The extra 10 pin plug brings in the wakeup signals for the extra microcode tasks used by the Trident interface. See the trident interface/cabling maint drawings for details.
I wasn't aware that Smalltalk ever was extended on the Alto to the larger microcoded RAMs (would be interesting to see if possible). On the smaller 1024 instruction RAM we had to choose what functions we wanted to have sped up (the 3 main ones were 10 frames per second 2.5D animation and graphics, the real-time FM and sampling musical timbre synthesis, and the Smalltalk byte-code emulator). Most of the Smalltalk work in the late 70s was done on the faster larger Dorado and on the smaller a bit faster NoteTaker.
P.S. You are welcome to try the mouse at HARC in Westwood ...
Back in the dark ages, I worked for two company that each manufactured many of the Static RAMs used to store microcode in these type of computers. I don't recall many of them using ROM, but that was a long time ago. One of the problems was that microcoded machines wanted a very shallow, wide memory system. Most of these machines used 1K x 4 and later 4k x 4 Static RAMs, with a register on the output. The designs shifted data into the wide data bus, then wrote into RAM, cycling through the entire control store.
Just as microprocessors gained enough power to kill-off these systems, mainly I think the 68000, several SRAM manufacturers came up with what was called Writeable Control Store Memories, basically wide Static RAMs (4K x 16) with built in output registers and shift registers to simplify the designs. Too late to make a difference.
I'm interested in how the Alto placed data into the control store and if an AMD 2901 bit slice was used, did they come later?
I've been following this series for a while. Very interesting!
I worked with Sun workstations at a job in the 1990s. They used optical mice too, with special mouse pads. The pad was reflective (like a mirror) with light blue horizontal and vertical bars on it, about 10 or 15 per inch I would say. There was something "magic" with the mouse pad: If you would turn the pad sideways (or turn the mouse 90 degrees), one of the sensors of the mouse (horizontal or vertical, I don't remember which) would stop working. It would definitely be impossible to make a working mouse pad for one of those mice by printing it from a picture, but perhaps if you can find a Sun workstation mousepad in the museum or on eBay or whatever, it might be compatible with your mouse.
All the best with the rest of this project. It looks like your Alto was used as a parts bin...
===Jac
October 15, 2016 at 11:02 AM
Anonymous said...
My Dandetiger mouse has a DA-15 connector (complete with AUI-style slide lock) but only 9 pins are populated, so I'd guess you only need to find the right permutation.
A small clarification: Only Smalltalk-80 required 3K of control RAM; Smalltalk-76 uses only 1K. The Alto IFS servers could make use of 3K of control store to speed things up.
Dogzilla - The Alto always had a 1K bank of ROM which held all the permanent microcode The microinstruction format generated a 'next microinstruction' address of 12 bits with the top bits used to select which of the 1K banks was the source of that next instruction.
There was no wholesale write of all microcode at startup, because microcode was either static, in a ROM, or dynamically loaded only by certain applications at run time.
A word from the ROM or control RAM is 32 bits wide, but implemented with 1K or 4K static RAM chips each handling a slice of the entire word. The main bus of the Alto is only 16 bits wide, so that dynamically writing or reading from the microcode ram (CRAM) involved two operations/cycles.
The Alto I was designed and built a few years before AMD released the 2901. No bitslice, it was all discrete ICs.
I just would like to say that I'm following every single update, thanks for sharing this exciting project! It's absolutely mindblowing how way ahead of its time the Alto was and I can't wait for you to get it up and running again!
October 15, 2016 at 4:12 PM
Anonymous said...
The screenshots look pixelated because of interlacing: in PrePress, the "Grow" button looks like "Crow".
If you can control the exposure time of the camera, you could set it to a multiple of the frame period.
Steve at bigmessowires.com is creating more DB-19 connectors if you need a source. I'm sure this is the kind of project that he'd love to assist. http://www.bigmessowires.com/2016/06/04/db-19-resurrecting-an-obsolete-connector/
Dillon - we need the double density DE-19 - it has the small shell same as what is commonly called a DB9 connector, but has three rows of pins. A DB-19 won't fit - it is the wider B sized shell and only two rows.
If you're still looking for those DE-19 connectors, you might want to ask around the Apple II community. Apple used those connectors for external floppy drives on the //e and //c computers.
In addition to the IR optical mouse, there was also an earlier version that used visible light from grain-o-wheat bulbs. The heat emitted made the mouse a nice hand-warmer on cold days.
In a pinch, you don't need the mouse pad at all. The optical mouse works well running over a pair of jeans. And finally, you don't need the Xerox mouse at all. The Amiga mouse uses the identical quadrature system. I have a Xerox mouse controlling my Amiga 2000 and it works fine. You just need a converter cable to the Amiga's DB-9 mouse port. (Admittedly you still need one of those weird connectors).
Ken, (Having been involved in the design of the Optical Mouse.) I also have some experience; I haven't noted whether you got the thing running, but I can probably advise. Just reach out. Best, Martin
After reading the comment above about using an Amiga mouse, it occurred to me that the screenshot of Neptune is quite similar to DiskMaster on the Amiga which I believe was inspired by Norton Commander.
That in turn has me wondering: Could Neptune be considered the (grand)father of all Orthodox File Managers?
January 16, 2021 at 12:24 PM
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
Marc Verdiell,
Carl Claunch
Luca Severini,
Ed Thelen,
and Ron Crane,
Incompatibility in the Alto's circuit boards
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.
[Image]
This is the Xerox Alto control board, one of three boards that make up the CPU. The board has been modified with several white wires which trigger our crashes.
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.[1]
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.[2]
(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.[3]
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.
[Image]
The Alto's Control board is part of the CPU. This board contains 2K words of microcode ROM, as well as control circuitry. Our original board had 1K of ROM (and 8 empty sockets), while this board has the full 2K of ROM. The ROM chips are in the lower left, with labels. The chip labeled SW3K (upside down) is the PROM that selects the hardware configuration. The spare PROM (labeled SW1) is in the upper left. The edge connector on the right plugs into the backplane, while the two connectors on the left are cabled to the CRAM board.
Some Alto software
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.
[Image]
'Draw' is the Alto's mouse-based drawing program. Clicking an icon on the left selects an operation.
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.
[Image]
'Bravo' is the Alto's WYSIWYG text editor. It supports multiple fonts, among other features.
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.
[Image]
The Alto includes a graphical file system browser.
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.
[Image]
'PrePress' is used to convert a spline-based font into a bitmap suitable for display or printing.
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 mouse
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.
[Image]
The three-button optical mouse.
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.
[Image]
Underside of the mouse. The sensor (right) consists of three illumination LEDs surrounding the optical sensor.
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.
[Image]
Inside the optical mouse. In the middle are the three buttons. At top is the IC that contains the optical sensor.
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.
(Several people have suggested sources for a DB-19 connector. Unfortunately the DE-19 (three rows) has a totally different shape from the DB-19 (two rows).)
[Image]
The Alto's mouse plugs into the 19-pin connector on the keyboard housing (above). Unfortunately our mouse has a 9-pin connector (below).
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.
Conclusion
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.
Notes and references
[1]
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.
table.altocram {border: 1px solid #ccc; border-collapse: collapse;
text-align: center}
.altocram td, .altocram th { border: 1px solid #ccc; padding: 5px;}
Configuration NameROMRAM
1K1K1K
2K2K1K
3K1K3K
[2]
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.
[3]
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.
"Restoring YC's Xerox Alto day 10: New boards, running programs, mouse problems"
16 Comments -
The extra 10 pin plug brings in the wakeup signals for the extra microcode tasks used
by the Trident interface. See the trident interface/cabling maint drawings for details.
October 15, 2016 at 9:07 AM
Hi Ken
I wasn't aware that Smalltalk ever was extended on the Alto to the larger microcoded RAMs (would be interesting to see if possible). On the smaller 1024 instruction RAM we had to choose what functions we wanted to have sped up (the 3 main ones were 10 frames per second 2.5D animation and graphics, the real-time FM and sampling musical timbre synthesis, and the Smalltalk byte-code emulator). Most of the Smalltalk work in the late 70s was done on the faster larger Dorado and on the smaller a bit faster NoteTaker.
P.S. You are welcome to try the mouse at HARC in Westwood ...
Cheers
Alan
October 15, 2016 at 9:22 AM
This comment has been removed by the author.
October 15, 2016 at 10:00 AM
Back in the dark ages, I worked for two company that each manufactured many of the Static RAMs used to store microcode in these type of computers. I don't recall many of them using ROM, but that was a long time ago. One of the problems was that microcoded machines wanted a very shallow, wide memory system. Most of these machines used 1K x 4 and later 4k x 4 Static RAMs, with a register on the output. The designs shifted data into the wide data bus, then wrote into RAM, cycling through the entire control store.
Just as microprocessors gained enough power to kill-off these systems, mainly I think the 68000, several SRAM manufacturers came up with what was called Writeable Control Store Memories, basically wide Static RAMs (4K x 16) with built in output registers and shift registers to simplify the designs. Too late to make a difference.
I'm interested in how the Alto placed data into the control store and if an AMD 2901 bit slice was used, did they come later?
As always, I totally enjoy your writing.
Randy Lea
October 15, 2016 at 10:32 AM
I've been following this series for a while. Very interesting!
I worked with Sun workstations at a job in the 1990s. They used optical mice too, with special mouse pads. The pad was reflective (like a mirror) with light blue horizontal and vertical bars on it, about 10 or 15 per inch I would say. There was something "magic" with the mouse pad: If you would turn the pad sideways (or turn the mouse 90 degrees), one of the sensors of the mouse (horizontal or vertical, I don't remember which) would stop working. It would definitely be impossible to make a working mouse pad for one of those mice by printing it from a picture, but perhaps if you can find a Sun workstation mousepad in the museum or on eBay or whatever, it might be compatible with your mouse.
All the best with the rest of this project. It looks like your Alto was used as a parts bin...
===Jac
October 15, 2016 at 11:02 AM
My Dandetiger mouse has a DA-15 connector (complete with AUI-style slide lock) but only 9 pins are populated, so I'd guess you only need to find the right permutation.
October 15, 2016 at 11:54 AM
A small clarification: Only Smalltalk-80 required 3K of control RAM; Smalltalk-76 uses only 1K. The Alto IFS servers could make use of 3K of control store to speed things up.
October 15, 2016 at 12:30 PM
Dogzilla - The Alto always had a 1K bank of ROM which held all the permanent microcode The microinstruction format generated a 'next microinstruction' address of 12 bits with the top bits used to select which of the 1K banks was the source of that next instruction.
There was no wholesale write of all microcode at startup, because microcode was either static, in a ROM, or dynamically loaded only by certain applications at run time.
A word from the ROM or control RAM is 32 bits wide, but implemented with 1K or 4K static RAM chips each handling a slice of the entire word. The main bus of the Alto is only 16 bits wide, so that dynamically writing or reading from the microcode ram (CRAM) involved two operations/cycles.
The Alto I was designed and built a few years before AMD released the 2901. No bitslice, it was all discrete ICs.
October 15, 2016 at 1:14 PM
I just would like to say that I'm following every single update, thanks for sharing this exciting project! It's absolutely mindblowing how way ahead of its time the Alto was and I can't wait for you to get it up and running again!
October 15, 2016 at 4:12 PM
The screenshots look pixelated because of interlacing: in PrePress, the "Grow" button looks like "Crow".
If you can control the exposure time of the camera, you could set it to a multiple of the frame period.
October 15, 2016 at 8:28 PM
Steve at bigmessowires.com is creating more DB-19 connectors if you need a source. I'm sure this is the kind of project that he'd love to assist.
http://www.bigmessowires.com/2016/06/04/db-19-resurrecting-an-obsolete-connector/
October 18, 2016 at 8:55 AM
Dillon - we need the double density DE-19 - it has the small shell same as what is commonly called a DB9 connector, but has three rows of pins. A DB-19 won't fit - it is the wider B sized shell and only two rows.
October 18, 2016 at 10:31 AM
If you're still looking for those DE-19 connectors, you might want to ask around the Apple II community. Apple used those connectors for external floppy drives on the //e and //c computers.
October 22, 2016 at 10:44 AM
In addition to the IR optical mouse, there was also an earlier version that used visible light from grain-o-wheat bulbs. The heat emitted made the mouse a nice hand-warmer on cold days.
In a pinch, you don't need the mouse pad at all. The optical mouse works well running over a pair of jeans. And finally, you don't need the Xerox mouse at all. The Amiga mouse uses the identical quadrature system. I have a Xerox mouse controlling my Amiga 2000 and it works fine. You just need a converter cable to the Amiga's DB-9 mouse port. (Admittedly you still need one of those weird connectors).
May 8, 2017 at 9:16 AM
Ken,
(Having been involved in the design of the Optical Mouse.)
I also have some experience; I haven't noted whether you got the thing running, but I can probably advise.
Just reach out.
Best,
Martin
October 14, 2019 at 1:56 AM
After reading the comment above about using an Amiga mouse, it occurred to me that the screenshot of Neptune is quite similar to DiskMaster on the Amiga which I believe was inspired by Norton Commander.
That in turn has me wondering: Could Neptune be considered the (grand)father of all Orthodox File Managers?
January 16, 2021 at 12:24 PM