Live data from Hacker News

Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

righto.com

21–30 of 111 posts

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#21
I used the Alto at MIT (and for fun when I worked at PARC -- we had more powerful machines by then).

There are two other things about the alto that have really stuck in my mind. First, the whole thing uses only 300 SSI and MSI TTL chips! No higher order chips (no LSI, much less VLSI).

The other is that the bus bandwidth was only 3/2 the screen update rate. Updating the screen was really important: this was a user-centered, IO-focussed machine which was super radical for its time. If you wanted to do a lot of computation you could steal cycles from the screen update, causing it to go black (in just the bottom half or so IIRC which I probably don't).

Error in the article: I do believe the Alto was the origin of the BITBLT instruction, but it was based on the PDP-10 (PDP-6) block transfer instruction BLT, and the expression blitting was current before the Alto was developed. In fact PARC had a PDP-10 which was the standard research computer at the time -- homemade as well (clones) because at that time Xerox was in the computer business and wanted PARC to use an SDS. (Again this is before my time though MAXC was still running when I was there -- with an Alto as its front end!)

Also contrary to what the article says, the Alto display was not unusual in being portrait mode -- most glass TTYs (think ADM-3A, Hazeltine, VT-52, and I believe the 3270 as well) were taller than they were wide, like a piece of paper. The Alto display was unique, as mentioned, by being bitmapped and black on white. Because of the Alto, bitmapped portrait mode was standard for workstations such as the CADR lisp machines, Bell's BLT terminal, three rivers PERQ, and of course the later PARC computers we used, Dolphins, Dorados (all ECL logic!), Dandelion (sold as the Star). I remember vividly the first landscape machine I used, the Symbolics 3600 in 1985. I didn't, and still don't appreciate the wasted space of landscape displays.

Three-button mice with the mouse buttons arrayed horizontally was also standard because of the Alto. The first time I saw the Macintosh mouse in 84 I was shocked: how could someone use only a one-button mouse? There was a lot of mouse (originally called the "bug") experimentation in the 70s on button count and layout.

The microcode of the alto was compatible with the DG nova as that was the computers used at PARC before the Alto was developed (before my time!).

edit: forgot to mention the origin of blitting.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#22
I haven't used one of those in a long time.

Stanford had several Alto machines, but they didn't have Smalltalk, due to some licensing issue. They just ran standalone Mesa programs. When I was at Stanford, few people wanted to use the obsolete Altos, so time on them was available. So I did a small project on them.

Bravo was used as both the text editor and the word processor. The file format was plain text, then a control-Z, then the formatting info. The compiler stopped at control-Z. So you could use bold and italic in your programs, and make the source code look good.

As in the picture shown, the Stanford machines had the keyboard and display on top of the computer. This isn't required, and it's really annoying to type on. The keyboard is great; it's a massive casting around clicky keys.

Altos talk PUP, Parc Universal Protocol, over 3MB coax ethernet. Stanford had gateways to connect this to the wider world.

I think I still have some of the Alto manuals.

The vision statement for the Dynabook is in "Personal Dynamic Media"[1] This is worth re-reading every few years.

[1] http://www.newmediareader.com/book_samples/nmr-26-kay.pdf

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#23
post #4

This was a great system. The more I research into Xerox's papers and manuals for Interlisp-D, Smalltalk and Mesa/Cedar systems, the more I become convinced it was a big step back to the industry the adoption of inferior systems like UNIX. Thankfully many traces of those ideas are now in Windows, Mac OS X, Android and iOS, Language Playgrounds and many IDE workflows.

I agree. UNIX has some brilliant ideas, like isolated functions (executables) connected by streams, but beyond that it made a lot of mistakes that we are still dealing with today. The biggest one being a C-centric view of programming that has cost the world untold billions of dollars when dealing with untrusted data. It could have used a statically analyzable functional middleware of some kind, falling back to micro…

> The biggest one being a C-centric view of programming that > has cost the world untold billions of dollars when dealing > with untrusted data.

I'm not sure it cost anyone anything. I mean, a lot of the OSes were/are written in it, so if you were going to go down that path you'd have to not totally forget to add a rather large benefit in the credit side. It's hard to imagine but programming wasn't always about compensating for not quite understanding how the 17 different frameworks you've downloaded from github and dragged into an IDE worked by just getting a faster machine. Once upon a time people had to carefully measure how much to unroll the loop, or how small a lookup table they could get away with before the errors become a problem.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#24
post #21

I used the Alto at MIT (and for fun when I worked at PARC -- we had more powerful machines by then). There are two other things about the alto that have really stuck in my mind. First, the whole thing uses only 300 SSI and MSI TTL chips! No higher order chips (no LSI, much less VLSI). The other is that the bus bandwidth was only 3/2 the screen update rate. Updating the screen was really important: this was a user-cen…

Thanks for the info, gumby. As you point out, the amount of bus bandwidth consumed by the display is a big thing. It seems a bit crazy that the processor was running microcode to copy all the pixels to the display in 16-word chunks, 30 times a second. (In a "normal" system, the video hardware fetches characters or pixels from memory. But in the Alto, the processor was running instructions to feed the pixels to the display over and over as they were being sent to the screen.)

I'm confused about your portrait vs landscape comments, though. The ADM-3A, Hazeltine 2000, VT-52, 3270, as well as Datapoint, Four Phase, Viatron, etc had a horizontal display, not a portrait display.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#25
post #9
post #5

Earlier quoted context omitted.

These days, some displays allow you to rotate them between landscape and portrait orientiation. At work, I have a 24 inch TFT in portait mode which I use mostly for coding (and other tasks where vertical space is valuable). It is very nice, because e.g. in text processing, a whole page fits the screen nicely. In a way, we have that with tablets and phones, too.

Operating systems and drivers will allow rotation of most monitors and it mainly comes down to a matter of mounting hardware if autorotation isn't a big deal. Monoprice has a stand for about $20. http://www.monoprice.com/product?c_id=108&cp_id=10828&cs_id=...

There is an non-obvious caveat to using vertical monitors on Windows though - ClearType font rendering doesn't support vertical subpixel arrangements, so you're stuck with naive anti-aliasing.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#26
post #25
post #9

Earlier quoted context omitted.

Operating systems and drivers will allow rotation of most monitors and it mainly comes down to a matter of mounting hardware if autorotation isn't a big deal. Monoprice has a stand for about $20. http://www.monoprice.com/product?c_id=108&cp_id=10828&cs_id=...

There is an non-obvious caveat to using vertical monitors on Windows though - ClearType font rendering doesn't support vertical subpixel arrangements, so you're stuck with naive anti-aliasing.

Turn it off. It looks better anyway.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#27
We've all been fans of Ken's blog for years, so were thrilled that he took an interest in this project. Not only is Ken doing these amazing writeups, he gathered together the master restorers and engineers, some of whom worked on Altos at the time, who are now working on this one. Seeing them set to it, inspecting the Alto and figuring out what would be needed, was a lesson in self-organization. It was an honor to watch from the side.

We have two goals. One is to have the restoration chronicled as it goes along, in a way the HN community can discuss and participate in. Obviously we hit the jackpot there, with one of the best technical bloggers in the world.

The other goal is to do something with the Alto that the community will find interesting once it's running. A couple ideas are to make it fetch and render the front page of HN (we'd happily write whatever code was needed to serve it in a suitable format, since HTML is probably a bridge too far), or if we could find a second Alto to communicate with, play Maze War on them (http://www.digibarn.com/collections/games/xerox-maze-war/#ma...). But we'll be eager to hear any suggestions the community comes up with!

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#28
There is a lot of documentation about the Alto. Are there also complete circuit diagrams? I am just curious because the processor was made in TTL at a time before the 6502 and Z80 were born.

Sooner or later the last functional Xerox Alto will cease to work (sadly). In that case it could make sense to replace the dysfunctional parts with modern retro circuits. I wonder if a project to build a functional Alto clone (with TFT as screen) would make less effort than the famous monster 6502 which was presented recently.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#29
post #5
post #2

My first impressions of it are that the portrait oriented monitor actually looks very stylish. There is something almost futuristic about it.

These days, some displays allow you to rotate them between landscape and portrait orientiation. At work, I have a 24 inch TFT in portait mode which I use mostly for coding (and other tasks where vertical space is valuable). It is very nice, because e.g. in text processing, a whole page fits the screen nicely. In a way, we have that with tablets and phones, too.

One of the first Macs I ever saw back in the early 90s had a Radius pivot display which could be switched between landscape or portrait.

As it was mostly used for DTP it made loads of sense.

Re: Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer

#30
post #24
post #21

I used the Alto at MIT (and for fun when I worked at PARC -- we had more powerful machines by then). There are two other things about the alto that have really stuck in my mind. First, the whole thing uses only 300 SSI and MSI TTL chips! No higher order chips (no LSI, much less VLSI). The other is that the bus bandwidth was only 3/2 the screen update rate. Updating the screen was really important: this was a user-cen…

Thanks for the info, gumby. As you point out, the amount of bus bandwidth consumed by the display is a big thing. It seems a bit crazy that the processor was running microcode to copy all the pixels to the display in 16-word chunks, 30 times a second. (In a "normal" system, the video hardware fetches characters or pixels from memory. But in the Alto, the processor was running instructions to feed the pixels to the di…

> It seems a bit crazy that the processor was running microcode to copy all the pixels to the display

It seems crazy today but not in context. There wasn't video hardware in today's sense. There were either mainframes (with channel controllers) with the terminal doing the "rendering" or minicomputers and microcomputers in which the CPU did everything (which is what I guess it was like before the mainframe era).

You can see this reflected in Unix, and therefore in Linux: unix was developed for the PDP-7 (and later -11), a reimplementation of some of the ideas of Multics, which ran on a mainframe. So C's IO was "user mode" (I seem to remember a funny line in the original version, something like, "You mean you I have to call a function to do IO?") and the kernel had expensive, primitive IO capabilities and involved the CPU in everything. Well, there wasn't any alternative in the smaller PDP line (FWIW PDP-10 were larger machines than the -7 or -11, though only the later models had channel IO).

Memory mapped IO was not uncommon on minicomputers.

> I'm confused about your portrait vs landscape comments, though. The ADM-3A, Hazeltine 2000, VT-52, 3270, as well as Datapoint, Four Phase, Viatron, etc had a horizontal display, not a portrait display.

I'm confused / unclear. Those terminals had more columns than rows, true, but the character positions were rectangular. So the ADM-3 and the Datapoint were rather square, actually, because TV tubes were squarish, not paper-like as I claimed. I think I biased my memory because I used a bunch of hacked terminals like AAA Ambassadors which could cram 80x48 rather than 80x24 and because of the rectangular characters were portrait-ish. Unfortunately it's too late to go back and edit my comment.

Post reply on HN