Saturday, March 19, 2016

Problem with 1403 function isolated to 'write special data' transaction from PC


Implementing virtual 1403 printer

The definitive diagnostic output was to a set of latches I set up to check the state of bit 1 of the carriage tape buffer word for various print line numbers. What I was pushing down from the Python program were the following four words for lines 1 to 4 - 0x8000 0x4000 0x2000 0x5000. These mean line 1 has only channel 1 set, line 2 has channel 2 set, line 3 has channel 3 set and line 4 has both channel 2 and channel 4 set. Bit 1 represents channel 2.

Therefore, I should have had bit 1, channel 2, set for lines 2 and 4, but not for 1 and 3. I spaced the printer through the four lines and had found bit 1 set on lines 2, 3 and 4. Not correct, as line 3 should have that channel off.

I did some more skip testing (XIO Write to skip to certain channels on the carriage control tape). I found that it behaved correctly but had a line number one higher than what should be sitting in the buffer. That is, if I was going to match a bit set in line 8 of the buffer, I would match and stop on line 9.

The proof of this was to do a skip to a channel that only existed in the last line of the buffer - such as channel 9 or 12 which I didn't set until the last line. The fpga logic had a runaway carriage - the result of looking for a channel (1 bit) when no buffer word has that bit set.

My problem is in the process that accepts the write special data transaction for the 1403 and places the data words from the transaction into the buffer. Tomorrow morning I will set the latches to watch the words being written and display the active word for given line numbers. This will freeze the transactional engine between fpga and PC, but give me the snapshots I need. At 30 minutes per tweak, it will continue to be a slow pace towards eventual success.

No comments:

Post a Comment