CHI INTERFACE AND DISK DRIVE
I managed to find documentation on some of the chips used on the logic boards inside this box - they are old Fairchild circuits from the late 1960s, a mix of DTL, TTL and what they called MSI (medium scale integration) that would correspond to the 7400 series level of functionality in future years.
The receiver circuits are TTL hex inverters which convert the 0 to +3V swing of the transmission line to an inverted TTL output, pulling the line up with the 100ohm terminating resistor required for the SAC cable. The driving circuits are DTL dual gates which look very much like a basic SLT NAND gate with no pullup resistor, the same basic circuit used to drive the transmission lines, taking a TTL level input (apparently) and pulling the transmission line down to ground if when the input is positive.
Once I map the specific card assignments to the SAC cable signals, I will be able to pop out the boards used in the CHI interface and stick in some boards I manufacture which deliver the signals to my circuits instead. Alternatively, if I trusted the logic levels, I could take the outputs of the CHI boards as TTL inputs and inject TTL outputs to the driver boards.
Only some of the chips are currently available from sources such as Anchor Electronics, but not the DTL dual gate which drives the transmission line. That makes reliance on the CHI interfaces somewhat less desirable than simply connecting my receiver/driver boards to the cable.
I attempted to find the addresses controlled by the CHI box, issuing Sense DSW to all potential addresses. When I sense the internal disk drive, powered off, it returns a Not Ready bit in the DSW as it should. The CHI box did not return anything for Sense DSW for either the disk drive or the line printer which it implements. This tells me it is not healthy enough to be responding to XIO commands for its area codes.
I looked at the disk heads with some better lighting and the heads appear too scratched up to be used. Perhaps, however, if the disk adapter logic works properly, I can figure out how to interface the DEC RK05 drives to the CHI box. However, this is not a priority.
NEW KEYPUNCH INTERFACE DEVELOPMENT
I discovered that the push pin connector for the +5V supply to the sensing pins in the keypunch was broken off inside the heat shrink tube, thus the wire and pin were hanging together solely because of the shrunken insulator tube. I replaced that connection and resumed testing.
However, no sooner did I turn on the keypunch and register and card, than it began punching the eleven row holes repeatedly (with no command input from me). Arrrrgggggggghhhh. Undoubtedly some electrical/mechanical treachery, coincidentally occurring just as I fixed the prior problem. However, I need to spend time to figure out what is causing this issue.
I am also concerned about lack of space in memory, since I have been bumping into problems from time to time and these don't behave cleanly, wasting diagnostic time before the root cause is seen to be lack of space. I converted my two fixed tables, the BCD and EBCDIC translations from ASCII, to place them in flash memory (program space) and to use only an unsigned integer rather than an unsigned long.
This change will save 512 words or 1024 bytes out of the 8192 bytes which are the entire dynamic RAM space for the program. I also switched all my uses of unsigned long to unsigned int (except for the time based functions which use the 32 bit variables), saving additional space.
While methodically testing with various components in and out of the circuit - no punch cable, no read cable, and so forth - I discovered that the errant punching occurs only when the reader cable is plugged in. My suspicion is that the +5V connection I recently repaired is bridging to some other circuit on the same relay, which is part of the DUP circuits that will punch a card from the values found on the card in the read station
After some adjustment of leads, I discovered that one of the read pins (for row 11) had popped out of its relay hole and was bridging to some other spot, inducing the spontaneous punching. After replacing the pin in its proper location, the spurious punching problem went away.
After some testing I can see that I have some slight errors in my direct access routines that are setting the microprocessor ports to fire the punch relays. Most of the holes are being punched as intended, but my code handling rows 8 and 9 are updating the 6 and 7 pins instead. Also, the release pin is not being activated.
After reviewing the code I found the problems. The next test showed they were corrected, except for the release which was only because the cable wasn't fully inserted. This leaves only the reading that isn't yet working right.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I finished installing all the wiring to the remaining boards, other than the lines from the SAC cable to the 1131 itself. I began the task of attaching the TTL signal wires to the connector I chose, a high density 78 pin type, but discovered that the pins don't crimp reliably around the wires, solder gets in the way of insertion, and placing these into the connector would require a special tool unless you want to be pushing a pin inward from the wire.
Pushing on the wire resulted in snapped connections, pulling on the pins to draw them into the connector resulted in deformed, damaged pins, and the fussiness of the crimp pin when trying to install the wires was just too high to tolerate for 78 leads on each side of the connection. I abandoned that choice for connecting the boards and will have to make a new design choice.
Tomorrow I will test out all 77 circuits before I begin testing their interface with the 1131.