We’ve been restoring a Xerox Alto from the 1970s for several months, and we finally got it to boot and run some programs!
There’s still some hardware debugging ahead of us, since the Alto drops into the debugger for many programs,
but we’re quite happy to see the system running. In this post, I describe our latest debugging session and show some programs running on the Alto.
For background, the Alto was a revolutionary computer designed at Xerox PARC in 1973
to investigate personal computing. It introduced the GUI, Ethernet and laser printers to the world, among other things.
Y Combinator received an Alto from computer visionary Alan Kay and
I’m helping restore the system, along with
Marc Verdiell, Luca Severini, Ron Crane, Carl Claunch and Ed Thelen.
For posts on previous restoration days see parts
In an earlier session,
we discovered that our boot disk had been used for drive testing decades earlier and was filled with random garbage, making it impossible to boot from the disk.
Fortunately, the Living Computer Museum in Seattle sent us a new boot disk, loaded with diagnostic software. I received a vintage Digital RK05K-11 disk cartridge box:
Inside the box was the 14″ disk. Despite its size, the disk cartridge only hold 2.5 megabytes, a tangible indication of the exponential improvements in disk density since the 1970s.
We loaded the disk into the Alto’s Diablo drive, waited a minute for the disk to spin up to speed and the heads to load, and Ed eagerly pressed the reset button. Would we be lucky and successfully boot the Alto? After all the anticipation, nothing happened.
Since we had successfully loaded a disk sector (of random data) earlier, we knew that the system was working end-to-end, from the drive through the disk interface card and into the processor boards and memory.
One possibility was that the alignment was different between our drive and the Living Computer Museum’s drive, corrupting the data. Needing to hand-align our drive would be very difficult, so we hoped that wasn’t the problem.
To see the words as they came off the disk, we added more logic analyzer probes to the Alto’s backplane to trace the processor bus. At this point, the backplane is liberally decorated with probes, allowing us to monitor the buses and microcode execution in detail.
Using the logic analyzer, we could step through the microcode to see each disk word getting loaded into memory, but the data didn’t match the boot sector we expected.
The Alto stores each sector on disk as a 2-word header (holding the disk address), a 10-word label (holding a next block pointer), and the 256-word data block. Although the data seemed wrong, more interesting was the octal value 000100 in the header coming from disk. (The Alto uses octal, causing us no end of confusion.) This header value corresponds to a disk address of cylinder 8, not the boot sector 0. Could we be reading the wrong sector?
By removing the cover from the Diablo drive, you can watch it seek. Unlike modern hard drives, the Alto’s disk isn’t sealed so you can see the disk surface and head when the disk is loaded in the drive.
Watching the drive as the Alto attempted to boot, we saw the disk arm seek, which it shouldn’t have done to read from boot sector 0. The seek dial rotated to cylinder 8—as the logic analyzer suggested, the Alto was trying to boot from the wrong disk cylinder, which clearly wouldn’t work.
Since the drive seeked correctly last week, why was it trying to read from the wrong cylinder today? Were we suffering another chip failure on the disk interface card? Had something malfunctioned in the drive? We
pored over the disk interface schematics and suspected a problem with the nine cylinder select lines between the Alto and the drive. In particular, a malfunction in the CYL(5) line could set the cylinder to 8, causing the seek we saw. (Bits on the Alto are inconveniently numbered backwards, so cylinder bit 5 corresponds to the value 8.)
We noticed a scratch in the 40-conductor ribbon cable between the Alto and the disk drive, exposing a wire. Could this be the cause of our problems? We carefully checked continuity and found no problems with the cable despite the scratch, so we hooked the cable back up along with an oscilloscope to monitor the offending signal, so we could debug the problem.
We tried booting the Alto again, watching for the seek problem. This time the disk unexpectedly performed multiple seeks. And then the boot screen appeared on the Alto. We had a running system!
A few months ago, I had used the Salto simulator to see how the Alto worked.
But now, facing a working system, I couldn’t remember the commands.
To see the files, was it LIST, or DIR? No. How about HELP? No good. After a minute or two, I remembered that a simple question mark was the command to list the disk, and I got a list of files.
The system was working well enough to read a directory.
I tried running the WYSIWYG text editor Bravo and the mouse-based drawing program Draw, but they crashed, dropping the system into the debugger, Swat.
Clearly some hardware problems remain and our debugging adventure is not over yet.
Some programs ran successfully. The CRT test program drew grids on the bitmapped screen.
The CRT is a bit fuzzy in the upper left, but the quality is surprisingly good considering that this tube was almost too dim to see a few months ago. Apparently running the tube a while restored it by burning contaminants off the cathode (or something mysterious tube-era phenomenon like that).
The Ethernet diagnostic program ran and showed off the mouse-based GUI. I’m developing a BeagleBone-based Ethernet simulator for the Alto, so this program will be very helpful. We don’t have a gridded optical mouse pad, so the mouse didn’t work and we couldn’t click anything.
The keyboard test program graphically displays the keyboard and shows each key as it is pressed. We used this to verify the keys all work.
It was an exciting day, with the Alto finally booting successfully.
A disk seek problem blocked us for a while, but then the problem mysteriously disappeared.
We ran a bunch of test programs from the disk. About half of them ran successfully,
and half crashed into the debugger. There may be a malfunction in the processor that we need to track down. Or perhaps we’re getting memory errors; the parity errors we saw earlier could have returned.
In any case, we have some more debugging ahead of us, but it’s exciting to see the system finally running.
Hopefully we will soon be playing Alto Trek and
For updates on the restoration, follow me on Twitter at kenshirriff.
Thanks to Josh Dersch and the Living Computer Museum for their debugging help and sending out the boot disk.