My research about graphics of the Pro

[czunit]

Stamp: The XT100 was the internal name of the Professional 300 series before it was built. They did mock ups and all sorts of things. That document.... many Botham spies died to bring us that document. Ok, maybe not but it's an interesting but of history.

I have found it to be quite accurate in terms of what it describes, so yeah it does have some neat stuff in there including a lot about the disk controllers.

The images are all sorts o' stuff. SPSS of course is the most fun one, I have the whole manual I should scan it sometime.

 

[stanp]

I was reading through the P/OS Device Driver technical manual to understand how to write a driver for the RTI card and unexpectedly came across a section that described exactly what we did here to use the unmapped video mode. Oddly, this section appears in the 1984 version of the document, but it was deleted in the 1987 version for P/OS V3.2. It also describes how to directly write BITMAP memory and says it is necessary to disable the terminal subsystem prior to accessing the video hardware or unpredictable results/system software failures may occur. We worked under RT-11, but there is probably a similar need. This may explain why we had some unexplained crashes on occasion. The section says the info provided may apply to other operating systems. For P/OS, it recommends locating the graphics card using the WIMP$ Executive Directive and scanning for an ID of 2 in the low byte and 2 in the low 4 bits of the high byte.

"9.1.5 Natural Images {Reduced Resolution)
The video hardware normally displays an image with a resolution of
1024 by 240 pixels, with one bit per pixel per plane. This means that
a non-EBO system displays black or white pixels only, and an EBO
system can display eight colors or gray levels at a time.

Using reduced resolution, you can display more grey levels or colors.
It is possible to have 512 pixels per line with two bits per pixel per
plane, or 256 pixels per line with four bits per pixel per plane.

To use reduced resolution in a system with an EBO, the color map must
be DISABLED by clearing the appropriate bit in the CSR. In this mode,
the output from plane 1 drives the blue signal, the output from plane
2 drives the green signal, and the output from plane 3 drives the red
signal. At 512 resolution for all planes, this configuration produces
4 gray levels in a monochrome system, or 64 colors in a color system.
At 256 resolution, this configuration produces 16 gray levels in a
monochrome system, or 4096 colors in a color system.

Resolution is set on a per-plane basis, so different planes can be
displayed at different resolutions. However, this configuration has
no real usefulness since it can be applied only to a monochrome system
with an EBO. In such a system, the monochrome signal is the sum of
the three color signals, and several output combinations would
overload the monochrome monitor. Also, the color map is not used at
reduced resolution. Therefore, an EBO system cannot be used to
produce any more gray levels than a non-EBO one.

The video logic for setting the contents of video memory is unaffected
by the resolution. The only difference is that as the contents of
memory are scanned for display, instead of each bit (from the least to
most significant) of a word being used for a given pixel, each 4 bits
is used to generate one of 16 possible levels. Thus, the application
must set 4 bits (in each plane) to define a pixel.

Note that at ANY resolution, the pixel aspect ratio is not one-to-one."

 

[vol.litwr]

@stanp Thanks for your interesting information. Of course the use of WIMP$ Executive Directive is more professional but my hack must always work too. Does the documentation show a way to disable the terminal subsystem? An alternative is to disable of interrupts but this can break the timer if we don't prepare the proper code. I have just added the interrupt disable code to https://github.com/litwr2/retro/blob/main/pro-3xx/utilities/fillv.mac - would you like to test it? Is the program stable now?

 

[stanp]

@stanp Thanks for your interesting information. Of course the use of WIMP$ Executive Directive is more professional but my hack must always work too. Does the documentation show a way to disable the terminal subsystem? An alternative is to disable of interrupts but this can break the timer if we don't prepare the proper code. I have just added the interrupt disable code to https://github.com/litwr2/retro/blob/main/pro-3xx/utilities/fillv.mac - would you like to test it? Is the program stable now?

Yes, below is the description of how to "disable" the terminal subsystem. Also, I wanted to make sure you saw my pieiss results on Mar 3.

"Before directly accessing the video hardware, an application must
ensure that the terminal subsystem is not "active". Failure to
"disable" the terminal subsystem can have unpredictable results,
including system software failure.
Steps for "disabling" the video subsystem (P/OS Version 1.7 and 2.0)Next
are as follows.

