Printer working fairly well in initial tests, also source code extracted from tape

1132 PRINTER RESTORATION

I removed the magnet unit and then watched the machine run with that out. I could see that the restore latches weren't moving! No wonder it was printing eternally. Out came the restore latch assembly as well. Yes, that is the one that took hours in order to insert the pins upon which it pivots.

I carefully evaluated the position of the restore latch assembly, after which I re-installed it. The pins only took me 45 minutes in total for the pair - definitely getting faster at this. I then installed the big magnet unit in place. Running it quickly showed me that the restore latches needed a bit of adjustment, so I rotated them to make them swing further.

With power applied, the printer did a single cycle and then latched all the 120 print columns - blissful quiet with the printer just idling away. It is now time to put on some of the cosmetic sheet iron fittings to the left and right side, since these won't block my access to make any needed adjustments.

It is therefore time to write and toggle in the short program to print "carl carl carl . . . " across the line. As a brief recap of yesterday's tutorial, the program will issue Start Print and then wait for printer interrupts. The printer will interrupt us as each character around the print wheel is rotating into printing position. We respond to the interrupt with a Read Emitter command to fetch the encoded value of the newly arriving character, but only when it is 'c', 'a', 'r' or 'l' will be set on bits in the printer scan area 0x0120 to 0x0127 causing the relevant columns to print that character.

After writing the program and its interrupt handlers, I toggled it into core memory on the 1130 and prepared the printer for a test. When I let it rip, the result was not so good, but it appeared to be problems with my code. Rather than waste the waning daylight with debugging of some hand code, I changed it to just print whatever character first is ready to print, across all 120 columns, then stop the printer.

Result of first tests, printing 120 columns of whatever character is first ready to print

That worked well. I am seeing a few signs of residual sludge which should work its way out with some sustained printing, but generally it looks very good for a first test. I see one column that is failing to print sometimes and out of 120 columns there might be 1 to 3 that print an adjacent character. The adjacent characters are caused by slow movement of the various levers and the column that doesn't fire would be another situation of sticky levers. I believe I saw all the columns fire correctly at one time or another out of the dozen or so times I printed with my test code.

Video of first test printing on the 1132 printer

I have put all the cosmetic parts back - other than the doors and sides that I had off for access. As soon as I can get the card reader working, to read in the 1132 diagnostic decks, I can really exercise this. I will try to build out some solid code using the 1130 simulator, which could let me print patterns sooner.

All but the side and front covers installed - ready for further testing

READ TAPE OF 1130/1800 SOURCE CODE

Lyle Bickley was successful, after a bit of effort, in reading the entire tape and converting its data to files on a CD disc. I looked them over and converted them from EBCDIC to ASCII text files, unblocked to single 80 character card images, using a quick python program I wrote. I then sent them to Clare Owens.

I will save the files as well, using them as further examples of 1130 and 1800 software.

Part of one of the source code files on the tape

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

My ZTEX fpga board was transferred from customs to the postal service in NY yesterday, just not sure how many more days in transit before it is delivered. My expectation is that it arrives this week, however, so I have to be ready.

I need to work out the pin assignments and VHDL signal names for use with the new board and get them into the code for the interface. I also have to put in the code for the new EZ-USB link that replaces the Digilent USB link I had been using. This likely requires installation of a tool chain for the open source USB functionality.

On the PC side, if I choose to use Python as the language for any software I write, I will need a python interface for libusb in order to communicate with the board.