The Universal Interface: Parallel I/O

Born of nuclear fire

Mike Kolesar

In the early 1970s, Mike Kolesar was working on his PhD at Cornell in the synchrotron group at the university’s department of nuclear physics. Kolesar earned his BS in physics at Villanova University in 1968 and then went to Cornell for his advanced studies. He became part of the team using the 10GeV (10 billion electron volts) synchrotron to fill out tables of predicted but yet-to-be-discovered particles. There are two kinds of physicists: theoretical and experimental. The theoretical physicists study and predict the nature of the universe. They only need paper and pencil (or chalk and chalkboard) for their work. A computer helps too. Experimental physicists confirm the theoreticians’ theories, or don’t, depending on the outcome of their experiments.

When Kolesar arrived at the 10GeV synchrotron lab, experimental data acquisition consisted of a hydrogen cloud chamber and film cameras. Nuclear particles created by hurling 10GeV electrons at targets would zip through the cloud chamber and leave tracks of bubbles as they hurtled through. Three film cameras would record X, Y, and Z views of the bubble tracks and then the film, once developed, would be manually digitized with pantographs to produce 3D models of the tracks. The process of developing and digitizing the film took many hours so the time required to conceptualize one experiment from the previous experiment’s results was relatively long.

The synchrotron lab needed a real-time way to show experimental results so that the synchrotron could be quickly tuned to produce the desired particles. The task of creating such a real-time acquisition and display system fell to Kolesar. He had relatively new PDP-11 minicomputers from Digital Equipment Corp (DEC)—first manufactured in 1970—available for the task. The PDP-11 was DEC’s fist 16-bit minicomputer and it was an immensely successful machine. One of the reasons for its success was DEC’s development of the Unibus, a well-conceived, well-designed, well-documented asynchronous computer bus that allowed relatively easy interfacing with external devices. Cornell’s synchrotron lab needed a lot of external devices.

The idea was to replace the cloud chamber and cameras with multiple wire sieves. Each sieve consisted of a 1-meter by 1-meter frame. Within each frame were 2000 fine metal wires strung in parallel using ½-mm spacing. The wire frames were then stacked with alternating directions for the wires: one frame would orient the wires vertically, the next horizontally. This arrangement of “stack planes” created a 3D grid through which the nuclear particles would travel. If the particle hit a wire, it would electrically charge the wire and this charge could be latched using a 1-bit latch for each wire. Many thousands of latches were required.

Kolesar designed electronic crates, which held dozens of circuit boards. These crates expanded the PDP-11’s bus so that it could read the state of the thousands of latches that reported on the state of the wires. From the latched 3D data, the PDP-11 could save the experimental results (“gazillions of bits” says Kolesar) on 9-track magnetic tape—driven by the PDP-11 through a tape formatter that Kolesar designed and built—and could then reproduce the 3D paths of the nuclear particles in the experiment. That took care of the data-acquisition portion. Kolesar also wrote display routines so that the PDP-11 could display the 3D paths on a Tektronix storage/display tube.

Using this massive data-acquisition system, experimental physicists could see their experimental results in real time. They could literally sit in a chair in the synchrotron’s control room with a rheostat in their hand and tune the deflection voltages within the synchrotron to produce the desired particles. This is an early example of closing the process-control loop using a computer to speed process optimization.

The unbroken circle

The PDP-11 wasn’t Kolesar’s introduction to computing. While he was still in high school, Kolesar was picked to participate in an advanced electronics program at the Moore School of Electrical Engineering at the University of Pennsylvania. This is the same place where Stanley Frankel had been the first to program ENIAC for the Manhattan Project. At the Moore School, Kolesar learned to program on LGP-30 computers, which had been designed by Stanley Frankel in the 1950s. The LGP-30s were quite possibly the first personal computers ever developed. Frankel’s subsequent design of a calculator was a key factor that drove Tom Osborne out of SCM (Smith Corona Marchant) and into the arms of Hewlett-Packard with his own calculator design. Osborne’s prototype calculator became the HP 9100A, introduced in 1968.

By the early 1970s, two HP 9100A calculators arrived at Cornell’s Department of Nuclear Physics and Mike Kolesar learned to program them as well and was fascinated by the diminutive proto-computers. In addition, the CRT display of one of the calculators began to dim and Kolesar was amazed when the HP repair technician arrived and replaced most of the boards in the calculator. Kolesar remembers admiring a company that gave that much attention to customer service. “I’d like to work for them,” he thought.

Then HP introduced the HP 35, the world’s first pocket scientific calculator, which also had Tom Osborne’s fingerprints all over it. The HP 35 “bowled everyone over” at the Department of Nuclear Physics says Kolesar. It was yet another way that HP drew Kolesar into its sphere.