1. Send a RIS (<ESC>c). This resets the terminal subsystem to
its initial state, and clears the screen.
2. Send a "disable cursor" sequence (<ESC>[?251). This turns
the text mode cursor off.

After disabling the cursor, the terminal subsystem accesses the video
hardware only when it is requested to display something - or when it
blanks the screen at the end of it's time-out period. If the
application combines requests to the terminal subsystem with it's own
manipulation of the video hardware, it must save and restore the
contents of the following device registers:
e Control and Status Register
• Plane 1 Control Register
Plane 2 and 3 Control Register
• Memory Base Register (should not be modified at all}

NOTE
CAUTION Do not set the interrupt enable bits. The
results of doing so are unpredictable, and probably
undesirable. The system could hang or crash.

 

[vol.litwr]

Yes, below is the description of how to "disable" the terminal subsystem. Also, I wanted to make sure you saw my pieiss results on Mar 3.

"Before directly accessing the video hardware, an application must
ensure that the terminal subsystem is not "active". Failure to
"disable" the terminal subsystem can have unpredictable results,
including system software failure.
Steps for "disabling" the video subsystem (P/OS Version 1.7 and 2.0)Next
are as follows.

1. Send a RIS (<ESC>c). This resets the terminal subsystem to
its initial state, and clears the screen.
2. Send a "disable cursor" sequence (<ESC>[?251). This turns
the text mode cursor off.

After disabling the cursor, the terminal subsystem accesses the video
hardware only when it is requested to display something - or when it
blanks the screen at the end of it's time-out period. If the
application combines requests to the terminal subsystem with it's own
manipulation of the video hardware, it must save and restore the
contents of the following device registers:
e Control and Status Register
• Plane 1 Control Register
Plane 2 and 3 Control Register
• Memory Base Register (should not be modified at all}

NOTE
CAUTION Do not set the interrupt enable bits. The
results of doing so are unpredictable, and probably
undesirable. The system could hang or crash.

Many thanks again for your results for the pi-calculator (EIS) under P/OS. They were added to the main table long ago, they are item #115 there.
Thanks also for the information about disabling the video subsystem. However my experiments show that we need to save more video registers than just the four mentioned in the documentation.
I am still curious, does disabling interrupts make FILLV stable?

 

[stanp]

Many thanks again for your results for the pi-calculator (EIS) under P/OS. They were added to the main table long ago, they are item #115 there.
Thanks also for the information about disabling the video subsystem. However my experiments show that we need to save more video registers than just the four mentioned in the documentation.
I am still curious, does disabling interrupts make FILLV stable?

I got around to trying FILLV. It is stable. The screen scrolled while it was running, but this is because I am using the VR201 monitor at the moment. When I set the line mode to 240 lines, the scroll stopped. The time reported was 2.50 - 2.53.

 

[vol.litwr]

I got around to trying FILLV. It is stable. The screen scrolled while it was running, but this is because I am using the VR201 monitor at the moment. When I set the line mode to 240 lines, the scroll stopped. The time reported was 2.50 - 2.53.

Interestingly, the interrupt disabling makes the code almost 2 times faster - https://forum.vcfed.org/index.php?threads/my-research-about-graphics-of-the-pro.1244252/post-1348386 - it was 4.25 seconds instead of 2.5 now!

 

[stanp]

Interestingly, the interrupt disabling makes the code almost 2 times faster - https://forum.vcfed.org/index.php?threads/my-research-about-graphics-of-the-pro.1244252/post-1348386 - it was 4.25 seconds instead of 2.5 now!

Yes, I noticed that too. I ran the new code several times and went back to a prior version to confirm it was still 4.25.

 

[vol.litwr]

Yes, I noticed that too. I ran the new code several times and went back to a prior version to confirm it was still 4.25.

I have two hypotheses that may explain this strange result:
1) the system timer works on interrupts. Perhaps the hardware can't handle pending interrupts properly and requires immediate CPU response. This causes some interrupt requests to be lost and gives the timer less value than it should;
2) when an interrupt occurs in a custom memory configuration, it causes the system to do some extra work (thas may crash the system sometimes), and this causes the slower result.
Case #1 is easy to spot, all we need is a stopwatch. Would you do me a favor and check this?

 

[stanp]

I have two hypotheses that may explain this strange result:
1) the system timer works on interrupts. Perhaps the hardware can't handle pending interrupts properly and requires immediate CPU response. This causes some interrupt requests to be lost and gives the timer less value than it should;
2) when an interrupt occurs in a custom memory configuration, it causes the system to do some extra work (thas may crash the system sometimes), and this causes the slower result.
Case #1 is easy to spot, all we need is a stopwatch. Would you do me a favor and check this?

Good call! The stopwatch measurement is 4 to 4.5 seconds. No noticeable difference in elapsed time between current and previous versions, but the reporting is different.

 

[vol.litwr]

Good call! The stopwatch measurement is 4 to 4.5 seconds. No noticeable difference in elapsed time between current and previous versions, but the reporting is different.

It's a bit of an unexpected result for me. I assumed that the next instruction sequence would take less than 32 CPU cycles.

a: mov r3,(r0)+
   sob r1,a

However, it may take about 40. So I made some changes to FILLV. I have also attached the diff. It is interesting will this variant show proper timings?