Last week our vintage Alto was crashing; we
traced the problem
to an incompatibility between two of the processor boards.
Today we replaced these boards and now we can run all the programs on the disk without crashes.
Unfortunately our mouse still doesn’t work, which limits what we can do on this GUI-based computer.
We discovered that the mouse has the wrong connector; even though it plugs in fine, it doesn’t make any electrical connection.
If you’re just joining, 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
and Ron Crane,
The Xerox Alto was designed before microprocessor chips, so its processor is built from three boards full of TTL chips: the ALU (Arithmetic-Logic Unit) board, the Control board, and the CRAM (Control RAM) board.
The Control board and the CRAM board are the ones that we dealt with today.
Last week we traced through software execution, microcode, and hardware circuitry to figure out why some programs on the Alto crashed.
We discovered that the problem happened when a program attempted to execute microcode stored in the Control RAM.
The microcode RAM select circuit malfunctioned due to some wiring added to the back of the Control board (the white wires in the photo below).
Why had this wiring been added to the board? And why did it break things?
At the end of last episode, we briefly considered ripping out this wiring,
but figured we should understand what was going on first.
A bit of explanation will help understand what’s going on.
Like most computers, the Xerox Alto’s instruction set is implemented in microcode. The Alto is more flexible than most computers, though, and allows user programs to actually change the instruction set by modifying the microcode, actually changing the instruction set.
To achieve this, the Alto stores microcode in a combination of RAM and ROM.
The default microcode (used for booting and for standard programs) is stored in 1K of ROM on the Control board.
Some programs use custom microcode, which allows them to modify the computer’s instruction set for better performance.
This microcode is stored in high-speed RAM on the Control RAM (CRAM) board.
Our Alto came with a 1K CRAM board, but some programs (such as Smalltalk) required the larger 3K CRAM board.
(This microcode RAM is entirely different from the 512 Kbyte RAM used by Alto programs; you didn’t need to fit an Alto program into 3K.)
Inconveniently, the 1K and 3K RAM boards have incompatible connections, and the Control board needs to be wired to work with one or the other.
We determined that the white-wire modifications on our Control board converted it from working with a 1K RAM board to working with a 3K RAM board.
Unfortunately, our Alto had a 1K RAM board so the two boards were incompatible and programs that attempted to use the microcode RAM crashed, as we saw last week.
It’s a mystery why our Alto had two incompatible board types, but at least we knew why the modifications are there.
(Since our Alto also came with the wrong disk interface card and an unbootable hard disk, we wonder what happened to the Alto since it was last used. It clearly wasn’t left in a usable state.)
Fortunately Al Kossow of bitsavers came to our rescue and supplied us with some 3K Control RAM boards and the Control boards to go with them.
This saved us from needing to rewire the board we had.
Al also provided the strange but necessary connector (visible below on the left) that goes between the Control board and the CRAM board.
We swapped these boards with our boards and everything worked without crashing!
We could now run all the programs on the disk without crashes.
With the Alto running reliably, we could try out the various programs on the hard disk that had crashed before.
Draw, the Alto’s mouse-based drawing program, apparently uses microcode for optimizing performance, so last week it immediately dropped into the Swat debugger.
With the compatible boards, Draw ran successfully. Unfortunately, since our mouse isn’t working, we couldn’t actually draw anything, but you can still see the icon-based GUI below.
I’ve tried Draw on the Alto simulator, and despite the icons, it’s not exactly intuitive to use.
We also tried Bravo, the first WYSIWYG (What you see is what you get) text editor. Again, functionality is limited without the mouse. But I could enter text and change the font to a larger, bold font with proportional spacing. Xerox PARC also invented the laser printer and Ethernet, so one could create documents in Bravo and then print them on a networked laser printer. Charles Simonyi, one of the co-authors of Bravo, later created Microsoft Word, so there’s a direct connection between the Alto’s editor and Word.
I’ve written more about how to use Bravo here.
The Alto included a GUI file manager called Neptune, allowing files and directories to be manipulated with the mouse. Neptune has an invisible scroll bar to the left of the file list that appears when you mouse-over it; apparently the Alto also invented the scroll bar.
A rather complex GUI is in PrePress, a program that converted a spline-based font to a bitmapped font for display or printing.
(You can think of this as a forerunner of TrueType fonts.)
High-quality fonts were created for the Alto using the FRED font editor.
As you would expect from a document company, these fonts included proportional spacing, ligatures such as “ffl” and “fl”, and multiple styles and sizes.
Most importantly, we were able to run MADTEST, the Microcoded Alto Diagnostic test, which runs a suite of low-level diagnostics using microcode. This test ran successfully, increasing our confidence that there are no obscure problems in the processor.
If you want to try these Alto programs for yourself, you can use the ContrAlto simulator, built by the Living Computer Museum. This simulator has been very useful to use for learning how the software is supposed to work.
The biggest problem remaining at this point is the mouse doesn’t work, so we investigated that next.
Although the mouse was invented prior to the Alto, the Alto was the first computer to include the mouse as a standard input device.
The Alto uses a three-button mouse that plugs into the back of the keyboard.
Some Altos had a mechanical mouse, while others had an optical mouse.
Our Alto came with an optical mouse, but we couldn’t get it to work at all. The mouse uses a special mousepad with a specific dotted pattern (which we didn’t have), so at first we suspected that was the problem.
However, the mouse didn’t
respond at all when we used a printed copy of the pattern.
We also didn’t see any light (visible or IR) from the three illumination LEDs on the mouse, so we suspected bigger problems than a missing mousepad.
Opening up the mouse shows the simple circuitry inside, with a single chip controlling it.
The chip is rather unusual since it includes a 16-pixel optical sensor, with a light guide that goes from the bottom of the chip to the bottom of the mouse.
The pixel-based optical mouse was invented at Xerox PARC in 1980 (and later patented), so this mouse is somewhat more modern than the original Alto (1973). The handwritten markings on the chip suggest this may have been a prototype of some sort.
When we closely looked at how the mouse was wired up, we discovered the problem. The mouse plugs into a 19-pin socket (DE-19), while the mouse used a 9-pin plug (usually called DB-9, but technically DE-9), so the connectors are entirely incompatible.
The DE-19 has three rows of pins: 6/7/6 (with the middle row empty on the Alto), and the DB-9 has two rows of pins (7/6).
The bizarre thing is that the mouse plugged into the socket just fine: the connector shells are physically the same size, and the mouse plug’s pins went between the Alto socket’s connections. So the mouse was plugged in, but not actually connected to anything! It’s surprising the connectors could go together without bending any pins.
After some investigation, we learned that the Alto was missing the mouse when it came from Alan Kay. YCombinator picked up a replacement mouse on eBay, but it wasn’t compatible with our Alto.
We’re still trying to figure out if the mouse is an Alto mouse with a nonstandard connector or if it is for a different machine. The Xerox Star used a 2-button mouse, so the mouse isn’t from a Star.
Tim Curley at Xerox PARC loaned us a compatible Alto mouse, so we’ll give that one a try next episode. We’re also looking into making an adapter cable, but DE-19 connectors appear to be obsolete and difficult to find.
Last week we discovered that the control board in our Alto was incompatible with the microcode RAM board. Al Kossow loaned us some compatible boards, and with those boards our Alto has been functioning without any crashes or malfunctions.
We discovered that our mouse wasn’t working because it had the wrong connector—although it plugged into the Alto, it didn’t make any electrical connection. Since the mouse is necessary for many Alto programs, we hope to get the mouse working soon.
For updates on the restoration, follow me on Twitter at kenshirriff.
Thanks to Al Kossow for helping us out again.
The table below shows the three microcode configurations the Alto supported.
Details are in section 8.4 of the Hardware Manual.
The desired configuration is selected by inserting a particular PROM in the Control board: SW1, SW2, or SW3K. Each control board has one PROM in use and an unused PROM in the upper left corner; switching PROMs switches the configuration.
The Control board has sockets for 2K of ROM; these sockets are left empty for systems with 1K of ROM.
The Alto introduced the 3K RAM board to take advantage of the new 4 kilobit RAM chips, replacing the 1 kilobit chips on the 1K board. Both boards required 32 RAM chips for the 32-bit micro-instructions, showing that back then you needed a lot of chips for not much memory.
The microcode required high-speed static memory, so density was worse with microcode than with regular RAM.
The 3K RAM board requires a few additional signals from the Control board, such as the task id.
The 1K RAM board grounds one of the lines used for these signals, so using the 3K Control board with the 1K RAM board (as our Alto did) shorts out one of the bank select lines.
This causes bank switching to fail and explains the crashes we saw last week.
Schematics for the boards are available at bitsavers.