Virtual 1403 printer is printing lines, skipping and spacing, but not fully correct yet

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Implementing physical plotter (1627 equivalent)

I created some hand code to enter which will move the plotter pen over a detectable distance. This will be toggled into core for my testing session this morning. It was only 26 words, not very onerous. Getting them to work properly for someone who is quite rusty in whipping up 1130 machine language added a bit of time.

My attempt at testing this was not successful. I suspect that the 1130 is too quick for the plotter, taking the interrupt and firing off all the successive commands before the plotter can reset. Not certain, however, and this will require a full set of diagnostic signals before I can get to the bottom of it. My priority is to wrap up the 1403 first, since it is nearing the finish line.

Implementing virtual 1403 printer

Reviewed my logic and cleaned up a few small points prior to testing this morning. It was not successful, but I suspected it was due to contamination from the 1627 testing I had been doing. When I straightened out the testing procedure, I discovered a flaw in my character translation (from 1403 printer code, packed two columns per word, to two characters of ASCII).

With that fixed, I went back out to work on the 1403 debugging. I have two minor errors in my spec, vis a vis the functional characteristics, which I also corrected. The next test printed my line properly. I tried the XIO Write with a skip to a channel, which did add multiple lines to the output file. The XIO Control may have also worked. However, both spacing and skipping did not trigger the interrupt or present DSW status, thus I may not be processing the carriage movement in the fpga.

I added some diagnostic signals while I looked over the fpga logic, but didn't do too much because I spotted the flaw that was blocking the carriage movement process and its completion interrupt. I did display the current print line, allowing me to see what occurs in the fpga as it moves the carriage. I added diagnostic writes in the Python program to give me the line number as the PC sees it.

When I began my last test of the day, prior to an evening out with friends, I ran into some flaw that stalled the transactional engine, causing timeouts before I could issue any 1403 XIO commands. I will need a whole new set of instrumentation to debug this, unless I spot it quickly in the VHDL code, and that would cost another 45 minute+ cycle time to run the toolchain.

Possible 1403 printer enhancement

One aspect of the 1403 printer which I did not model was parity checks - the printer code uses 6 bits for the character plus a parity bit to make the total number of 1 bits odd. I look up ASCII equivalents by the full 7 bits, the character value plus the correct parity error. Any parity error or unrecognized code outside of the 48 characters plus space that are rotating on the print train, result in a space.

I could implement a parity check as I fetch and translate characters from core, detecting the error in the Python program and signalling the fpga to present a parity check error rather than a successful print result. This would catch errors in programs writing to the 1403, behaving the same as a real 1403 printer, and might be important for running the 1403 printer diagnostics.

High Speed Link Errors

I see errors on the high speed link between the fpga boards when I use the manual controls on the 1130, in addition to power-on and power-off events. I should chase these down to ensure they won't occur in normal operation.