Implementing physical plotter (1627 equivalent)
I fired up the 1130 with the plotter connected through my slave fpga board to do some testing of XIO commands to see how it worked. I found that interrupt level 4 requests are hot from my fpga, which is probably an issue in the 1403 function as it uses that level. I need to debug that first before I begin writing to the plotter.
The problem with the hot interrupt was a mistake in assigning signals to the high speed link. The Not Ready status for the paper tape reader was connected so that it appeared to be the end operation signal which triggers an interrupt on IL4. Correcting the assignments should get rid of the undesired interrupt.
It worked and I then tried some plotter commands (XIO Write with the proper data words), but it wasn't responding. I executed XIO Sense Device and saw that my slave fpga was reporting Not Ready. I hadn't wired up the proper wire to mark it ready, but instead connected the 1627, 1134 and 1055 ready status to three of the slide switches on the slave fpga board. Now I can test as I wish.
Something is blocking response to the XIO for the plotter - I issue the XIO Write and should see a movement plus an interrupt on level 3, but even though the Not Ready bit is off, the adapter behaves as if it were still on.
Implementing physical paper tape reader/punch (1134 and 1055 equivalents)
I saw an improvement in how I would handle interrupts for the paper tape devices and began implementing it in the fpga. This treatment is consistent with the other device drives. I won't be testing the paper tape until I finish with the physical plotter and virtual 1403 types, but the changes are in place.
Implementing virtual 1403 printer
I cleaned up and tested the Python code that will load a virtual carriage control tape image from a PC file, as it is opening a print output file. If the user cancels the file open, a default tape is loaded. This tape has channel 1 in the first of 66 lines, channel 9 punched in line 65, channel 12 punched in line 66, and then a pattern for the other channels based on their numbers.I put channel 2 on every other line, channel 3 on every 3rd line, etc so that there is some degree of skipping even with the default tape. .
My testing would have been easier if the IBM diagnostic decks for the 1403 printer had been in the drawers that came with my 1130. There was a third party printer that pretended to be a 1403, but I am not sure whether the diagnostics for that depend on any behaviors that were different from an IBM 1403.
Without the 1130 or the SAC box, I can still test out the logic for opening the output file on the PC and trying to open the carriage tape image file. That all worked well but when the Python program began to write the default tape image to the buffer, my write special data transaction timed out. More debugging on my plate, along with the hot IL4 from above.
I found the problem with the write special data transaction, which was miscoded in the Python program. I fixed up this as well and went back to testing - after the 45 minutes needed to synthesize both fpga boards.
When I turn on the virtual 1403, I get an error in the first tranaction which turns off the Not Ready status to signal that programs can do IO to the printer. Something is going wrong with that or the following transaction, the one that loads the virtual carriage control tape buffer. Time to put in more diagnostics as this problem did not clear up after my first changes.
Well, I found the problem and it is something I tripped over earlier this year as well. The fpga logic looks for the transactions for the 1403 printer by matching the UCW number in the transaction. The 1403 printer is set up in the first UCW position, so its number is 00001 but the area code - the address used with the XIO program to speak to the printer - is 10101. I coded the latter value. Since I only have 20 UCWs in the current implementation, there will never be a value 21 (10101 in binary).
Thus, my logic didn't kick off and process the incoming carriage tape buffer contents and stalled the main transactional loop. I corrected the logic, surfed the internet for the half hour required to update the fpga, and then tested again. Not right, but it zoomed me in on the logic that is malfunctioning.
By the end of the day, I still hadn't found and fixed my problems, although the logic is cleaner and more solid as a result of the work so far.