By 1974, Kolesar was an ABT (All But Thesis) PhD candidate and he decided that instead of spending several more years as a doctoral candidate, he’d prefer to go and make some money. “I/O is fun,” thought Kolesar, “I like doing this sort of thing.” Kolesar wrote a Master’s thesis on his data-acquisition work at Cornell’s Department of Nuclear Physics, got his Master’s degree in physics, and then went interviewing for a job. He visited several companies including DEC, IBM, and HP. He ended up with six job offers in Colorado alone.

The offer he chose: the one from HP’s Calculator Products Division in Loveland, Colorado—the home of the HP 9100A desktop calculator and the future home of the HP 9825A desktop computer. When Kolesar arrived at HP in Loveland, he was asked what he wanted to do. “Got I/O?” he asked.

Yeah, we’ve got I/O

By the time Kolesar arrived at HP in 1974, some preliminary thought had gone into the HP 9825A’s I/O backplane, but the way the desktop computer’s I/O cards would work was still largely unplanned. The basic operation would be defined by the mechanisms built into the computer’s hybrid processor, namely the protocols designed into the hybrid’s IOC (I/O chip). However, the full protocols were yet to be defined. Kolesar set out to define them.

He started by building a hardware I/O backplane simulator, because the hybrid processor wasn’t yet ready. To achieve this task, Kolesar eagerly adopted the state-machine design techniques that Tom Osborne had developed. However, Kolesar learned the techniques from the book “Designing Logic Systems Using State Machines” written by HP’s Chris Clare, which had become HP’s bible for hardware-design engineers. “I ate it up” said Kolesar.

This cartoon for the HP 98032A parallel I/O interface card appeared with the article on parallel interfacing techniques that was part of the article series called “Leibson on I/O.” The cartoon appeared in HP’s Keyboard magazine.

In parallel with the I/O backplane simulator, Kolesar started to develop the HP 98032A parallel I/O card, the most basic and most essential I/O card in the HP 9825A I/O card family. The HP 98x0 desktop calculator family (HP 9810, 20, 21, and 30) had accumulated a large number of parallel I/O cards used to connect the calculators with a wide variety of peripherals including printers, plotters, paper-tape readers and punches, and a digitizer. Each new peripheral required a different I/O card. Kolesar realized that he could be clever. He could create one universal parallel card that could be easily adapted for all current and future peripheral devices by creating a sufficiently general and flexible design without significantly increasing the I/O card’s manufacturing cost.

The first I/O card to be developed for the HP 9825A was this HP98032A Parallel I/O card, designed by Mike Kolesar. The card’s unusual shape arises from the mix of requirements to plug into the back of an HP 9825A, to accommodate enough circuitry for the intended I/O functions on the two internal printed-circuit boards, while matching the sleek HP 9825A industrial design created by Leroy Lacelle.

The resulting design, called the HP 98032A (Project Parsley), could perform 8- or 16-bit input and output transfers using a variety of commonly used handshake protocols to move data between the I/O card and an attached peripheral device. The configuration was set using a plug-in configuration card built into the back shell of the I/O card. By changing the cable, the connector, and the configuration card, the HP 98032A could (and did) replace all of the various parallel input and output cards developed for the HP 98x0 calculators.

At the same time, Kolesar had to refine the protocol used between the HP 9825A desktop calculator and the I/O card. That’s not as simple as it sounds. Although the basic synchronous hardware-handshaking mechanism and register-based transaction protocol had already been established by the design of the IOC, the meanings of the various registers were as yet unassigned. Kolesar set out to define them and he had help from Dr. John Nairn.

Dr. J becomes part of the unbroken circle

John Nairn got a BS in Chemistry at Regis College in Denver. He wanted to continue his studies and eventually wanted to earn Masters and PhD degrees so he went to Rice University in Houston where he studied organic chemistry, physical chemistry, chemical physics, and mathematical physics. By that point, Narins was no longer a chemist. He was a physicist and his PhD thesis was on the theoretical calculations for hard-sphere models of gases. Those are the calculations that Stanley Frankel had helped physicist Bernie Adler study back in 1948. Those are the calculations that led Adler and Frankel to develop Monte Carlo simulation (independently of Nick Metropolis, Edward Teller, and their compatriots, who usually get the credit). Monte Carlo simulation is now a pervasive computing technique throughout the scientific and industrial world.

Dr. John Nairn

