Computeriter Emulator Software Design

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?

Computeriter Emulator Hardware Design

As described here, the System Source Computer Museum asked me to build an electronic replacement for the non-repairable Soroban Computeriter used with the recently-acquired CDC 160A computer.

Computeriter Electrical Interface

This drawing from the Soroban Computeriter Coder Unit Technical Manual shows the underside of the Computeriter.

The electrical interface to the Soroban Computeriter can be viewed as three mostly-independent blocks:

• A mechanical "coder unit" that encodes printing characters
• Switches that signal non-printing functions (space, carriage return, shift, etc.)
• A "decoder unit" that allows a computer to drive the printing mechanism

Let's look at each of these separately.

 

Coder Unit Interface

Here's the connection diagram for the Coder Unit connections, taken from the CDC 161 Typewriter Unit documentation.

 Each of the TC1 through TC6 contacts encodes one bit of the 6-bit Computeriter character set. Since these are mechanical switches, some will close before others and all are subject to bouncing. The TCC contacts change state after the TCx switches have settled to indicate they can be read. 

Here's a drawing from the Soroban documentation that shows the timing:

 

Non-printing Function Switches

Rather than encode the non-printing functions, the Computeriter uses separate switches to signal when the user presses the keys. These include the space bar, the tab key, the backspace key, the carriage return key, and the shift key. An additional switch signals when the inked ribbon advances, which it does for each character typed.

The function of some of these switches is obvious: press the space bar, and the "Space Cam" switch will change state briefly. Others are not so obvious, like the difference between the "Shift Cam" and the "Upper Case Lever"; by experimentation I determined that the "Shift Cam" switch changes state momentarily when the shift button is pressed or released, while the "Upper Case Lever" indicates the current position of the type mechanism. Since the "Ribbon Feed" and "Tab Cam" switches are not used by the CDC 161 I didn't investigate their operation.

You might ask why these switches are SPDT (single pole, double throw) rather than a simpler single contact SPST switch. The answer is that these are connected to simple Set/Reset flip-flops which serve to debounce the contacts. The first closure of the normally-open contact sets the flip-flop, and all subsequent bounces of that contact do not cause the flip-flop to change state. When the switch returns to its normal position, the normally-closed contact resets the flip-flop.

I mentioned in the previous post that one of the switches is both a logic input and illuminates a bulb. That's the right-hand contact of the DPDT switch at the bottom of the drawing, connected to pin 34 of the DD-50 connector.

This drawing also contains an error. Have you spotted it? It's literally impossible for the common contact of the DPDT switch to connect to the right side of the DD-50P connector, as the switch is part of the Computeriter while everything to the right of the DD-50 connector is part of the CDC 161 electronics. Thus the common contact must be connected to pin 50 of the DD-50.

 

Decoder Unit Interface

The decoder is a mechanism that can activate any of the typewriter keys through seven small solenoids. Six of the solenoids (TM1 through TM6) select which key will be activated, while the seventh (TCM) triggers the action.

A SPDT switch (TBS) indicates that the action has taken place, and the Computeriter is ready to print another character. An additional switch disables printing at the right edge of the platen.

 

 

Mission: Emulate a Soroban Computeriter

In the early 1960s a company called Soroban Engineering produced a product they called a Computeriter. This was an IBM electric typewriter, modified with an electro-mechanical encoder to allow a computer to sense what keys on the keyboard had been pressed, and solenoids to allow the computer to operate the keys to print text.

This photo is taken from a Soroban technical manual, available on the Bitsavers archive here. It shows the IBM typewriter and the coder and decoder modules Soroban added to create the Computeriter.

Although not as heavily built as the Teletype machines of the day, the Computeriter could print 26 upper case and 26 lower case letters, ten digits, plus 24 special glyphs. This is the device Control Data Corporation (CDC) chose as a base for their CDC 161 Typewriter Unit for the CDC 160 computer.

Unfortunately, the Computeriter in the System Source Computer Museum's CDC 161 is badly worn. A typewriter restoration expert brought in to consult advised that attempting to refurbish the most badly worn part, a drive roller, would cost over $1,000. Even then, he said his experience was there was only a 50% chance that the refurbished roller would function properly. So the museum management decided to replace the electro-mechanical Computeriter with a custom electronic device that would allow the use of a more modern terminal or laptop computer with the CDC 161 electronics.

What have I been up to?

Last summer I came across my somewhat tattered copy of the PDP-11 Processor Handbook. This dates to my first job as a software engineer in the early 1980s for EMC Controls. EMCC was a process control system manufacturer whose products ran everything from bakeries to steel mills to the Trans-Alaska Pipeline. A descendant runs the ventilation systems for some of Boston's road tunnels.

I got hired there because they used Intel 8080A microprocessors in their EMCON-D2 process loop controllers, and a friend of mine who worked there knew I knew a lot about the 8080A. My first day I was informed they didn't have an immediate need for work on the 8080A software, but would I like to do a sysgen on a PDP-11/44? I replied, "What's a 'sysgen'?" I never touched a single line of 8080A software in the two years I worked there, but became something of an of an expert on the RSX-11M-Plus operating system.

My first big project was the continuous annealing line for Bethlehem Steel in Burns Harbor, Indiana. It used a PDP-11/44 as a supervisory computer, which ran a mathematical model of the system to update process loop controllers. My second big project was porting the company's EMCON-D3 software to a VAX-11/750 running VAX/VMS. It was my knowledge of RSX and VMS gained at this job that guided my career through 1999. But that's a story for another time.