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?

 

[stanp]

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?
View attachment 1277959

Sorry for the delay and let me start by saying thank you. It is because of FILLV that I was able to repair by EBO board. My temporary absence on this thread was because I recently acquired a DECnet card and found it had hardware problems on boot. I started a new VCF thread (https://forum.vcfed.org/index.php?t...th-a-pro380-and-windows-client.1247091/page-4) to pursue this problem and ironically two points led me back here. While debugging the DECnet card hardware, I decided to remove the EBO board in case there was an unexpected conflict. Well, in doing so, I ended up damaging it. The error code indicated a memory plane 2 error. After having success repairing my DECnet card by writing a utility to test the onboard memory and building upon the reverse engineering generously offered by others, I decided to write a similar program for the EBO. I started with your FILLV code and revised it to sequentially test each of the three memory planes, cover all 128KB in each plane (4 pages, not just the first 32KB/page 1), and then print out the read back memory value if it did not match the test pattern to identify the logical bit(s) in error so I could try to physically locate which of the 32 chips on the EBO was bad. I attached the program here for reference. It worked like a charm and told me Bit 10 was stuck low in plane 2. I was able to replace the chip and selectively identify which of the 32 chips was bad so that I did not have to replace chips in mass. My EBO is back up and running (well no error on boot up and a clean memory test. I just haven't yet connected a color monitor yet). So, again thank you.

However, the second point that led me back here is the issue with directly setting PARs. I had to set PARs for the DECNet card test also. For that program, I was running under P/OS (RSX-11M). I found similar issues as experienced here that were causing trap 4 and instability. After much debugging, I realized that even though I explicitly set PAR values, they were getting changed in at least two scenarios. First, if I called any system macros, my PAR was overwritten and restored by the OS. I confirmed the same happens in RT-11 with macros like .print and .ttyout. I had to make sure I didn't call a macro and then try to read EBO memory without first setting the PAR again. After addressing this issue, I encountered the second scenario, which you identified here with interrupts. If an interrupt occurred, such as during the tight memory read/write loop, I would suddenly get a trap 4. With P/OS, I could not loop through the full 8KB of virtual address space without triggering a trap. About ^O1700 writes in, it would trap. With my DECNet card program, I ended up coming to a similar solution as you, i.e., disabling interrupts, writing the PAR for each memory access and then re-enabling interrupts.

Disable interrupts
Set PAR and PDR values
Write memory
Read memory and increment base virtual address
Re-enable interrupts

In P/OS, I could not disable the interrupts by setting the Processor Status Word because those bits are protected and a change would trigger a trap. I tried to install a trap handler, but it hung the system. Instead of pursuing, I disabled interrupts through the interrupt controller masks (IC0). In doing so, I was able to traverse the whole 8KB in the virtual window. However, in P/OS, the side effect was that I lost my block cursor and could not turn it back on without a reboot. The Setup key menu showed the cursor on, but toggling it had no effect and I tried to send a control sequence without success. I am not sure why this occurred, but I suspect it had something to do with stopping all interrupts including the ToD clock for an extended time. Unlike your current FILLV code, I did not break up the loop. I suspect the blinking cursor is interrupt driven.

I started to research the proper way to use PARs and what I found is that none of the Macro 11 programmer training documents discuss the coder directly setting PARs. All examples and exercises show use of system macros, such as .CRAW and .CRRG, to formally request a block of memory, create a region, create a virtual window, and map the window to the region through an APR and let the OS/memory management unit set the PAR. These macros let the memory management unit select the physical memory and the coder never sets the PAR. In this way, the OS is always informed of the proper PAR values and when it needs to switch context, the OS will restore the PARs back to what is needed for the task. Whereas, if the coder directly sets the PARs without informing the OS, the OS will restore the PARs to what it believes is the proper value and hence we get the problem of our PARs suddenly changing after a macro call or interrupt. I found the issue to be the same across RT-11 and P/OS.

I'm willing to use the system macros, but there are times like this where we need a specific region of physical memory. How do you inform the OS/memory management unit that you want it to assign a specific portion of physical memory to a region and window so that it will set the proper PAR? Normally, the memory management unit decides on the location of memory when a request is made. I have not found a way to request a specific portion of physical memory through those macros. As such, I am not sure of the proper way to use PARs and whether directly setting them is appropriate without informaing the OS. The POS Driver manual talks about a $STPAR call to add option card memory to the system and discusses how to install a driver into the system. No discussion about how to reach onboard card memory via PARs.

Back to your updated FILLV code, it tested correct showing 4.25 seconds. You mentioned "I assumed that the next instruction sequence would take less than 32 CPU cycles". Why is 32 cycles significant? Is this time period related to some periodic interrupt that needs to occur?