Back in 1948, Frankel had to travel to Manchester, England so he could work on what was then the world’s most powerful computer, the Ferranti Mark 1. It was the world’s most powerful computer chiefly because, at the time, it was one of the world’s only computers. When Nairn tackled the problem, in the late 1960s, the situation was different. In late 1956, three Rice professors (Zevi Salsburg, John Kilpatrick, and Larry Biedenharn) had decided to build a computer at Rice “like the ones at Los Alamos.” The result was called the R1, which first became operational in 1961 but evolved throughout the 1960s. In the mid 1960s, hardware support for performing Monte Carlo analysis was added and this is the machine that John Nairn used in pursuit of his PhD in Physics.

The R1’s arithmetic unit was built from vacuum tubes. It had magnetic-core memory driven by solid-state memory-control circuity. Storage was on two big, fast hard disk drives. User I/O and program storage was through a Frieden Flexowriter, a peripheral that merged the functions of a typewriter, a paper-tape reader, and a paper-tape punch. The R1 wasn’t actually the first computer at Rice; it was the second. The first computer was one of Stanley Frankel’s LGP-30s, shared by the university’s mechanical and chemical engineering departments, which also happens to have used a Frieden Flexowriter for user I/O.

Nairn got his PhD in 1971. There was a recession in the US at the time and no one was hiring physicists. However, like many physicists, Nairn had been sucked into computing. While working on the Rice R1, he’d developed a lot of code including major upgrades to the machine’s operating systems. Nairn capitalized on these skills, returned to Denver, and got a job with a Wang sales office. Wang, a key competitor to HP in the calculator market, was trying to sell calculators to automobile dealerships at the time. Nairn developed a program for Wang calculators that could print out a full order on a 1-page sales sheet using extensive formatting commands. It was a far cry from developing operating systems on the R1, but Nairn couldn’t find a way to leverage the Denver job into a job at Wang’s headquarters in Tewkesbury, Massachusetts.

Then serendipity struck. On a reconnaissance mission, Bill Cummings and Ivar Larson came down from HP Loveland’s marketing department for a demonstration of Nairn’s work. They liked what they saw and they stole Nairn away from Wang to develop application programs for the HP 9810A and 9820A desktop calculators. However, when he arrived, Nairn got a different task. Homer Russel had written a math package for the HP desktop calculators. It included routines for statistics and root finding using the Newton-Raphson method. Unfortunately the package was buggy and Russell had left HP. Nairn’s first job was to fix the bugs in Russell’s code. Unfortunately, Russell had used every available bit on the magnetic card used for program storage of the math package. There was no room for a code patch.

Nairn found a way to fix the code anyway, using code-compacting skills he’d need again, and soon, on the HP 9825A project’s I/O ROM. He solved the code-space program by writing another program that scanned code for recurring 3-byte program sequences. If the program found three or more of these sequences, Nairn could shrink the code by making the sequence into a subroutine and replacing the instances of the identified sequence with subroutine calls. In this situation and at that time, the summer of 1972, memory and code efficiency were far more precious than speed. This situation would remain true until the 1980s and the advent of 32-bit microprocessors and large dynamic RAMs.

Chris Christopher

After fixing Russell’s math package, Nairn went on to write some application packages on his own including an expense/budgeting program. He spent a year and a half in the marketing department at the Desktop Computer Division. Then, one day, Chris Christopher came into marketing looking for warm bodies. Christopher was the software project leader for the HP 9825A’s ROM operating system and language interpreter. He was behind schedule and needed anyone who could write code to help meet deadlines. The main code was already being written by Wayne Covington, Joe Beyers, Jeff Osborne, and others. Christopher needed someone to tackle the I/O ROM. He dragooned Nairn and dragged him off to the R&D department.

“Make it (the HP 9825A) a controller.” said Christopher.

“What’s a controller?” asked Nairn.

“I don’t know. You figure it out.” replied Christopher.

And with that amount of direction, Nairn went off to figure it out.

Click here for the next part of the HP 9825 I/O story.

Mike Kolesar designed these two boards for the HP 9825A’s parallel I/O card, the HP 98032A. Because it was the first of the I/O cards designed for this new generation of desktop calculator/computers, Kolesar had to invent many new circuits to connect to the HP 9825A’s backplane. He used 30 integrated circuits and 16 discrete transistors for this design. These components fit neatly on the two internal circuit boards of the I/O card packaging. Each new I/O card for the HP 9825A was more complex and needed more integrated circuits. As a result, the density of the integrated circuits on the boards climbed and the board outlines expanded so that they completely filled the plastic case of the I/O card.   Information on the I/O pages of this site came from interviews with: Don Morris, Geoff Chance, Chris Christopher, Mike Kolesar, John Nairn, Dick Barney, Larry Smith, Ed Schlotzhauer, and from the memories of Steve Leibson.