Restoring a Xerox Alto II Extended

being performed in the Silicon Valley area, California - 2016 & 2017

from Ken Shirriff
"Its an Alto II XM (extended memory). With the Orbit backplane
(i.e. it can take the Orbit cards to run a laser printer.
Except we don't have the cards. Or a printer.)"

Along with this page, three Alto restorers are reporting our activities in GREAT blogs :-))
In alphabetical order they are:
    - Carl Claunch's blogs
    - Ken Shirriff's blogs
    - Marc Verdiell's YouTube blogs
Also Al Kossow's CHM efforts July 2017

Goal of this page:
- help me learn and retain some info about the Xerox Alto
Updates to this web page stopped in Oct 2016, the wonderful blogs above made continuing seem redundant.

Table of Contents

Introduction
As per https://en.wikipedia.org/wiki/Xerox_Alto
The Alto was
    - conceived in 1972 in a memo written by Butler Lampson,
     - inspired by the oN-Line System (NLS) developed by Douglas Engelbart at SRI International (SRI),
         - - https://en.wikipedia.org/wiki/NLS_(computer_system)
     - and was designed mostly by Charles P. Thacker.

From "Fumbling the Future: How Xerox Invented, then Ignored, the First Personal Computer"
by Douglas K. Smith - Chapter 7 - more of chapter 7
In designing and building the Alto, Butler Lampson and Chuck Thacker had to master two conflicting objectives - how to make a system cheaper and better than minicomputers. Unless the cost of an Alto fell considerably below the price of a minicomputer, PARC would not have been attracted to the notion of replacing timesharing with an experiment in personal computing. Yet, as Lampson and Thacker conceived it, "personal" implied convenience in addition to economy. To them, a person computer had to handle as easily as other common instruments of expression and communication - typewriters, blackboard pointers, pencils, pens, and paper. Only a state of the are system could approximate that kind of functionality, but only a stripped down computer would be affordable. Only an elegant solution would do both.
...
Lampson and Thacker had seen better "user interfaces," especially in the research of Douglas C. Engelbart, one of the patriarchs of interactive computing. ...

Industrial Design and manufacturing was sub-contracted to Xerox, whose Special Programs Group team included Doug Stewart as Program Manager, Abbey Silverstone Operations, Bob Nishimura, Industrial Designer.

An initial run of 30 units was produced by Xerox El Segundo (Special Programs Group), working with John Ellenby at PARC and Doug Stewart and Abbey Silverstone at El Segundo, who were responsible for re-designing the Alto's electronics.

Due to the success of the pilot run, the team went on to produce approximately 2,000 units over the next ten years.[5]

A 1979 promotional video for a follow-on product. ( one minute )

A standard Alto system includes: from the Alto_Hardware_Manual_Aug76.pdf
  • An 875-line television monitor, oriented with the long tube dimension vertical. This monitor provides a 606 by 808 point display which is refreshed from main memory at 60 fields (30 frames) per second. It has programmable polarity, a low resolution mode which conserves memory space, and a cursor whose position and content are under program control.
  • An undecoded keyboard.
  • A mouse (pointing device) and five-finger keyset.
  • A Diablo Model 31 or Model 44 disk file.
  • An interface to the Ethernet, a 3 Mbps serial communications line that can connect a large number of Alto's and other computers.
  • A microprogrammed processor which controls the disk and display, and emulates a virtual machine whose characteristics are approximately those of the Data General Nova.
  • 64K 16 bit words of 850ns semiconductor memory.
  • 1 K microinstruction RAM that can be read and written with special microcode to extend the facilities of the processor or to drive special I/O devices.
  • Optionally,. a Diablo HyType printer.

People involved
warning: very partial list, started Dec 4, 2016, from gleanings of Marc's e-mails
Host
     - Marc Verdiell - prime mover, machinist, and hardware debug
             and we invade his home, use his tools and instruments
Frequent attendees
     - Carl Claunch - veteran restorer, IBM 1130, 1401, ... disk interface
     - Ron Crane - PARC, early Ethernet electronics, many companies
     - Luca Severini - software
     - Ken Shirriff - software guru, getting hot on hardware debug
     - Ed Thelen - could fake it about monitors ;-))
     -
also providing physical, informational, moral support
     - Alan Kay ( his Alto )
     - Sam Altman of Y Combinator is who provided us with the Alto. https://www.ycombinator.com/
     - Ray Brewer (Xerox Historical Archives, Manager)
     - David_Boggs https://en.wikipedia.org/wiki/David_Boggs - PARC veteran, co-inventor of Ethernet
     - Tim Curley (discs, documentation, mouse, ...)
     - Josh Dersch (Living Computer Museum) - software, boot disc
     - Al Kossow ( documentation, boards, advice, ...)
     - Robert Garner - report on mouse while at PARC
     - Keith Hayes (Living Computer Museum) - software, monitor exercizer
     -
     -


Restoration Sessions


June 11, 2016 - Restoration Session 1
A YouTube report by Marc Verdiell

A report from Ken Shirriff,

From Al Kossow - June 13
> We found one mystery connector and haven't figured out what it is supposed to connect. Al, do you recognize this?

It is the connector that goes from the trident interface to the CRAM and Control boards, the rev of which you don’t have.

I would suggest just removing the two trident interface boards. They will just generate heat.

I will leave the alto disk interface board in the 1401 shop the next time I’m there, which should be before wed


June 24, 2016 - Restoration Session #2, - Monitor - report by Ed Thelen
YouTube activity/summary report by Marc ;-))
and Ken's blog post

Update from Session 1 (June 11, 2016)

Incorrect disc controller card in system - "ALTOII TRIDENT DISK INTERFACE" -
as per "TriconDoc.pdf" "in addition to the standard Alto disk." - "manufactured by Century (now part of Xerox)."
Ken picked up the correct disc controller card (matches the supplied disc) from Al Kossow of CHM.
Correct disc controller from Al Kossow - "ALTOII DISK Control"
Note the different interface tabs.

