23 Sept. 2009
It's 1970 and I'm a 25-year-old Junior Engineer (no degree, a Berkeley dropout for now) at the Special Products Division of Ampex Corporation. I have a desk out on the floor of an open area used for staging systems and equipment – the “bull pen”. I earn a little over $6 and hour and I wear a suit and tie to work.
My responsibilities are “maintenance of product design” for the computer interface electronics of the “Pyramid” system – a “programmed instruction” system meant to be installed in a university, that delivers illustrated lectures on demand to students and which can respond to students' keystrokes on a touch-tone type keyboard.
Each lecture is actually recorded on 8-track tape, and the tape can stop when a question is asked, wait for a response, and move to another place on another track to deliver an appropriate response, most of which end up back at the original question. If the right answer was given, the tape continues on its original path. This is known as “branching” and it's supposed to be the coming thing in programmed instruction.
The logic for all these responses is handled by a small computer built to be installed as part of an industrial system. Known as a “minicomputer” this one is the Data General Nova 1200. It's a box that can be mounted in an industry standard 19-inch-wide rack. The outside world connects to it through multi-pin connectors on the back panel.
I own the “I/O” (Input/Output) box that Special Products built. It has a cable going to the computer back panel and contains a number of circuit boards performing various functions – some receive data from the keypads, some send out control signals to the tape drives, and some – the tone detectors, listen to audio playing to the student and decode bursts of 55-Hertz (cycle per second) waves added into the audio stream when the tape was mastered. These bursts - using a method similar to Morse code - cue the computer that an event is ready to happen and tells it what should be done. So when the tape stops after a question is asked, that's how the computer knew when to stop and what responses to give.
The design of the tone detector was beyond my capabilities, using magic known as “active filters” to selectively amplify narrow bands of frequencies, but I only have to deal with circumstances in which it doesn't work and fix it. Soon enough one such circumstance brought itself to our attention.
The prototype system was installed in a community college in Oak Park, Illinois, and the tone detectors were misbehaving. An engineer named Jim Ferguson was sent out to find a fix, and he returned with a tone detector board to which a piece of cardboard had been added as an extension. On this cardboard were two adjustable resistors (“potentiometers” or “pots” in the terminology) and some other components connected to the board circuitry to allow the adjustment of certain delay timings.
Ferguson, quite full of himself, was telling everyone repeatedly how he had adjusted the board operation just so. I was less delighted, since the specifications for the board called for no such adjustments, but I was instructed by management to incorporate the new adjustable pots in a new version of the design, and so I did.
When we tried the new board out at our development system it didn't work. Now the problem was mine. I finally found the cause of the problem after what seemed to be weeks of frantic effort (but was probably only a few days), by using an old paper chart-recording oscillograph – a device which has been totally rendered obsolete by digital oscilloscopes now.
On the chart I could demonstrate that when the burst of 55-Hz tone began something was shocked into a kind of oscillation and the audio signal began sloshing up and down at a very slow rate – about 1 Hz. You couldn't just define a signal level for the 55-Hz bursts at which the comparator said “this must be a filtered and amplified signal at 55 Hz, so I will start a digital pulse marking the event”. The reference level used for comparison was bouncing up and down at the 1 Hz rate.
Further investigation revealed the culprit – the master tape recorder on which the program materials were created. Each system had exactly one of these – a studio-quality model AG-440 tape recorder from Ampex's distinguished studio product line. Unfortunately, Oak Park had a different model number, which had different response characteristics from ours.
When asked about the anomalous performance of the master recorder an audio engineer would say “Who cares what the recorder is doing at those low frequencies – they'll never get through the channel and do any harm!” (High fidelity audio was considered to end at 20 Hz in the low direction) And this sloshing behavior to the equivalent of incredibly loud, incredibly low-frequency disturbance was no doubt the byproduct of some clever engineering that was quite effective at higher frequencies. “Bump and thump” percussion effects were still decades away.
I knew that, unless we were going to tune the adjustment of the tone detectors to the specific master recorder used at the site of each system we could never get it working reliably. And what would happen when a different master recorder was used some time in the future – resulting in a mix of programs with different baseline shift characteristics!
I reached the conclusion that we had to do something in the tone detector that would straighten out the sloshing effect and adjust for inevitable variations in level that could be expected in the future. This meant AGC – Automatic Gain Control. I set about trying to modify the design to include this feature.
For several weeks I continued to develop the AGC solution, but support was not forthcoming from management. I would stand up in the weekly review meeting and tell how I was still trying to finish the AGC version and would be told – in front of all the engineers present - “never mind about that – freeze the design the way it is.” After two such episodes I relented, and three other Pyramid systems were shipped with tone detectors that were invitations to trouble.
Two years later, after having returned to Berkeley and finishing my degree, I returned to check in with the guys who were left (Ampex was undergoing a long and painful contraction phase, which has lasted to the present day) and see what the outcome had been. During my last few weeks on the job the Pyramid system had been passed over to something called the Videofile Division, who had been trying to use videotape recorders to store and retrieve huge amounts of digital data.
My former colleagues told me that the solution to the tone detector problems had been to add AGC. I looked at the schematic diagrams to better understand what had been done and saw the name of the responsible engineer – one Al Alcorn. I had never heard of him.
Two years after that I found myself standing in front of Al Alcorn's desk asking for a job at his new company, Atari, of which he was Vice President for Engineering. He had gone with a fellow Videofile engineer named Nolan Bushnell and the two had founded what became the first coin-op video game company, with a winning product called Pong, designed by Alcorn.
I tried hard to explain why the tone detector debacle hadn't been my fault, but Al was not interested. He was looking for manufacturing engineers, not designers like me. I didn't get a job at Atari. The young man who had pre-screened me and escorted me into Al's office, wearing a white shirt and tie, turned out to be Steve Jobs before his India sojourn. I think I left on my own.
In retrospect I don't see what I could have done differently, other than trying to build political support within Special Products for my AGC conclusion. But short-term thinking ruled there as it does in many other places in Silicon Valley, a valley that's a lot smaller than it seemed. “Don't worry about that”, indeed!