Debugging the virtual 1442 functionality
First chance to get out to test was lunchtime today, when my first test revealed a flaw causing me to only fetch the first card column in the read emitter process. Quickly changed, then glacially synthesized and made ready to load into the ztex board. I got one more shot at the read test before my afternoon client calls began, and took it. Reading is now working perfectly.
Late in the afternoon I went out to begin testing the punch functionality, when XIO Control specifies a Start Punch operation. The punch emitter process will 'loop' up to 80 times, once per column. It stops early if bit 12 of a fetched word is set on, meaning we are punching only up to this column, otherwise it goes the full size of the card. The interrupt handler software will issue an XIO Write for each interrupt on IL0, thus punching each column. I should be saving these output words in the pre-punch buffer and then writing them up to the output (stacker) files.
There are two tests to run here - partial card and full 80 column - where the goal is to see if the new punched 'holes' are added to the card previously read (from the pre-read buffer) but any prior contents are preserved. The partial card should leave all the remaining columns untouched. This involves ORing together the previous contents of the pre-punch buffer plus the output word as captured during the XIO Write. My first test of this showed that I was successfully ORing but also doing it during the copyover from pre-read to pre-punch, when I only intended to do it for XIO Write.
With some changes inserted to isolate the OR activity to card punching, but not the copy-over between the two card image buffers in the 1442, I found it all worked well now. I could punch short records or the entire card, it would overwrite existing 'holes' in the card images if they were not blank, and everything for reading, punching and feeding now looked perfect.
The final area to test was the boot function - extract the current card in the input file, translated to the special Program Load format, and write it down to core memory locations 0 to 79. I tried it, found that memory was properly loaded exactly as it should, so I went ahead and tried a deck which was a boot card, the diagnostic monitor and then the 1442 functional test diagnostic program. Why not go all out to test this virtual 1442?
My boot card stopped with a wait 30F2 which means that the DSW was not right. The stored DSW was completely blank, but it should have had on the operations complete DSW for the card reader I guess. I will need to make some change to drive this bit on when I push the "Boot" or Program Load button for the 1442.
First, however, I need to prove out that boot is working properly. I brought over the seven one-card diagnostic programs and will boot a few to be sure all is well before trying to debug the diagnostic loader deck issue. All seven worked properly. The last one will test card reading and response status from the virtual 1442, by turning on the interrupt delay switch to block interrupts. This shows me that something is not working as it should, blocking both the boot emulation and this diagnostic.
This bears some investigation - I need to investigate more closely to see what is expected but not occurring. My hand code worked but these diagnostics don't. First thing I will look at is the reset bits for the XIO Sense Device - my hand code reset both interrupt levels with bits 14 and 15 both on. However, if I have the bits reversed, so that I am resetting the wrong condition for each bit, it would fail on the diagnostic but not fail with my hand code.
I see from my research that bit 15 should be resetting the IL0 condition (read response or punch response to a column ready for read/write) and bit 14 resets the IL4 condition (operation complete). Sadly, I see that I have properly implemented this, so my first guess is wrong.
Puzzling. If I had a working 1442 I could compare its behavior to what I am producing - but I don't have that option. I could potentially get some aid from other 1130 owners in trying a few bits of hand code, but only after I have really spent time investigating this problem locally.
My best guess now is that I don't present the busy bit on in the DSW for the times that the code expects it. New research - very detailed examination of the busy status flipflop in the 1442 adapter and how it is set and reset. That confirmed I was modeling this improperly.
Several flipflops are ORed together to form the busy condition - basically when a feed, read or punch cycle is taken, it goes on at activation of the cycle and turns off at the end, about when the operation complete interrupt would be turned on. This is easy to model - I just report not busy whenever the main feed cycle process is at its idle state, otherwise the device is busy.
I was keeping the device busy up until the Sense Device with reset turned off the op complete state. This is not correct and I changed the logic to make the busy status more accurate. One final test at night but it still didn't work as expected.
Implementing physical plotter (1627 equivalent)
I cleaned up the transaction logic on the master fgpa side, sending the result of the XIO Write over and then triggering the IL5 interrupt when the slave has responded. I also changed the logic to ignore the XIO Write when the device is reported Not Ready by the slave fpga. I began building the slave fpga side of the logic to drive the plotter.
Implementing physical paper tape reader/punch (1134 and 1055 equivalents)
The transactional logic between master and slave fpgas was inserted into the ztex board side, so that it calls the slave to handle the paper tape devices. I also changed it to to handle Not Ready conditions on either device. As well as with the 1627, I began building the logic in the slave fpga that will drive the motor, latch up data and time the actions of the paper tape reader and paper tape punch devices.
No comments:
Post a Comment