Keypunch able to read all eighty columns now, plus work on SAC interface

NEW KEYPUNCH INTERFACE DEVELOPMENT

The method of using multipunch and spacing did not give me the first column's data value. I need to study the mechanism and the methods used for duplicating cards much more deeply in order to figure out how I can capture column one of each card. There was a comment in the 029 Theory of Operation concerning how punching happens a cycle after reading, with the machine using a 'dummy punch cycle'.

That dummy cycle seemed to be necessary only when the sensed value would be needed to drive punch magnets in the same cycle. For our purposes, a delay wouldn't be necessary but the machine itself may be designed such that we can't do what we want without the equivalent of a dummy cycle.
A minor setback, until I develop a method that will work; hopefully without adding wires and relays to the design.

I found that if I fire the punch clutch directly, it produces a dummy punch cycle. No holes are punched and no escapement (movement of the card) occurs. I wired the keypunch to allow me to trigger this, added some code, and now I can reliably grab the first column of the card in the read station.

I am having some problems with stack overflow, since the Arduino has a very limited static ram space for all variables and stack frames. I stripped out some unneeded variables, outputting characters as they are read rather than waiting until the end of the card to send them - less efficient because it makes all those calls to the serial stream but it saves space. I also collapsed the user table and ascii table to a single data structure.

I have some other ideas if I am still suffering from stack overruns, but each trimming makes the program a bit more opaque to the reader and a bit more cumbersome to update. I will keep working at this until the code runs reliably.

I now realize there is something more pernicious going on, because the system resets at the same point, column 46, whether I am punching or reading, after several rounds of changes that trimmed down memory use.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

The 160 pin socket for my interface is ordered and should arrive in three or four days. It is time for me to think of the right enclosure for this interface, something that has enough room for the four conversion boards, this socket, an FPGA based main card, and whatever connectors I need to support all the real and virtual peripherals that will be hosted by the box. Some design thinking will be required.

I found a way to temporarily disconnect two signal wires from inside the CHI box in order to test out my circuits - the wires from the SAC cable are hooked to wirewrap pins on the backplane using push-on connectors. After identifying the pins that correspond to the in and out signals I wanted to use,

I traced all the 160 pin cable connection onto the CHI backplane to discover where each signal is available. I planned to lift the connectors off the wirewrap pins for an interrupt request line and the corresponding interrupt status. However, there are some ambiguities including a pair of signals connected that don't show up on my schematics, missing connections for handling interrupt levels 3 and 5, and a few holes in the socket where no connection can be made.

I intended to hook these wires to a receiver and driver circuit on one of my boards, provide power and set up a TTL input and output source/sink where I could inject the interrupt request and later watch the interrupt level go active. The 1131 would be in single instruction mode, to delay the satisfaction of the interrupt request, and to verify the remotely detected signals against the console display lights. Once I sort out the remaining questions about the cable assignment and hookup, I can perform this test.