The Fonly Institute

Small Valley

Small Valley

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!

What Engineers Sometimes Must Do

The year was 1970, and I was a Junior Engineer at the Special Products Division of Ampex Corporation in Redwood City California. I had applied for a job as a technician after dropping out of Berkeley in a depressive crash, but with my work experience while in school I was routed to a job that was sort of a combination of technician and engineer. 

Special Products, as its name implies, was the place where oddball jobs came to be done. We had to be able to design and build almost anything, and the division was tiny by Ampex standards. I learned the craft of engineering there, and consider myself quite lucky to have wound up there. 

In 1970 we were building the "Pyramid System" - a contrived acronym referring to a system for delivering illustrated audio lectures on a college campus and allowing the lectures to take various branches in response to the students' responses on a numeric keypad. Today it could be handled by a DVD player with a keyboard, but then it required racks ands racks of equipment installed in a basement room and wired to multiple locations around campus. 

A system like that had to be controlled by a computer, and we were using the Data General Nova 1200 - a box with maybe 16K of 32-bit magnetic core memory, a panel with switches and lights and a number of connectors on the back. One of those connectors was the "I/O bus" - the means by which external electronic equipment could be placed under control of the computer. The architecture of the Nova I now consider to be rather inferior for reasons I won't go into here - back then I knew no better. I was placed in charge of "maintaining" the design of the external interface electronics - a job no one else wanted.

We had a demo room in our building - the largest conference room available in which the system was being staged. Our software guys worked in there putting together the machine code that would make everything run. They used a Teletype Model 33 as a terminal, connected by another plug to the back of the Nova. 

When prospective customers came to visit they were first received in a front conference room and told the wonders they would behold. Then our engineering manager, Maynard Kuljian, would conduct them back through the doorway labeled "Engineering" to the demo room. Far too often the system would crash as soon as they entered the room. I remember Ray, one of the software engineers, softly crying out "Wha' hoppen'?" as the disaster struck, as always at the worst possible time. Maynard would have to take the visitors back out and entertain them for another half hour while Ray and others scrambled to re-load the software. I would retreat to my desk out in the bull pen and try to stay busy.

Eventually Maynard made a hard decision. He would not go back to the demo room with the clients, but would send them in someone else's charge. Somehow, he figured, he was the cause of the crashes. And apparently it worked! The crashes ceased!

That was engineering at work. In a process far older than science, one takes a guess as to what might work and tries it. The question of "why" is irrelevant (though possibly useful) - the operative question is "how". If the "why" is supernatural, that's fine, as long as the effect is consistent for as long as it's needed. And it was.

For two years I worked on that system, while Ampex began a long, slow process of contraction. Six years later I sought out Maynard and tried to recruit him to be engineering manager of the personal computer company I was helping. He turned me down - he was much happier, he said, working on building products than on the management track.

So when you look at engineers at work, don't think that they are all so very smart. Sometimes they're just foolhardy - and lucky. But you'll never know when that is.