SAC interface circuits interact with 1131, plus keypunch debugging continues

CHI INTERFACE AND DISK DRIVE

My first attempt to hook up my circuits to the backplane of the CHI interface box caused some damage to the interrupt level 4 status and request wires where they were hooked to wirewrap pins on the backplane. I will need to repair this before I use the unit further.

In the process of tracing the wiring of the 160 pin socket inside the CHI box, I found four signals that are not connected because the socket has an empty hole rather than a female pin at those locations. The way that the SAC interface works on the cable makes it insensitive to unconnected lines (or a missing SAC cable). Any signal that is produced by the 1131 is activating a transistor to pull the line down to ground, but without a connection, it doesn't matter if the pin floats. Any signal that is received by the 1131 terminates the cable on the 1130 end, puts 3V on the pin, and watches to see if the remote end pulls that pin down to ground or leaves it at 3V. With nothing connected, the pin stays at 3V.

Two of the missing pins are for specialized modes that may be needed by certain peripherals, but are not needed by the printer and disk connections implemented by CHI: Advance I/O Entry and Block Channel Advance cause the 1130 to latch in data earlier than normal in a memory cycle and keep the cycle stealing logic holding longer than normal for peripherals that can't meet the timing requirements of an 1130 memory cycle. If we don't ask for these, we get normal 1131 operatoin.

The other two are the interrupt level status for levels 3 and 5 - without looking at them, the CHI box can't place any devices on those interrupt levels and can't watch to see if the level is active. Since CHI determined what levels it would use for its disk and printer devices, they can work without that information.

NEW KEYPUNCH INTERFACE DEVELOPMENT

Something is hanging the Arduino in mid-card, around column 46. I looked over the keypunch and don't see any shorted pins or obvious anomalies. I will have to do more testing to understand what triggers this condition and therefore how to fix it.

I did testing with various length output lines and also with the read cable disconnected. The problem occurs regardless of the read cable, which rules out that as a source. When I punched a line with about 55 characters it seemed to finish properly and continue to process other commands, but when a line to be punched was 66 or more characters, the Arduino hung up during the punching.

I am not sure what changed that left this sensitive to this problem, but I will do further clean up of the code to reduce the chance of the stack running into the heap. One change I will make is to remove the use of the String objects which are what I extend as I add the incoming command lines and build up the punch output. I will explicitly store these in character arrays and track their size myself.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

I did the test with my interface boards and the 1131, making use of the CHI box for its 160 pin socket. I pulled the circuit cards, leaving the SLT lines unterminated, then hooked two of them up to circuits on my board and to a TTL switch and indicator light. The signals were interrupt request for level 2, and interrupt level 2 active.

It wasn't an ideal connection, since the wire run from the socket was almost the maximum permissible for unbalanced lines - straight wire not twisted pairs - before I added my twisted pairs to those backplane pins. The behavior of the 1131 was what I expected when I had it in single step (SS) mode, but it was always triggering interrupt level 2 when in any other run mode.

My test setup to activate and monitor signals to the 1130 over the SAC cable

In the single step mode, the basic clocking pulses such as Phase A are held at one level rather than oscillating at the basic machine cycle time. I pushed the start button to advance the machine through each of the T clock steps for each of the instruction phases. The other modes induce noise on the line, to which the poor termination of the ad-hoc wiring is susceptible - at least that is what I suspect.

When the machine is in the midst of executing an instruction and a request is raised for an interrupt, the request is not acted upon until the instruction ends and is ready to step from T7 to T0 of a new I1 phase. I executed several instructions step by step, then in the midst of one I turned on the interrupt request switch on my testbed. As I finished stepping through the instruction, when I finished the last step, the interrupt level 2 light lit and the next step performed the forced BSI Indirect which is how an 1130 jumps to its interrupt routine.

When the machine entered the interrupt level, the light changed on my status indicator on the testbed, showing me that I was properly receiving the state of that signal. This proved to me that I was able to receive the proper logic state of signals coming from the 1131 and that I could produce logic states that properly activated functions on the 1131.

As I said, however, when the machine was in any other mode, which sends a continual stream of Phase A and T clock signals on the cable, the 1131 would jump into interrupt level 2. This didn't depend on the position of the input switch and a VOM showed a steady proper voltage that should be interpreted as no request. This is why I believe it is transient factors that are artifacts of my simple testing method, rather than a problem with the interface boards.