Here's an update on my DECNA card debug. My program to test DECNA card memory led me on an educational journey to learn things that some of you probably know. After fixing the length calculation in the QIOW$S call, I proceeded to debug the memory test portion. It seemed to run, but I needed a way to determine if I was actually hitting the DECNA card with reads and writes. I tried different techniques including removing the card, but eventually found that turning off memory access in the 8207 to trigger a Trap 4 event with a bus reply timeout was best once I had confidence in the code to write the control register. I assembled, linked and ran the program from the P/OS Toolkit. I linked the program with /PR as a privileged task. I discovered that when you link it this way, it places the program in APR 5 space by default and you can choose APR 0, 4 or 5. The program does not run in kernel mode, but user mode. For that reason, my attempts to program kernel PARs yielded no results. Upon realizing this, I attempted to run in kernel mode by changing the PSW. But the mode bits are protected and trigger a Trap 4. I tried to install an error handler, but that froze the machine (maybe halted it). I then discovered the $SWSTK call for this purpose, but then determined it does not exist in P/OS. However, SWST$ exists and allows one to run a subroutine in kernel mode and return back to User mode rather than switch to kernel mode. A small test program showed SWST$ worked, but running in kernel mode for the memory check is probably not best. So, I returned to user space and found my changes to User PAR were not having their desired effect. I set tried both instruction and data space and later confirmed I was running in a mode that only the instruction space PARs are used. I also found I could not change User PAR 5, presumably because it is used by the code when linked with privilege. But I could alter User PAR 6 and User PAR 4. However, my debug code using QIOW$S was unknowingly causing unexpected problems. I discovered after much debug that even though I set PAR4 and called QIOW$S and $EDMSG to print the value to the terminal, my PAR 4 was being overwritten by the macro calls. So, while the screen message showed the right PAR, it was getting after the print. If I read the PAR and printed it consecutively, the change in PAR value from my value of 144000 to 1000 became evident. My takeaway is that if you set a PAR directly, don't assume it is still in place after calling a system macro. In fact, I think the technique of directly setting PARs is probably not good. There are macros such as CRAW$ and WDBBK$ to create virtual address windows and set the PARs. I haven't tried them yet under P/OS, but I suspect it may address the unexpected reset of the PARs. I tried this approach under RT-11 with success previously.
Getting past this problem and satisfying myself that the code was actually hitting the DECNA card by turning memory access on and off and triggering Trap 4 when off, my memory tests immediately showed a problem. I tried to write 0x0, 0xAAAA (125252) and 0x5555 (52525) and read back the results. I started with the lower block of 64KB and got the following:
0x0000 --> 060136
0xAAAA (125252) -> 165336
0x5555 (52525) -> 072537
The good news is that some bits are actually responding, so I am confident that I am hitting the card. If you break it down by bit you find errors as follows:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
G B B G G G G G G B B B B B B G G= good, B= Bad
This helps me identify which memory chips in the two columns of memory on the board may be bad, assuming I can determine whether the top of the column is bit 15 or bit 0. However, I then decided to check the upper 64KB of memory in the next row. I found the same result. I am thinking now the issue may not be the memory but instead a common buffer or latch, unless bad memory chips are forcing various bits of the data bus high or low. Any thoughts on whether this is a memory chip or buffer/latch problem and method to test which is at fault? It could be a data-in problem or a data-out problem. I assume the 8207 is working properly since I can map the memory, turn it on and off. and get some bits through.
Some have asked for the updated maintenance disk. I will post once I get a chance to clean up.
