The Adventure of the Computer that Wouldn't Boot

Two EE grad students triumph over a group of physics majors when a minicomputer goes down.

By Bob Colwell, Contributing Writer

Two of the cool things about a PDP-11 minicomputer were its front panel lights and switches. You could tell when the machine was running versus when it was crashed, and if you were really good, you could often tell what program was running by the pattern of the lights. And with the switches, you could write or read memory directly, no running software required.

When I was a grad student at Carnegie-Mellon in 1978, my MSEE project was a digital music synthesizer built around a digital oscillator controlled by a bit-slice 16-bit controller, shown in the photo below. (I’m the guy with the Carnegie-Mellon t-shirt posing proudly here with my cohort Paul Rodman.)

Back view of Bob and Paul’s digital synthesizer.

This controller would interface to the laboratory’s PDP-11/45 minicomputer for the music program and the controller’s microcode. PDP-11’s were expensive, so Paul  and I had to share it with several other groups, including a group of physics grad students.

One day we came into the lab to find the physics students standing mournfully around the PDP-11. They informed us that the machine would not boot, that the service person had been called, but the machine would likely remain down for the next two weeks. They sadly shuffled out of the lab.

Paul and I quickly verified that the machine would not, in fact, boot, but it wasn’t completely dead, either. When the reset button was hit, the lights would flash a while, but then stop in a particular pattern. We looked in the PDP-11 book and found that the pattern was a memory address, always the same one. We realized that address was where a handler for a memory parity error would go, if there was such a handler present.

After pondering that for a moment, it occurred to us that if the machine was running a memory test, and found a memory parity error at some location, the odds were one in eight that it was the parity bit itself that was wrong. And even if it were a real data bit error, maybe it was in a memory address that we didn’t care about. If we could just get the machine to keep booting despite that parity error, maybe it would still be useful.

So we looked up the machine code for a “return from interrupt” and keyed it into the location where the machine was halting. Presto, the PDP-11 now booted and ran just fine, and better yet, we were the only students who knew how to bring it up, so we now had two weeks of unlimited time on it.

The machine was repaired a week later, but several weeks after that we came into the lab to find the same set of glum physics students, who had the same story as before. This time, the machine would boot to the point where it needed to access the hard drive, and there it would halt. After some sleuthing, it became clear that the problem was in the drive itself - it had a battery whose sole job was to provide power to yank the read/write head off the disk if wall power was lost, and that battery had died. With no battery, the disk drive refused to boot.

The battery was, of course, an extremely expensive custom job requiring a service call. Which was all the incentive we needed to solder a few batteries together, solder wires to the ends, tape the whole thing with electrical tape, and connect that assemblage into the disk drive. It didn’t fit, so it hung over the side of the drive looking thoroughly disreputable. But it worked! This time, we didn’t try to hide our cleverness from the physics kids, so we only got our usual allotted time, but we felt very virtuous and superior. And a week or two later the service person replaced it with the real thing. But I’ve always wondered what he or she thought of our handiwork; did they think “I have GOT to send my kids to this school” or more likely “They do not pay me enough to do this job.”

Contributing Writer Bob Colwell was Intel’s chief x86 architect in the 1990s and has worked as a computer designer at VLIW pioneer Multiflow, Perq Systems, and Bell Labs. Author of The Pentium Chronicles and the At Random column in Computer Magazine 2002-2005. He is currently an independent consultant. The digital synthesizer he built in grad school is still in his garage.