Restructuring the GUI
-- virtual 1442 --
Made a few tweaks to the copyover logic, particularly the way the buffer memory addresses are created. Now they are registered to avoid passing glitches as various selection signals transition, particularly state variables which might pass through unwanted states momentarily.
This made zero difference in the results - still blank cards coming out of the pre-punch buffer when I fetch them to the GUI. I validated once again that the card image in the pre-read buffer is properly read into core during a 1442 read operation. Still unclear whether this failure stems from the copyover process that moves a card from pre-read to pre-punch, or whether it is a defect in the get special data transaction fetching the pre-punch buffer.
I went back to the diagnostic traps, trying to catch column 2 during a copyover, setting one lamp if the high bit of that column is 1, a different lamp if the high bit was 0. At least one of the lamps will light if I catch column 2 during a copyover. This tests that the pre-read buffer still has the proper card image at the time that the copyover is running. As you will see, this is a time consuming, exhaustive search for the place where the problem starts.
My first tests proved that the data was coming out of the pre-read buffer during the copyover process. The open questions are whether it makes it into the pre-punch, whether it is still there on get special data fetch, and whether something overwrites it before delivery.
Next, I moved the traps to see what the high bit of column 2 of the input to the pre-punch buffer is seeing at the time that the copyover is writing to that buffer. This will tell me whether the data is presented to the pre-punch buffer for writing.
This too worked properly. I have two decks to run into the 1442. One has the 12 row punched in column 2, while the other does not. The various lamps worked as expected, thus the data is set up as input to the pre-punch buffer during copyover.
Next, I set the traps to tell me what is coming out of the pre-punch buffer after it was written, for the high bit of column 2 during a copyover. This will confirm it was actually written into the buffer. The results highlighted where the problem lies. The value in column 2 of the pre-punch buffer output is the same as what was written in for column 1. Some interaction here is introducing the off by one problem. Clearly, that is separate from the other problem where only blanks are returned to the PC.
I changed quite a bit and still see the same outcome - no idea why this is not working, but it could be some flaw with how Vivado is implementing the three built in block ram instances. There is an obscure message about problems with black box instances, which I can't sort out even after reading all the documents and web pages related to the message.
I decided to infer the block ram with VHDL, coding up a module 'blockmem' based on the exact template from Xilinx documents. This way I will avoid the 'black box' confusion and should have discrete memories for all three buffers (two in the 1442 and one used for the carriage control tape of a virtual 1403).
My first try to test this resulting in the spurious lack of bit 4 on any USB transmissions, which I cure by making a trivial change and resynthesizing to replace the corrupted bitstream with a good one.
Bit 4 problem went away, but still not seeing the stored value from the pre-punch buffer that I see on its input. Time to look closely to make sure I am actually toggling the write enable - not sure what else could be the problem.
I did more tweaking and checking of the behavior when the hopper runs out, but with and without the last card box checked. Everything is working like a charm. At this point I have a good card reader, but it won't produce the stacker output file that will be essential for punching.
Time to rebuild the copy over process in its entirety. More tomorrow.