Since the Soroban Computeriter is entirely electro-mechanical, I expected everything to operate glacially slowly. Examination of the documentation and measurement of the actual Computeriter proved this true.
Printer Output
For
printing from the computer, the CDC 161 documentation provides this crude diagram. While it suggests the code selection solenoids
(TM-1 through TM-6) will be driven for about 65 milliseconds, it doesn't
directly indicate how long the TCM solenoid would be driven. Nor does it indicate when the TBS switch is expected to activate.
An examination of the CDC 161 logic diagrams suggests the real
answer is that the solenoids are driven until the TBS switch changes state. This would allow the Computeriter to manage its own operation.
The museum's Computeriter isn't really functional, but I found I could emulate the activation of the TCM solenoid by tripping a lever with a small screwdriver. This causes the TBS switch to switch states for about 40 milliseconds.
Hey, it's a starting point.
Originally
I thought to use the TCM input as an interrupt, so it's wired to the
PIC's INT0 input (RB0). However, my current software simply monitors
this input until it sees it asserted for 10 ms, then reads the six TM
inputs. It then asserts TBS for 40 ms, waits for TCM to be deasserted,
then goes back to waiting TCM to be asserted again.
This hasn't been tested yet. In fact, I found a bug in the state machine while writing this. This is what my old boss referred to as "Debugging by explaining it to the janitor": the process of organizing your thoughts to produce a decent explanation often results in recognizing the source of the problem.
Keyboard Input
For keyboard input to the computer, a rather poor timing diagram in the Computeriter Coder documentation suggested it would provide about 2 milliseconds of setup and hold time in the six "TC" code outputs on either side of a 25-30 ms "TCC" code valid signal. No description of the function switch contact timing is provided, but since all the mechanism are operated by the same drive system I assumed their timing would be similar to the TCC switch.
Given how sparse the documentation is, and how many assumptions I've made, I was shocked to discover this mostly worked the first time I tried it for real. Characters typed into Minicom on my laptop were translated from 7-bit ASCII to 6-bit Computeriter codes and appeared in the CDC 160A's memory.
I did say "mostly". The CDC 161 documentation indicates there are three ways to terminate input (which the docs refer to as an "Input Disconnect"). The first is to fill the memory area the program is trying to read. The second is to momentarily move the right-hald switch on the CDC 161 console from the middle ("NORMAL") position to the down ("MANUAL") position. Both of these work, of course, as they have nothing to do with my emulator.
The third way is to position this switch in the up ("AUTO") position. This enables logic in the CDC 161 to automatically generate an input disconnect when the user presses the Carriage Return button on the typewriter. This did not work.
At first the reason seemed simple. When the emulator received an ASCII CR character (hex 0D) I was sending a Computeriter Carriage Return character (octal 045) through the TC lines and asserting TCC. The CDC 161 logic wasn't looking for this; it was looking for the CR switch contacts to change state. This required only a small change in the keyboard software to fix. Or so I thought.
When a carriage return is sent to the emulator, the emulator's CR relay switches state for 40 milliseconds then returns to its normal state. The CDC 161 recognizes this as a carriage return and sends the Computeriter CR code (octal 045) to the CDC 160A memory, but it does not send an Input Disconnect to the CDC 160A. That happens when the next character is entered, and that character appears to be lost. I can't believe this is the intended behavior.
Why doesn't Auto Input Disconnect work?
I'm not really sure yet what's causing the Input Disconnect to be delayed. Here's my current hypothesis:
When a switch in the Computeriter is actuated, the normally-closed contacts open first. Then, a short time later, the normally-open contacts close. When the switch is released, this process is repeated in reverse: first the NO contacts open, then the NC contacts close. That's the behavior I assumed I'd see with the LCC110 solid-state relay.
I woke up early one morning with the idea that maybe the LCC110 didn't emulate an electro-mechanical SPDT relay very well. I already knew that it had deficiencies, like having an on-state resistance of about 35 ohms. What if it had other issues? To find out I did some tests with an LCC110 in my home lab.
With no current flowing through the LCC110's LED, the normally-closed circuit conducts and the normally-open circuit does not. With current flowing through the LCC110's LED, the reverse is true: the normally-open circuit conducts and the normally-closed circuit does not. All fine and good. What about the transitions?
As the current stops flowing through the LCC110's LED, it takes about 400 microseconds for the normally-open circuit to stop conducting. Another 150 microseconds later the normally-closed circuit begins to conduct. Much like a mechanical switch, there is no overlap.
As current begins flowing through the LCC110's LED, nothing much happens for about 150 microseconds. Then
both circuits begin changing state simultaneously. This results in a period of about 100 microseconds when both circuits are conducting to some extent. What would that mean to the CDC 161's logic?
These switch contacts connect first to an input circuit that converts the voltage swing from "line" levels (-0.5V and -16.0V) to "logic" levels (-0.5V and -3.0V). The logic level signals then connect to the "SET" and "CLEAR" inputs of a simple flip-flop made of two NOR gates. With this sort of flip-flop, if both inputs are "1" at the same time, both outputs are "0". That's normally considered an erroneous state, and that's exactly what having both relay circuits conducting might cause.
And then the power went out
It was time to see if this hypothesis was true or not.
Each of the printed circuit cards that make up the CDC 161 plugs into a backplane. In an era when electronics weren't as reliable as they are today, ease of servicing in the field was key. Most of the logic cards have test points near the exposed end of the card, where they can be accessed without removing the card from the chassis. However, accessing them requires opening the back cover of the chassis.
On my next visit to the museum I pulled the CDC 161 unit further from the wall it was near so I could open the back and connect an oscilloscope to some logic cards. Turning the system on, though, resulted in the CDC 161 shutting itself down immediately. Probing the outputs from the unit's power supply showed it would turn on for about a half-second, then turn itself back off. Why?
Studying the documentation revealed the power supply has an internal overvoltage detection circuit. When the voltage across the +20V and -20V outputs (normally 40V) approaches 60V, a relay pulls in. This relay pulls in a second relay, and the second relay cuts the AC power to the power supply and latches itself on. Turning off the AC power externally allows the second relay to reset. This matched the symptoms I was seeing.
But why?
