Thursday, March 12, 2015

Plodding through wiring and testing of SAC Interface cards, plus work on the 1442 read/punch


I determined that the failure to read a boot card is because the read clutch isn't engaging at all - the feed cycle takes place but no sign of movement on the read clutch. I  studying the mechanism and logic in order to find the next few things to check.

What I discovered is that the read clutch should trip each time the feed cycle occurs, but it is not. The activator is a pushrod riding on a cam on the feed clutch axle. Time to look for missing or misplaced rods.

Yes, it was the staggeringly difficult to replace rod from a while back which had fallen out. I put in thirty minutes of contortions involving several forceps, hands bent through parts of the mechanism and with great luck, I got it back into place.

I did a boot read of a one card diagnostic which was read perfectly - no errors! I was eager to pull that card out and put in the cold start card, booting up DMS from the 1442 card reader and of course getting the job start page printed on the 1132.

In my haste to remove the card, I brushed against the read clutch lever, which instantaneously ejects the rod. I called myself every name in the book, went inside to calm down, then returned to wrestle that damned rod back into its position again.

Got it back into the machine and did a boot of DMS using a cold start card - the reader got a transport check but that is after the read is complete and thus invisible to the process of booting. Up came the monitor and out printed the header page.

I jumped on the 029 keypunch and put together a three card job to dump the LET to printer (that is a listing of the directory of the disk pack. Success! This further exercised the printer as well as validating that the reading functionality is solid.

Here is a sloppy, quick video because I didn't think about videorecording until the job was already running and printing away: Printing the disk cartridge LET on 1132 printer

Now I just have to work out the stale grease and other problems involved in moving cards through the punch station and out to the stackers. I haven't tested punching cards yet, so there may be some additional problems lurking there, but at least for now the only remaining issues are in transporting cards once read.


I began to test the boards with the 1130 hooked up, in order to verify the quality of signals and the behavior of my circuits. My first discovery was disheartening. Somehow I had mis-marked the input and output sides of my circuits, thus wiring the 1130 signals into the wrong side on all 77 circuits.

Checking the rewired inputs and operation of a receiver circuit
I first moved all 12 input and 12 output signals on the top level board, then hooked up the scope and 1130 again to see the behavior. The good news is that twofold. First, nothing was damaged by my Homer Simpson moment with the original connections. Second, the signals look fantastic.

Incoming 1130 signal on top in yellow, my output signal below in blue
I observed the T0 clock input while running a loop on the 1130, monitoring the signal sent by the 1130 and then my receiver/conversion circuit output as it would be presented to the FPGA. The output pulse has essentially zero delay on the timescale of the 1130 system and the shape of my output pulse is more ideal than the signal transmitted by the 1130.

I finished the rework of the first board, mounting new headers that will connect to the FPGA cable. It was then time to validate that all 12 incoming signals worked properly. The outgoing signals from this board are just the data lines that will be gated into memory when the software is reading from a peripheral supported by this box. As such, observing them will be a bit complicated. They are normally gated off and don't affect the B register until the proper cycle of an I/O instruction.

I was, however, able to inject a signal into my driver circuit using an external tool and monitor the resulting signal going out to the 1130, but don't see it activating. That was true for multiple circuits, eliminating the chance it is a construction or component error. More study is needed to sort this out.

I ordered all the connector parts I need to make up the final FPGA connection cable. The parts should arrive early next week when I can fabricate the cables and then finish physical construction of the SAC interface box.

My the end of my lunch hour, I had converted board two as well, and the partial board four, now having 53 of the 77 signals correctly installed. After work, I finished the third full board, the last one to do.

I discovered to my horror that wires had snapped off of pins on the 160 pin connector - two I can see - which would drop bits of data being read in from an IO device to the 1130 through this interface. I have to fix the problems, so a bit of unexpected work on top of everything else I have had to do on this unit.

No comments:

Post a Comment