Today was Alto Monitor day -
With out a functioning monitor, very little is visible of Alto functions.

Present were Marc Verdiell (his home), , Ron Crane, Ken Shirriff, Luca Severini (observer ;-), Ed Thelen (observer)

We made HEAVY use of "5-017-1017B_Ball_TTL_Series_Service_Manual_Oct76.pdf" in BitSavers http://bitsavers.trailing-edge.com/pdf/xerox/alto/ - worth its weight in gold !!
Local Schematic of the monitor.

We made extensive use of the "Alto Signal Generator", made for us by Keith Hayes of the Living Computer Museum. It generates signals similar to VGA, ie vertical sync, horizontal sync, and video, but tailored to the Alto format raster scan of 4x3 (4 high, three wide) rather than the usual 3x4 (3 high, 4 wide) with appropriate horizontal scan sync pulses to one vertical sync pulse. This replaces having to set up multiple synchronized pulse generators :-))
Getting Set Up
Note the hands in pockets. If your hands are in your pockets, your hands can't get into trouble !!
Test Signals
Blue is "video", Yellow is "horizontal sync", Green is "vertical sync". Not enough horizontal lines yet to need a vertical sync.
Marc clearly has too much fun. Luca says The exploded view on Marc t-shirt is an early Macintosh. This is the main circuit card - many connectors removed (after careful labeling) to open up this far.
The struggle continues. Device hanging on the right is NOT an IV bag as in a hospital ;-)) About to clean the malfunctioning linear pot - "brightness". (The black thing on the green ... ) Removing it this far, and returning it was another struggle.
Detail of the dirty/greasy linear pot.
Also one shorted capacitor [C130] was replaced, but no brightness help.
This is the brightest we could do. Seems too dim, needs dark room :-((
After all the pain and strain of trying to get a bright picture on the monitor, we concluded that the picture tube was "weak", weak beam current emission. We may have to increase the filament voltage (old TV trick) or get a new tube. This is Ken's picture of the tube name plate.
Out of mercy to Marc, I have not gotten into other gory details, nor the efforts to put it all back together again - including connecting the monitor and its stand :-(( We started about 10:30 AM, left about 8:30 PM

Marc asks " Ron et al, How compatible are all these CRT tubes? Would something like this work? http://www.ebay.com/itm/15in-black-and-white-96R02500C04-CRT-NEW-old-stock-/152137440948?hash=item236c191eb4:g:9gQAAOSwFNZWyMR9
For $90 I could take the risk.
I do not think Clinton made their own tubes anyhow. Must be a rebadged Hitachi or something like that.
Carl says "Clinton was a manufacturer of CRTs " - https://clintonelectronics.com/about/
Luca says "I think it may worth to contact them explaining what we are doing. They may have some old one left around for whatever reason or perhaps give us some advice on where to find or look for it..
Al Kossow says "I bought three tubes from Clinton within the last 10 years. Note that it isn't a normal phosphor. It is P40 to mitigate the flickering of the interlace.
Keith, did you end up buying any recently for your machines?



Video Test FPGA Board

from Carl Claunch to Marc Verdiell - June 14, 2016
Subject: Design notes on video test fpga board

Hi Marc

If you are interested, here are the details of how the video will be generated.

The pixel clock for the Alto is 20.16Mhz, so the first task is to use the DCM clock module to synthesis this clock rate from the 12MHz rate of the Elbert V2 board. The native clock on the Elbert is too slow to produce pixels.

There are two counters that are running from the pixel clock - horizontal and vertical.

Horizontal will count from 0 to 765, the length of a horizontal scan.

Each time the horizontal line finishes, we bump up the vertical count.

Vertical counts from 0 to 436, the number of vertical lines in a field scan.

This is interlaced scan, so that we alternate, writing odd lines in one field and even lines in the next field.

The horizontal sync is a +1 from count 21 to count 93. This is a 'front porch' of 22 pixel counts, a sync width of 72 pixels or 3.57 microseconds.

The video for a horizontal line begins at 159 and continues to 765, delivering 606 horizontal pixels.

The vertical sync is at line counter values 7 to 11, a duration of four horizontal lines or 152 microseconds. The front porch of the vertical is 8 horizontal lines long and the back porch after the sync pulse is 22 lines. Video is delivered from lines 33 to 437, for 404 lines.

Interlaced scan requires an offset of half a horizontal line between successive vertical scans. You do this by adding a half horizontal line to the second scan of a pair.

VGA does not interlace and none of the open source video examples we have handle this.

I will deal with this by delaying the vertical start pulse by half a horizontal line on the 'even' field. That means the timing for the vertical sync pulse is counts 7 to 11 on the vertical clock for the odd field and counts 7 + 1/2 to 11 + 1/2 on the even field. This complicates the logic slightly. I need to track odd versus even fields and to adjust the vertical pulse emitting logic.

The patterns in my open source code, vertical and horizontal bars, needs to be adjusted to deal with even and odd fields as well. I will be using every other line in each field.

The DCM is giving me a pixel clock of 20MHz, rather than 20.16, but that is close enough for our purposes. The minor difference eats into the back porch by about 7 pixels out of a line of 766, reducing the line to 759 pixels.

Carl

Monitor
Ball
BitSavers 5-017-1017B_Ball_TTL_Series_Service_Manual_Oct76.pdf

Mouse ( 3 button )
Reference info:
     - the original "Engelbart-English mouse"
     - The Optical Mouse: Early Biiomimetic Embedded Vision, Richard Lyon,
     - “The Optical Mouse, and an Architectural Methodology for Smart Digital Sensors", Richard Lyon, local copy
     - Designing and Testing The Optical Mouse, Richard Lyon, local copy
     - Optical Mouse, Functional Specification Robert Garner, 24 July 82,
     - Mouse Pad, .jpg, from Digibarn.com.

Table of Contents
     - from Robert Garner, Oct 21, 2016 to Ken Shirriff
     - Incompatible Mouse Connector Troubles
     - Mouse history and arrow by Alan Kay
     - Mice at CHM by Al Kossow

from Robert Garner, Oct 21, 2016 to Ken Shirriff
> Robert, what was your part in this? You did the whole design?

Heavens no, Dick Lyon invented the whole concept and did the design, layout, optics, etc.

I joined Lynn Conway’s VLSI group just as he was sending his first chips out (if I recall correctly ;-).
I subsequently tweaked the layout a little, searched for a bug, expanded the documentation, etc.,

> I'm told you have the masks for this chip. That would be interesting to see…

If I find the its folder, I’ll scan and email the layout printout (not “masks”) tomorrow.

I still have (my marked up) copy of the PARC report (that I can bring in next Weds if I’m not on jury duty. :-(

I’ll ask Dick if he might be interested in a return visit to the 1401, meet you, etc.

- Robert

p.s. I just noticed this detailed/honest/insightful retrospective by Lynn Conway, mainly focused on the history of her VLSI accomplishments while at PARC: http://worrydream.com/refs/Conway%20-%20Reminiscences%20of%20the%20VLSI%20Revolution.pdf
(Alan Bell, photographed, was my manager.) Here’s her reference to Doug’s spearheading work:

"Doug Fairbairn and Dick Lyon ran an intensive short course for PARC researchers during the spring of 1979, which was videotaped. We began using those tapes as the basis for short, intensive courses at PARC for university faculty members in the summer of 1979. With the help of the PARC tapes, Mead and Ted Kehl also ran a course at the University of Washington that summer.”

"Meanwhile, during the exciting summer of 1979, Doug Fairbairn and Jim Rowson had had the idea of publishing a magazine for the emerging community of VLSI designers and tool builders, and began working on it in parallel with our work on MPC79. The first issue appeared in January 1980 (see Fig. 18), and Lambda (later known as VLSI Design, then Integrated System Design Magazine) soon attracted scores of technical articles about VLSI architectures, design tools and implementation methods [30]. Those articles, along with the many Melgar chip photographs it featured, made Lambda a potent medium for spreading the revolution [27], [28]."


Ken,

Here are two more period articles on Dick’s seminal optical mouse:

Dick’s formative PARC blue report on its design and initial version: “The Optical Mouse, and an Architectural Methodology for Smart Digital Sensors"

The report’s concluding jab at mechanical mice (I concur!): “When one is forced to use a workstation with an electro-mechanical mouse after becoming accustomed to the optical mouse, the erratic performance is an annoying contrast."

And this article in (now CHM’s) Doug Fairbairn's Lambda/VLSI Design magazine: http://www.dicklyon.com/tech/OMouse/DesigningTestingOMouse.pdf (w/ Martin Haeberli, cc’d, who had started working with Dick in ’81, before I joined VLSI group in ‘82)

I still have (my marked up) copy of the PARC report (that I can bring in next Weds if I’m not on jury duty. :-(

I’ll ask Dick if he might be interested in a return visit to the 1401, meet you, etc.

- Robert

Incompatible Mouse Connector Troubles
PARC was a research organization, not a manufacturing, sales, maintenance organization.
This gave it the blessing of high flexibility, and the curse of high flexibility. The various developments in mouse technology, and connectors, is a case in point.

"This mouse cannot plug into that Alto computer." :-((

Generous people offered the restoration team various mice to try/use/borrow ...
The following is a attempt (successful) to adapt one mouse to "our" Alto. (Forgive me Alan Kay, possession by "us" is not necessarily ownership by "us" ;-))

Here is Marc Verdiell soldering. He (was) "volunteered" for this effort because he has clear(er) eyes and steadi(er) hands than many of us - (and Ken Shirriff was busy with the logic analyser, trying to get bits shifted out of the Ethernet board.)
This is the mouse internal connector, thankfully consistent. Marc is using this for the connections of the colored insulation of the wires. OH - those tiny wires !! Are they #32 wire ?? And the insulation is tough and doesn't melt - is it Teflon ?? Mark had a special took for stripping insulation from tiny wires, much different from the wire stripping tools for say lamp wire and electric stoves ;-))
The wisp of smoke above the soldering "iron" is smoke from the rosin core of the solder. I don't know if the EPA has declared this "hazardous" or "carcinogenic" yet. Whole generations of techies have been "testing" the smoke :-|
Here is Carl Claunch reassembling the mouse after inserting the newly soldered black 10 pin plug. Note the three black switches on the circuit board with the three red plastic push buttons to interact with the mouse push buttons.
The operation was a success, the patient survived, and worked !! :-))

Mouse history and arrow, by Alan Kay, Oct 16, 2016
Hi Josh (Dersch)

I'm pretty sure I did the first mouse pointer arrow -- as part of doing a number of the first fonts, and especially many of the proportionally spaced fonts (Ben Laws also did some of the font designs and renderings). Dan Ingalls later did the hour-glass, the spectacles, etc.

Smalltalk was the first system to run on the Alto for quite a while, so many of the eventual conventions were first seen in Smalltalk (also recall that our research community -- mostly ARPA and ONR -- had done GUIs in the past, some of them quite good. But the Alto was the first to have a "display anything" display that had enough pixels to do half-toning. This made a big difference in the whole design.

An interesting side-story here is not a secret, but not so well known. The Alto was an outlaw project, done while "Executive X" was away (this is chronicled in "The Early History of Smalltalk") cooked up by Butler, Chuck and myself, and using some budget I was going to spend on a "cobble" I had been forced into by Executive X. The famous Butler memo "Why Alto?" was not written to get the project going, but as a defense when Exec X came back around Christmas time and found out about it -- the Alto was well underway by that time.

Because of the tight budget and secrecy, we had decided (me grudgingly) to use the nice POLOS (Parc OnLine Office System) terminal as the display, keyboard, and mouse rather than do a custom one (this is what you have before you when you look at an Alto today).

The catch was that POLOS was going to use a variation of "the old character generator" and run at 1000+ lines of resolution, whereas the Alto wasn't going to have the horsepower to drive that many lines: about 800 was the max (808 was the magic number). This meant that the pixel size was going to be much larger on this CRT (about 1/80") than what I'd determined to be the sweet spot between cost and non-linear effect (about 1/100") ... (this was the point of the $200K we spent on "the old character generator": to find out everything about video and every kind of image, especially readable fonts). A fun fact is that the worst size for a pixel at normal viewing distance and this contrast ratio was found to be 1/50", which just happened to be what IBM had picked for its own displays!

The Alto needed a smaller CRT. But we went with the POLOS terminal since Bill English had already paid for the industrial design and the molds to cast the terminal.

This meant that many of the fonts we'd designed had to be redesigned lickety split because Chuck did the whole Alto from scratch -- design and the first one "Bilbo" -- in just one week more than 3 months. You will appreciate that font design on an interlaced display brings additional problems of interlace flicker unless some deep care is taken. All are helped by having more resolution to work with and hurt when the pixels are larger and you still want to have a full page WYSIWYG display.

Part of the theory behind the cursor arrow was to find a graceful shape that wouldn't have too many jaggies at the lower spatial resolution. Cheers

Alan


Hi Al (Kossow)

The vertical buttons were on the earliest mice (we thought -- as you did -- that it would be a lot easier to find the desired button -- and it was). I think we (LRG) might have been the perpetrators of the colored buttons (I'm a bit hazy about the actual history here) -- but Adele and I wanted a way to talk about the mice and the buttons and did use color terminology for years, even after the vertical button mice went away. It's likely that the color button issue came up in one of the "meetings" (not quite the right term for what these were at Parc) and it was just decided that the next round would come out in color.

In any case, the black vertical buttons were in the earliest batchs of mice done.

The big beige plastic case mice were from Engelbart's group, and were part of the Herman Miller joint design (with Bill English, etc) of the lapboards for keyboards, mice and keysets -- these were done in time for the 1968 "mother of all demos". The lapdesks hooked to the chairs were great because you could scoot your chair around as wished, put your feet up, etc. The CRT monitor was separate, and everyone was waiting for the price of light valve projectors (like the amazing Eidophor used in the big demo) to get down to reasonable office costs.

We had a bunch of these NLS mice at Parc in the early days (and they were used on the original half-tone painting system done by Steve Purcell in our group in 1972 (nicer by far than the later "Draw") and also by Bill Duvall for his very impressive mini-version of NLS done on a Nova hooked to "the old character generator" (this was a very impressive system!).

Cheers

Alan

Mice at CHM by Al Kossow, Oct 16, 2016
No, (I don't have an orginal mouse) but I think Duvall gave CHM one. One of the things I need to do is get better descriptions into CHM’s catalog for Alto parts. Right now, we have around a dozen devices that are just described as “Alto Mouse”

I need to take a picture of a mouse that I got a LONG time ago. Beige plastic case, HUGE (like the SRI mice) with two potentiometer wheels. I think I have a matching key set. Maybe for an Augment terminal ???

There is also the mystery of the mice with vertical switches, multicolor or black. There is a picture of a black switched one on the cover of the Clement reports under clementDesignlabs/alto on bitsavers. We have a multicolor switch one on display at CHM with an Alto I, though I’m not sure if these were only used on POLOS. I selected it for display because I thought it was earlier than the more common horizontally arranged switches, and the keys weren’t black.

Helpful Documents on-line - mostly BitSavers.org - http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/

Hardware Manual - from bitsavers - expanded
AltoHWRefPart1-4-ocr
-- Table of Contents
-- 1.0 Introduction
-- 2.0 Microprocessor
-- 3.0 Emulator
-- 4.0 Display Controller

Fig 1 -
Processor Data Paths

Fig 2 -
Process Control

Fig 3 -
Instruction Formats

Fig 4 -
Instruction Execution

Bootstrapping

Fig 5 -
Display Control
AltoHWRefPart5-9-ocr
-- Table of Contents
-- 5.0 Misc. Peripherals
-- 6.0 Disk and Controller
-- 7.0 Ethernet
-- 8.0 Control RAM, ROM, and S Registers
-- 9.0 Nuts and Bolts for the Microcoder
-- Appendices

Fig 6 -
Keyboard Mapping

Fig 7 -
Diablo Disks

Fig 8 -
Disk Data Structures

Software Archives
  • via Paul McJones in classiccmp.org
  • via Al Kossow in classiccmp.org
    "Alto software evolved throughout the 70's. It started out bare-bones as they bootstrapped themselves up. Mesa was developed in parallel, as was Smalltalk. Mesa is an Algol-like strongly typed language with the notion of modules and with internal and external interface. This is all documented on bitsavers and in the source tree at CHM. Mesa is a bit too big to run comfortably even on the max memory Alto with two disk drives. By the time the language was in wider use they had D-machines to run it on. SDD stayed with Mesa for their product development, PARC CSL evolved Mesa into Cedar, with things like integrated garbage collection.

    "The build system used in XDE and the D-machines is extremely powerful. Builds were completely distributed across many servers with the distributed build system managing the packaging and dependencies."

  • from Ian King < isking@uw.edu > in classiccmp.org
    "Even if you never touch an Alto (and I hope that you someday can do so!), it's interesting to look at BCPL, an ancestor of C. I learned to read it fairly well when I was maintaining LCM's first Alto. -- Ian"

  • Subject: PARC Cabinets (boards and platters)
    From: Tim Curley, PARC , Wed, Jul 06, 2016 11:04 am

    Ken,

    I just located these items with the help of facilities (three cabinets full of platters, one cabinet has two boxes of boards). We're gathering up some extra taps just in case we want to network two Alto machines together sometime in the future.

    PARC has only two Alto computers on premise (display units). All the rest of the heavy iron parts went to the Xerox archives on the East Coast. I'll reach out to them to let them know we've got a restoration project that may require spare parts/pieces.

    Attached were Boards-1-.jpg, Cab 2-1-.jpg, Cabinet 1-1.pdf, Cabinet 2-1.pdf, Cabinet 3-1.pdf.

1 K ROM - From: Ken Shirriff
From: Ken Shirriff
Date: Thu, Jul 21, 2016 9:57 am

I've been studying the CTRL 2K board (217129A) which has some missing chips. As far as I can tell, they are supposed to be missing. But I'm suspicious that a couple of the PROMs may be in the wrong place.

I've attached a diagram to help clarify everything.

The "missing" chip is U33. As far as I can tell from the schematic, there is no U33. There are no connections on the back of the board to this chip (I can't tell on the front). I suspect that there isn't supposed to be a chip here, so it's okay. We could easily test continuity and verify that power/ground are not wired to this chip.

Another strange thing is U11 which is a 14 pin chip in a 16 pin socket. The chip is a 74S00 and the schematic calls for a 74S00 and this is a 14 pin chip. So this seems okay, but it's strange they used a 16-pin socket. Again, we can check the board and make sure it's wired for 14 pins.

The microcode PROMs: These are 82S136 1024x4 chips, so there are 8 of them for 1K of microcode. In the first bank, are 8 chips labeled 53x.3, 55x.3, 60x.3, 61x.3(?) 62x.3, 63x.3, 64x.4, 65x.3. The numbers are the chip positions, conveniently enough. The only strange thing here is the paper is ripped off 61x.3 and it looks like 1X, but this is probably okay.

The second bank of microcode has 8 empty chips, which is expected.

Here are PROM labels according to the documentation (07_CTL2K.pdf):

U3 is labeled C03 on the board. This matches the documentation.

U76 is labeled CMS on the board. The documentation doesn't mention U76, but this is probably okay.

U38 is labeled CTR on the board instead of 2KSW. U51 is labeled SW1 instead of CTR. U38 and U51 seem to be labeled backwards compared to the documentation. It makes me wonder if the chips are in the wrong spots. U38 is a 82S23 PROM while U51 is a 3601 PROM, so we could peel off the labels and check the part numbers. They are both 16 pin chips, so that doesn't help distinguish them. It would be strange for the chips to be swapped, but it's also strange for the labels to be wrong.

Al, Keith, Ray: if you have this board handy (CTRL 2K), it would be interesting to see if your boards have the same chip labels and missing chips.

It would also be interesting to dump the contents of the PROMs, which would be easy with an Arduino. This would help clarify if U38 and U51 are swapped. Many of the PROMs are in the firmware.zip file on bitsavers, but not all of them. It would also be interesting to see if we have the same data as on bitsavers. Also, the display and Ethernet boards use PROMs for key timing/encoding tasks, so I can't entirely understand the boards without knowing the PROM contents.

Ken


Comment by Al Kossow - Thu, Jul 21, 2016 10:16 am

The "missing" chip is U33. As far as I can tell from the schematic, there is no U33.[cid:41A9C473-8417-45C2-8F9E-E70F427EE592]

----
U33 is a place to hold the 1K / 2K mapping prom
[cid:41A9C473-8417-45C2-8F9E-E70F427EE592]

Actually U76 is the placeholder. U33 isn’t used as can be seen from the pics

Kossow -> Shirriff, Fri, Jul 22, 2016 8:37 am
> it holds the 1K/2K mapping PROM (although I'm not sure what that is).
It sets how many microcode banks are for RAM or PROM
...
> I just put the firmware for the alto I and II up under bits/Xerox/Alto/firmware on bitsavers. The mirrors should have it around 12:30pm


The .zip file in
http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/xerox/alto/Alto_II/
contains the contents of the PROMS.
There are three directories in this zip file.
  1. AltoPROMs_20070612 - with some of the files hex dumped here
  2. altoROMs - with some of the files hex dumped here
  3. CTL_U51 - with some of the files hex dumped here
and a file called .DS_Store which was not hex dumped

July 29, 2016 - see if various interrupts working, try booting from disc
Various vacations and travels interrupted the "regular" Friday restoration sessions.

Several people have e-mailed helpful suggestions :-)) Very useful, Thanks much -

Ken and Mark worried that there was not enough progress to make interesting blogs,
however, Ken e-mailed the following report:
Marc, Ed, Luca, Carl and I worked on Alto restoration yesterday. A lot of things are working, but it's not booting yet. Next step will be to get out the logic analyzer and see exactly what's happening.

We started by taking a look at the IBM 360 front panel that Marc just got. Very nice:

Moving on to the Alto we started by checking that all the clock signals were working properly. At first, the signals all looked awful, but after finding a decent ground, we verified that the clocks were all running nicely. We also tested the reset line to make sure it was being triggered properly, aided by Ed's expert triggering of the reset button.
Ed adds - "I am now a journeyman RESET BUTTON PUSHER, complete with union card and ISO-9000 certification." "Ya gotta be good a something !!" ;-))

Next we looked at the running tasks. The Alto has 16 separate tasks running in microcode, doing everything from pushing pixels to the display to refreshing memory to moving disk words. Task scheduling is fairly complex. Each task has a priority. When a task is ready to run, its request line is activated (by the associated hardware). The current task can offer to yield by executing the TASK function at convenient points. If there is a higher-priority task ready to run, it preempts the running task. If there's nothing better to run, task 0 runs - this task is what actually runs user code, emulating the Nova instruction set.

The point of this explanation is that microcode instructions need to be running properly for task switching to happen. If the TASK function doesn't get called, the current task will run forever. And if all the task scheduling hardware isn't working right, task switching also won't happen.

The good news is we saw the appropriate tasks running at the right intervals, with preemption working properly. This shows that a whole lot of the system is working properly. The following traces show the four task number bits (active low: 8, 4, 2, 1). Most of the time task 0 runs (all high). You can see task 12 (display vertical task) running in the middle (low, low, high, high). You can see task 8 (memory refresh) (low, high, high, high) running three times, 38.08 microseconds apart as expected. From the traces, everything seems to be functioning correctly with the task execution.

We also managed to see some garbage on the screen along with a cursor, showing that RAM is storing something and the display interface is working, and the display microcode is feeding pixels to the display.
Detail
In addition, the display has steadily increased in brightness from its original very dim state, so we probably won't need to replace the CRT.

Lots of things are working at this point. The minor :-) remaining problem is the system doesn't boot. We looked at the disk signals and found that the Alto is sending no commands to the disk and thus is getting nothing back from the disk. The Alto isn't trying at all to read the disk. We checked for various hardware issues and couldn't find any problems. My suspicion is the boot code in microcode isn't running properly.

A bit of explanation on the boot process: On reset, microcode task 0 handles the boot. If backspace is pressed on the keyboard, it does a Ethernet boot. Otherwise it does a disk boot by setting up a disk command block in RAM. The microcode disk sector task gets triggered on each sector pulse (which we saw coming from the disk). It checks if there is a command block in RAM, and if so sends the command to the disk. When the read data comes from the disk, the disk word task copies the data into memory. At the end, the block read from disk will be executed, performing the disk boot.

Since we're seeing no command sent to the disk, something must be going wrong between task 0 setting up the command block in RAM and the sector task executing the command block. There's a lot that needs to go right here. If anything is wrong in the ALU or RAM has problems, the command block will get corrupted.

The next step is to use a logic analyzer to see exactly what is running.
Techie "clarification" by Ed - The four channel logic analyser shown above is not sufficient to easily show address and other fields. Marc is looking into logic analyzer a wider view. He has an early version of an Agilent which he says is a bear to set up. Fortunately the Alto has a "slow" clock, about 5.8 MHz.
By looking at the microcode address lines, we will be able to see what code is executing and where things go wrong. Then we can probe the memory bus to see if RAM is the problem, and look at the ALU to see if it is causing the problem. This is where debugging will get more complex. I've looked at the microcode closely enough to have a fairly good idea of what is is doing, but it is very bizarre. (Instructions are in random order, what an instruction does depends on what task is running, branches happen by the driver boards flipping various address bits, and various bits in the microcode instructions are inverted for no good reason (probably to save an inverter somewhere)). But hopefully with the logic analyzer we can narrow the problem down.

Next weekend is the Vintage Computer Festival, which will be taking up people's time. So restoration will proceed after that.

Ken

DRAM
Background - How_DRAM_refresh_works

The goal in mentioning DRAM chips here is to note the refresh characteristics. These characteristics affect the Alto microcode program used to refresh them. (Many systems at the time used a few hardware chips to do the refresh, saving software interaction. Even I, a software guy, made a 16 K byte extended DRAM memory for the family Commodore PET computer giving it pixel level programmable display, ORed in with the normal CRT display.)

The dynamic random access memory (DRAM) chips were introduced in about 1970, wonderful at the time. Early types can still be obtained for "special" projects :-))
http://www.jameco.com/z/4116-15-Major-Brands-Dynamic-RAM-16kx1-150ns-DIP-16_41339.html
Spec sheets for DRAM type 4116 1x16K

Especially note that the refresh mode permits total refresh with only 128 accesses rather than the expected 16,384 - a great saving in time (and hardware). (An 8 bit counter (for addresses) and some control logic can refresh all banks of memory at once.)


A little computer memory (fast random storage/access) history:
  1. DRAM for early computers was Williams-Kilburn storage on the faces of CRT tubes, a secondary effect, fussy and unreliable. These *never* had memory system checking such as parity. This lack of fault isolation, given the vacuum tube technology of the time, was a nightmare for the service people
  2. The next break through was magnetic core memory, very reliably, almost always had memory parity checking. The demand for parity checking could be viewed as a hang over from the bad old Williams CRT days. Many/most commercial computers using magnetic cores went through their whole life with out an actual memory failure.
  3. The current break through is semi-conductor memory, very reliable, some early systems such as Alto had parity checking, hardly ever used in home computers now -

Diablo Disk hardware tool ( can both emulate and read/write) a Diablo disk drive
from Carl Claunch - September 27, 2016
It is a dual role tool - the fpga board plugs into one of two extension boards.

One board is cabled to hook to a real Diablo drive and causes the fpga logic to act as a disk driver. A user can read, write or update sectors, seek to any location they want, and all data read or written sits in a 16MB RAM on the fpga board. It can be uploaded to a PC file and conversely a PC file can be downloaded into the RAM.

The other board is cabled to have an Alto disk driver card connect to it. With this board, the fpga logic emulates a Diablo drive, again using the 16MB of onboard RAM as the virtual disk cartridge. The user would download the contents from the PC first, then the Alto can read and write as much as it wishes.

I am testing the first role (disk driver) first so that I can run through reading all 203 cylinders x 24 sectors of data into RAM, then upload the file to the PC. This gives us an archive of each disk cartridge. Once we have protected all the data this way, we won't be at risk if we have a head crash or bad software mangles some files.

The second role (disk emulator) will be used to let the Alto run without having to risk the real disk drive, heads and cartridges every time.

Carl


Big News, it boots :-)) Sept 25, 2016
- a series of e-mails and notes, first near top (here)
1st, a list of people usually CCed on these e-mails
Marc Verdiell, Ken Shirriff, Sam Altman, Hacker News, Keith Hayes, Ed Thelen, Luca Severini, Al Kossow, Tim Curley, Carl Claunch, Ron Crane, Rick Nearpass, Alan Kay, Josh Dersch, Robert Garner
  1. from Ken Shirriff - Sep 25, 2016 6:26 pm
    We got the Alto to boot today, thanks to the boot disk provided by the Living Computer Museum. It runs some programs successfully but crashes on others, so we still have a bunch of debugging to do. I've attached a screenshot of the Alto running.

    Thanks to Sam Altman and Alan Kay for providing the computer; Keith Hayes, Josh Dersch and the Living Computer Museum for their help, and Al Kossow for providing the disk interface card we needed.

  2. from Al Kossow - Sep 25, 2016 6:32 pm
    Woo hoo!

    MADTEST is what you want to run next.
    If you can get that reliable, the basic machine should be solid.
    And, like I asked before, a good disassembly of MADTEST would be really handy.

  3. from Ken Shirriff to Al Kossow - Sep 25, 2016 6:59 pm
    MADTEST rapidly ends up in SWAT. Any advice on how to interpret the SWAT output would be helpful :-) I've attached a SWAT screenshot, but I'm not sure if this was from MADTEST or something else.

  4. from Josh Dersch to Ken Shirriff - Sep 25, 2016 8:22 pm
    Congratulations!

    Interpreting the reason MADTEST crashed is going to be difficult; as Al noted, there are no sources (or symbols) available so there's not a lot to go on.

    In the screenshot, you've got a trap at location 2. IIRC, the first 16 memory locations are set to 77400 (TRAP) instructions to catch things like null pointer dereferences and the like; that this is where you're ending up indicates that it's not MADTEST intentionally trapping (as would be indicated by a TRAP instruction at a location higher in memory), but rather something jumping off into the weeds and ending up at location 2.

    How far does the test get? It prints the currently executing test while it's running. If it goes by too fast to see, recording it with a video camera and stepping through frame by frame may help (ask me how I know). Knowing which test caused the crash may help narrow down the problem.


    I'll add that running DMT (Diagnostic Memory Test) to ensure that the memory is sane would be a useful first step. Let it run for a few hours; press (and hold) the 'S' key to see the current results of the test.

  5. from Ken Shirriff to Josh Dersch - Sep 25, 2016 8:58 pm
    As far as I can tell, MADTEST printed a message about "press space bar to stop" and then immediately died. We ran it a few times and I never noticed any additional messages, but I'll try video. I can try figuring out MADTEST. Do you have any information on the internals (microcode disassembly?) or will I be starting from scratch?

    We're a bit suspicious of memory because of the parity errors we saw earlier (that mysteriously went away). We tried switching banks but programs crashed exactly the same as before, which is evidence against memory errors. We can try DMT to see if anything shows up.

    We tried the Ethernet test, but our mouse wasn't working so we couldn't click on anything. (We may need to get an optical mouse pad.)

  6. from Josh Dersch to Ken Shirriff - Sep 25, 2016 9:20 pm
    The first test MADTEST performs is a test of Microcode RAM, followed by a jump into Microcode RAM; if the latter fails things could fail in odd ways (but I'd generally expect a more catastrophic failure than an orderly trap into SWAT). This is another reason to try running DMT -- it tests Microcode RAM as well, it would be interesting to see if it fails similarly.

    I've attached a screenshot of what MADTEST looks like when running (the garbage in the middle of the screen is normal); if you're not seeing that whole screen render, it could be an issue with the Ethernet interface; we had an issue with ours and MADTEST would hang after printing just the top portion because the Ethernet microcode was posting a nonsensical result when MADTEST was attempting to initialize the interface.

    It would be interesting to get a summary of what programs work, and what programs die; for awhile we had a problem with Microcode RAM, so any program that attempted to use it would fail. If this is the case with your machine, that at least narrows down the search.

    As for reverse-engineering MADTEST, here's what I know: The main program is a standard Nova program, likely written in a combination of BCPL and assembly. It loads small chunks of microcode into the Microcode RAM during each phase to test specific functionality (for example, the Jump RAM test inserts small code throughout uCode RAM that simply sets a register and returns to ROM). I don't know if that microcode is simply a resource embedded in the executable or if it's generated programmatically (I suspect a combination of the two). Using ContrAlto's debugger to look at what's in microcode RAM at the various phases of the test might be a good way to start looking at this. (If you choose to go this route, let me know, I've made some tiny improvements to the microcode disassembler to make it suck less).

  7. from Al Kossow to Ken Shirriff - Mon, Sep 26, 2016 7:49 am
    You need a Xerox grid pad if you have a Lyon optical mouse
    Alto ones are quite rare and extremely cool
    I have a pad of the sheets (somewhere)
    They can be copied. I should make a high res scan of the pattern
    Printing a high res grid may work.
    The guts are similar to the optical mice used on later 8010s and 6085s

    I have a bunch of dead Holley mechanical mice with rotted cords.
    The mechanical mice aren’t very much fun to use.
    I should salvage some for the funky connector that plugs into the back of the keyboard.
    They are just TTL quadrature. I have been meaning to see if a Logitech 3P would work.

  8. from Alan Kay to Tim Curley - Sep 26, 2016 11:09 am
    Hi Tim
    If you haven't gotten the bits on the Alto disks transferred to safer storage, I would like to suggest that this be done as a backup. It's great when things can be run right off the disks, but -- heads crash, oxides decay and drop off, etc. There are several solutions for recovering these files, so it's just a matter of getting the disks to the solutions ....

    Cheers

    Alan

  9. from Al Kossow to Tim Curley - Sep 26, 2016 11:11 am
    Tim, can we work out a methodical method for archiving what is at PARC, rather than randomly seeing “what might be interesting to run” ?

    The condition of the packs is currently unknown. It would make more sense to methodically inspect and archive their contents with the setup Carl is working on first.

  10. from Josh Dersch to Alan Kay - Sep 26, 2016 11:12 am
    Seconded. Carl is working on his Diablo emulator/reader board which would make this possible. (It’s also possible for the LCM to archive these, if for some reason that doesn’t work out…).

  11. from Ken Shirriff - Sep 26, 2016 11:16 am
    I wrote a blog post on the Alto boot with more details and screenshots:
    http://www.righto.com/2016/09/restoring-ycs-xerox-alto-day-8-it-boots.html

  12. from Tim Curley - Sep 26, 2016 2:00 pm
    Hi Alan – yes, Ken and I have spoken about a process for copying/archiving all of the disks we have in storage here. By the way, we found a few disks labeled ‘Alan Kay Backup Disks’. Take a look at the attached lists to see what we still have on hand.

    Ken, we can start the process whenever you’ve got some spare cycles.

  13. from Al Kossow - Sep 26, 2016 2:35 pm
    http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43260.pdf
    The pattern was a hexagonal array of light dots in a dark field,
    If you zoom up, you can see the hex pattern

  14. from Alan Kay - Sep 26, 2016 3:11 pm
    Hi Tim

    There are a few that look like "important" historical milestones (particularly all the Notetaker ones, the Mesa ones, etc.)

    I'd be curious as to what is on the "Backup Disks" (probably demos and/or writings).

  15. from Marc Verdiell - Sep 26, 2016 8:42 pm
    And the video link is below, including the surprise boot once Luca re-tightened the disc cable in place with his iron fingers. I second, +1 and Thumb Up the thank you note below, to all of you that helped out. And gave us the opportunity to work on this awesome machine in the first place! Extra thanks to Ken (and Josh) for reading mounds of documentation and persevering in deciphering the micro-code traces. I think we’ll have a few more to go through…

    https://youtu.be/9OQMhvArI9g Xerox Alto Restoration Part 8

  16. from Al Kossow - via cctech Digest, Vol 27, Issue 26 - 27 Sep 2016 08:21
    How would you suggest they do that? [Do a disk copy] They have one disk drive.

    This is the perennial problem with the Alto, it expects there is a network so you can do things like network copydisk.

    LCM solved their problem by having two machines, and building a 3 to 10mbit gateway with a simulated file server.

    Carl is working on a Diablo drive simulator. Ken is working on a 3 to 10mbit bridge using a Beaglebone. LCM has promised me gateway boards, but no ETA on those.

    It is possible to put two drives on an Alto, but given the marginal state of the hardware yet, they have a bunch of burn in work to do.

    They also need to lubricate the wick on the drive, which I told them to do but it isn't clear if they bothered in their excitement. They also need to clean the pins on the Winchester connectors on the drive. I ran into this bringing up one of my drives on an exerciser yesterday.

    Also, if they have a Lyon optical mouse, they need to come up with a pad, I pointed them to a paper Dick wrote that shows the hexagonal pattern in enough detail to draw a new one.

Ed's version of the momentous events of Sept 25 ;-))
A non-techie version ;-))
Ken brought formal attire :-))
A GOOGLE lab coat !!
Marc gets into a wizard costume :-))
From the Garlic Festival ??
Carl sets up the main logic analyser. Logic analyser inputs from this intimidating rats nest of probes and wires.
Ken (left) and Marc doing some serious thinking :-(( Caused because the disc moved to cylinder 8, instead of this cylinder 0, when commanded to read the boot sector on cylinder 0. When this problem "went away", the boot sector was read correctly and the machine "booted up".
"We" didn't get to check out Carl's new FPGA Emulate/ReadWriteTheDiablo Card which can/will be used to archive Alto disks I didn't get a picture of Ken's EtherNet 3 to 10mbit bridge card being prepared. Should we have "popped the cork" on a bottle of champagne ??


Carl Claunch's blogs Ken Shirriff's Blogs Marc Verdiell's YouTube blogs
In-Memorium Chuck Thacker dies, Driving force and designer of the Xerox Alto I
via cctalk
From: Christine Thacker
Sent: Monday, June 12, 2017 6:58 PM
Subject: Chuck Thacker

Roy, Alan, Butler & Kurt,

I'm sorry to tell you that my father Chuck Thacker passed away in the early hours of this morning, after a short battle with cancer. He died peacefully and without pain at home with his wife of 52 years, Karen, and daughters Kathy and myself all with him. He was incredibly brave and stoic, as I'm sure you can imagine, and refused all invasive medical treatment following his diagnosis in March. As per his wishes, there will be no memorial or service. Kurt, when we heard that Bob was gone my father was so sad, and I was also so sorry to hear the news. Working with Bob and all of you was a source of incredible joy, excitement, and fulfillment for him - the great animating thread that wound through his life. We are sad he is gone, but his life was such an epic adventure that mainly we're all just glad we got to be a part of it.

Please feel free to distribute this news widely.

Christine Thacker

From: Al Kossow
I had the privilege of doing Chuck's oral history for CHM a few years ago. (.pdf)

Robert Garner sent this
Here's s 2008 photo of Chuck (& Ron Cude, Alto I) in my garage.

I hold strong and enduring memories working with Chuck on the Dolphin at Xerox from 77 - 79.

I won't forget his humor, brilliance and compassion.

- Robert


Web page started June 11, 2016
updated through June 19, 2017
to offer suggestions/corrections, e-mail ed@ed-thelen.org