[Indigo]<AltoSource>BRIEFINGBLURB.DM!2>BriefingBlurb.1

Are you a programmer? Are you sick of manuals that tell you how to use a software system without telling you why it behaves as it does? Are you frustrated because you don’t know the unstated assumptions behind the interesting discussions you hear around you? Have you ever wanted to browse through the source code or the documentation for a program, but couldn’t figure out where to find it? If the answer to some of these questions is ``yes’’, read on! These and other useful (and occasionally entertaining) tidbits shall be made known unto you.

You will doubtless read many documents while you are at Xerox. A common convention observed in many manuals and memos is that fine points or items of complex technical content peripheral to the main discussion appear in small type, like this paragraph. You will soon discover that you cannot resist reading this fine print and that, despite its diminutive stature, it draws your eyes like a magnet. This document has such passages as well, just so that you can begin to enjoy ferreting out the diamonds in the mountain of coal.

There is a great deal of useful information available on-line at Xerox in the form of documents and source program listings. Reading them is often very helpful, but finding them can be a nuisance. Throughout this document, references to on-line material are indicated by {n}, where n is a citation number in the bibliography at the end of this document. Standard citations to the open literature appear as [n].

Reading a document from front to back can be mighty boring. This document is organized so that you can (supposedly) browse through and read the parts that look interesting. In fact, the current version of this document is so disorganized that it is not at all clear that there really is a front and a back in the normal sense! This means that the usual bottom-up approach to documentation (define your terms before you use them) has been abandoned. Instead, all the relevant terms, acronyms, and the like have been collected in a glossary at the end. Some information is contained only in the glossary, so you may want to scan through it later (or now, for that matter). It is assumed that you have a basic knowledge of computer science, and a modicum of common sense. Don’t expect to find terms like ``computer’’ and ``network’’ in the glossary.

Behind that inviting screen there lurks a wealth of fascinating history, folklore, and (occasionally) documented wisdom. However, even the great storytellers of old occasionally forgot that their attentive audiences included travelers from other lands who were ignorant of the local customs and traditions. So it was with the Alto gurus. What follows is a transcription of the oral history of the Alto culture acquired by a relatively recent settler in these parts. It makes no claim to completeness, balance, or fairness. (A separate document exhibiting these qualities may be found on {20}.)

Before exploring Alto-land, you should know something about the names of the creatures you will find there. The prevailing philosophy about naming systems in CSL and SDD is perhaps somewhat different from the trend elsewhere. While we have our share of alphabet soup (e.g., PARC, FTP, MAXC, IFS), we are trying to avoid making it any worse. Names for hardware and software systems are frequently taken from the Sunset Western Garden Book [14]; Grapevine servers are named after wines; Dorados are named after capital ships; Pilot releases are named after California rivers. Personal machines also have names that frequently, but not necessarily, come from the same kinds of sources. These names are chosen by the machine’s owner, and registered with an entity named NetSupport.WBST. As this convention about names does not meet with universal approval, it seems inappropriate to offer a justification of the underlying philosophy without offering equal time to the opposition. You will doubtless provoke a far more interesting discussion if you advance your own views on naming to almost anyone wandering in the corridors. Accordingly, we abandon the topic here and move on to more concrete matters.

Most of the offices and some of the alcoves around PARC have personal computers in them of one flavor or another. The first of these was the Alto. There are more than 1000 Altos in existence now, spread throughout Xerox, the four universities in the University Grant program (through which Xerox has given Altos to U. of Rochester, and Altos, Dovers, and IFS’s to CMU, MIT, and Stanford), and other places. In contrast, the Dolphin and Dorado are newcomers to the scene. A Dolphin is somewhat more powerful than an Alto, and a Dorado is gloriously more powerful. Private ownership of Dorados is a recent innovation, and has not yet spread very far. Most of us get our fixes of Dorado time by signing up on lists to share one of the ``pool’’ Dorados.

The genus ``Alto’’ comprises two species, imaginatively named Alto I and Alto II, and there are several sub-species as well. All members of the genus have at least a display, a keyboard, a mouse with 3 buttons, and a processor/disk cabinet. The front cover of an Alto I cabinet has a ventilation grill just at the bottom, while on the front cover of an Alto II, the grill goes all the way up to the disk slot. All Alto I’s have a main memory consisting of 64K 16-bit words, called one bank in local parlance. Most Alto II’s are equipped with the extended memory option (XM), and have up to four banks of memory (that is, 256K 16-bit words). Needless to say, you can do a lot more with four times the memory.

The first Alto II’s made came equipped with a funny keyboard, properly called the ADL keyboard, although sometimes also simply referred to as the Alto II keyboard. An ADL keyboard is larger, and has a different key layout, including columns of function keys on the left and right. The ADL keyboards were generally reviled, and hence did not stay in production long. Nowadays, they are pretty rare. If you want to see one, check out Clover’s Alto. Don’t be confused by documentation that warns you that keys will be in different places on an Alto II; you can safely ignore these warnings unless, God forbid, your Alto II has an ADL keyboard.

The innards of the Alto are revealed in gory detail in a very complete manual {1}. Facts, figures, specifications, and programming information (at the machine level) are all there. What isn’t there is a bit of the philosophy underlying the machine design and organization. In particular...

1)There isn’t much special-purpose hardware in the Alto. Most of the nifty stuff you can read about in the hardware manual is in fact implemented by microcode. This gives us considerable flexibility in the way we design software interfaces for experimental devices and specialized instruction sets. In fact, Mesa and Smalltalk are implemented almost entirely with "special" microcode.

2)The display is rather different from a number of other common displays. Instead of containing a character or vector generator, the display hardware interprets individual bits. One bit in memory shows up as one dot on the screen. Since the screen is 606 by 808 points, a quick calculation shows that a full-screen display requires nearly half of an Alto I’s memory. For a machine with only 64K of memory, that seems a big price to pay. The theory is that in exchange for the space we get enormous freedom to experiment with various strange ways of manipulating the screen.

So much for philosophy—how does it work out in practice? Well, excessive flexibility breeds chaos, so a number of things have been standardized. All Altos contain a ROM that defines the ``normal emulator’’ (i.e., the standard instruction set) and the standard i/o device interfaces (e.g., display, disk, ethernet, and so-called ``junk i/o’’—the keyboard and mouse). The instruction set is derived from the Data General Nova, though the i/o structure is rather different and several specialized instructions exist to support various display manipulations. If you have a spare hour or so, read about BITBLT in {1}. Then try to imagine writing the microcode to implement it. Since the microcode for these standard facilities is blown into a ROM, suggestions for improvements/extensions are treated with considerable skepticism. Microcode hackers will find the additional 1K control RAM available on all Altos a reasonably comfortable sandbox in which to play. If you are both a microcode hacker and a concrete pourer, you can also use a second 1K of ROM on Alto II’s. A few Alto II’s substitute 3K of RAM for the second 1K of ROM, which gives you even more room to play without any need for concrete..

The display has enormous potential, and there are a number of programs around that exploit it in interesting ways. We also feel compelled to note that at least an equal number of programs still treat the display as a glass teletype. Home-made cookies require more effort, but they taste a lot better than the store-bought variety. Fortunately, more and more people are getting into home cooking.

The mouse has two obvious properties—it rolls and it clicks. Inside the Alto hardware, the mouse position and the display cursor position are completely unrelated, but most software arranges for the cursor to ``track’’ the mouse’s movements. The three mouse buttons are named red, yellow, and blue, even though physically they are nearly always black. This choice was made because not all mice have their buttons arranged in the same way. On some (older) mice, the buttons are thin, horizontal bars; the top one is red, the bottom one is blue. On most mice, however, the buttons are wide, vertical bars, with red at the left and blue at the right. Some people insist on naming the buttons red, yellow, and green—perhaps as kids they had strange paintboxes, or were fixated on traffic lights.

A somewhat unusual property of the Alto is that the keyboard and mouse buttons are unencoded; that is, there is a bit for each key that indicates whether the key is up or down. Many programs distinguish between holding a mouse button down and clicking it down and up. Fewer programs play such tricks with the keyboard, although combinations of keys that would jam a conventional typewriter are quite meaningful to some programs, e.g., the NetExec. Fortunately, there is standard software that enables you to treat the keyboard in the usual way if you want to. Note that this ``usual way’’ involves a feature called infinite rollover that changes your typing style after a while: you can have arbitrarily many keys depressed at the same time without causing a jam, and without causing any strokes to be discarded. Every key that goes down counts as a key stroke when it goes down, and when that key comes up again doesn’t matter at all. A few weeks of typing on this sort of keyboard, and you begin typing common letter clusters such as ``ion’’ with just a flick of the wrist; after all, if the letters come out in the wrong order on the display screen, you can always edit them later.

With a personal computer, you are programmer, system hacker, and console operator all rolled into one. If you don’t like the state your program has reached, you can always press the boot button and start over—an option you rarely have on larger, shared machines. It is a good idea NOT to press the boot button when disk activity is in progress, however, since you may interrupt the writing of a disk sector halfway through, thus rendering that sector unreadable. However, the Alto differs from many small computers in that it lacks those time-honored, nitty-gritty debugging facilities: the console lights and switches. If things are so screwed up inside that you can’t get some sort of (software) debugger running, there isn’t much you can do as console operator. This tends to down-play the operator role and emphasizes the system hacker role. ("Let’s see, if I hit shift-Swat, that will write the core image on Swatee, and if I then bootload the debugger...") It also makes certain kinds of bugs, e.g., those that smash crucial memory locations in low-core, very difficult to find.

If you have just turned on an Alto and are about to spin up your disk and do some work, it is a good idea to hit the boot button before your disk comes up to speed: When an Alto is first powered up, it comes up in an unknown state, and there is some small but nonzero chance that the processor is sitting in a loop just waiting to eat your disk (that is, write something on it).

Many Altos in CSL have been equipped with a second disk drive, which either balances on top of the processor cabinet or sits on some flat surface nearby. The two drives of a double disk Alto can be used in two different ways: either the two disks constitute separate file systems, or they together constitute a single, larger file system. It is possible to extend a one disk Alto file system into a two disk system at any time, but the reverse is not possible. And a two disk system will only operate when both of its disks are loaded into the drives of a double disk Alto. A double disk machine has a second little switch hidden at the back of the keyboard, in addition to the boot button. This switch serves to interchange the roles of the two drives, called DP0 and DP1. If you flip this switch while disk activity is in progress, you will fairly likely get what you deserve: a smashed page on one or both disks. The Scavenger may help you recover.

A Dolphin looks a lot like an Alto II. The biggest difference is that the Dolphin has a nasty looking piece of solid sheet metal where an Alto has a slot into which you can stick your disk pack. You see, a Dolphin comes with a Shugart 4000 disk instead of the Diablo 31 disk of the Altos—and the recording medium of a Shugart 4000 is not removable (well, not easily removable anyway: with the right tools and expertise, you might swap platters in an hour or so). This makes it somewhat harder to borrow someone else’s Dolphin than it is to borrow their Alto—see the discussion below on Living Cleanly.

Dolphins have various advantages over Alto II’s: Mesa programs run significantly faster; long pointers in Mesa work (making it easier to use lots of memory); the Shugart disk is bigger (two partitions); and Pilot runs on Dolphins. Most Dolphins have wide displays, 1024 bits in width instead of the 606 bits of the standard Alto-style display. The extra screen space is only available to programs running in the Pilot world.

A Dorado doesn’t look anything like an Alto, although most Dorados today come equipped with an Alto-style terminal (display, keyboard, and mouse). In fact, in a return to the ways of the past, a Dorado’s processor is located in a remote, heavily air-conditioned machine room. When the Dorado was being designed, it was intended and hoped that the Dorado, like the Alto, would live in your office. To prevent its noise output from driving you crazy, a very massive case was designed, complete with many pounds of sound-deadening material. These cases are fondly known as APC’s, although no one is sure what the letters stand for in the Dorado’s case (see the Glossary). But experience indicated that Dorados run too hot when inside of these cabinets, and the concept of having Dorado processors in offices has been abandoned. With VLSI and all, there is some hope that the Dorado’s successor (the Dragon?) will once again come out of the machine room and into your office.

Dorados have varying amounts of memory, but at least 512K 16-bit words, or equivalently, 8 banks. In addition to these oceans of real memory, the Dorado has a fairly whippy processor, a cache, and a Trident 80 MByte disk; this all adds up to pretty impressive performance. A Dorado is roughly three to five times faster than an Alto when emulating an Alto, that is, running BCPL. And a Dorado runs compute-bound Mesa software roughly eight to ten times as fast as an Alto. Because of the raw power of a Dorado, it is usually the computer of choice for substantial programming projects. The primary difficulty about Dorados is that there aren’t enough of them—yet (and the related fact that they are rather tricky to build).

Dorado disks can be changed with somewhat greater ease than Dolphin disks, but the process is still painful enough that changing disks is not the normal mode of operation. The biggest difficulty is that you must be at the processor to change the disk, and the processor is a long way away. Subsidiary difficulties are that you must power down a Dorado in order to change the disk pack, and that T-80 disk packs are difficult to label effectively. As a result, when you borrow a Dorado, you also need to borrow at least some of the space on that Dorado’s local disk: this brings us to the issue of Living Cleanly.

Local disks are very convenient, but not very reliable. It is quite tempting to work along on an Alto for weeks at a time, without backing up your files on any other medium. You might be able to do this forever without getting burned. On the other hand, those of us who have been hanging around here for a while could tell you many sad stories of head crashes and dropped disks, that left our colleagues (or even ourselves) with disk packs suitable only for wall decorations. In fact, most of those very disks are now serving as wall decorations. Hence, the principle of clean living: you are living cleanly if your pulse and blood pressure would remain substantially constant when you are informed that your local disk has been degaussed. Make sure that all of the bits you really wouldn’t want to lose are out some file server, such as Maxc or an IFS, where suitable precautions are constantly being taken by wizards to protect against disk failure. Appropriate use of command file, dump files, and other automatic aids can make this task easier.

Encouraging clean living has another benefit: shared local disks are only practical if everyone lives cleanly. The management of the public partitions on Dolphins and Dorados presumes a policy of clean living: when you are done working on a public partition, you must store away all of your files on remote file servers. It is polite to delete your files from the local disk as well, to give whoever follows you more space to play; but this is not nearly as critical. If you find that there isn’t enough space on a partition, you are perfectly within your rights to delete the random files that are lying around on the partition to regain space. And the creators of those files won’t mind, it says here, because they have been living cleanly. In fact, there is an authoritative image of what a ``completely clean’’ public Alto-Mesa 6 partition for a Dorado is out on [Ivy]<Cedar>Mesa6.bfs. If you find that the public Mesa partition you just started using seems to be screwed up in some way, you can always get back to a known good state with lots of free space by smashing the whole partition with that image, using CopyDisk.

(The above paragraph is the ``letter of the law’’ regarding the sharing of public partitions. People who want to be well regarded should also pay some attention to the ``spirit of the law’’: sharing things is always more pleasant when everyone acts with a modicum of politeness and care. This topic is discussed at greater length below...)

It would be nice if our computers could handle more of this file shuffling for us. There is some hope that we will be able to move someday to a glorious future in which all of the independent file system fiefs will be combined into a universal file system, and all local disks will be employed simply as automatically-managed caches for that file system.

An Alto has one boot button, hidden behind the keyboard. On Dolphins, there are two boot buttons, one at the back of the keyboard, and one on the processor cabinet itself: the two perform roughly the same function, but the one on the cabinet is a little more potent. On Dorados, the situation is much more complex. There are really two computers involved, the main processor and a separate microprocessor called the baseboard computer. It is the baseboard computer’s job to monitor the power supplies and temperature, and to stage-manage the complex process of powering up and down the main processor, and the correct initialization of all of its RAM’s. The boot button on a Dorado is actually a way of communicating with this baseboard computer. You encode your request to the baseboard computer by pushing the boot button repeatedly: each number of pushes means something different. For details, see Ed Taft’s memo: {24}. If the baseboard computer of the Dorado has gone west for some reason (as occasionally happens), your only hope is to push the real boot button, a little white button located on the processor chassis itself, far, far away. Just as the boot button on the keyboard is essentially a one-bit input device for the baseboard computer, the baseboard computer also has a one-bit output device: a green light located on the processor chassis. Various patterns of flashing of this light mean various things, as detailed in {24}.

Two’s company, three’s a network. You can do a lot with an Alto, but at best it’s still a classy minicomputer. With hundreds of them out there we should be able in theory to do all sorts of wonderful things. In practice, we actually do some of them. You should read the paper by Metcalfe and Boggs describing the Ethernet [2] for a good introduction to the communication network that connects our Altos together. In essence, a collection of Altos within reasonable proximity is hooked together by an Ethernet. Ethernets are connected to each other by Gateways, which for most purposes allow us to ignore the topology of the resulting network; the network as a whole is called the Internet. However, occasionally it’s nice to know where things really are, and that’s when a map {3} is helpful. For programs (which are notoriously poor map readers), the Gateways also provide an information service {15}.

We all know how uncommunicative computers can be when left to their own devices, and Altos are no different. That’s why we invent careful protocols for them to use in talking to each other. Most of the protocols now in use on the Ethernet are called PUP-based (PARC Universal Packet) {16}. Built on top of the Pup protocol are quite a number of others, some of which you can read about in {4,5,6,7}. You will probably hear some of the following protocol names being tossed about in conversation:

2)FTP - refers to the File Transfer Protocol, as well as the Alto program that implements it and provides an interactive user interface. If you come from the Arpanet world, don’t confuse this FTP with the one out there—ours is Pup-based and incompatible. On MAXC, where both the Pup and Arpa FTP protocols come in handy, the name FTP refers to the Arpa one and PupFTP (obviously) refers to the Ethernet one.

There are quite a few other protocols in use as well. The wisdom here is: if you have some nifty multi-machine communication to do, look around—someone may well have done your protocol work for you. There also are a number of communications wizards about who can keep you from falling into various traps.

Question: Why have a network? Answer: Because it’s nice to be able to pawn off some of the dog work on other machines, leaving your Alto free to do the interesting stuff. That’s why we have a number of machines generically called servers. Normally, servers have special purpose, expensive hardware attached to them (e.g., large-capacity disks, printers), and their sole purpose in life is to make that hardware available to more than one person/Alto. We tend to identify servers by function, so we talk about printing servers, file servers, name lookup servers, mailbox servers, tape servers, and so on. Many of the protocols for use of the Ethernet were developed precisely so that personal Altos could communicate effectively with server Altos.

Printer servers and file servers get the biggest workout. There is considerable history and folklore surrounding printing and printing servers—you will find some of it in later sections of this document. One doesn’t tend to hear much about file servers, except when they are down; nevertheless, they are essential to our computational well-being. Because Alto disks are rather small (another topic we’ll come back to later), we rely heavily on file servers to store libraries of Alto packages, subsystems, and documentation. In Palo Alto, our primary file servers are Maxc and two IFS servers, Ivy and Iris. A file server also acts as the natural common repository for the ``truth version’’ of a system being constructed by a number of individuals. And file servers are important to single individuals since they provide greater capacity and higher reliability than local disks.

The first high-level programming language used on the Alto was BCPL, and quite a bit of program writing was done in that environment. But BCPL is now a dead environment. It will be around for some time to come, since there are BCPL programs that perform valuable functions for which there are no current replacements: the printing server programs Press and Spruce are two important examples. Other languages that run on our computers are: Smalltalk [18] (an integrated, interactive, object-oriented programming system), Mesa [19] (a strongly-typed, PASCAL-like implementation language), Poplar (a simple, interactive, text-oriented language), a dialect of Interlisp, and others. Mesa is perhaps the most widely used, with Smalltalk and Lisp coming in second and third. Mesa was given a big boost in CSL when a variant of Mesa (itself called Cedar) was chosen as the base language for the Cedar programming environment.

There is a reasonable amount of introductory documentation for systems you commonly need (e.g., Bravo, FTP, the Alto Executive) in [13]. This is by far the most useful single reference for the Alto environment. Since the entire document can’t be reprinted when any subsystem changes, however, you can expect the information there to be somewhat out of date at any one time. If you suspect you need the latest documentation for some program X, you might try [Maxc]<AltoDocs>X.press (or X.tty, or X-news.press).

BCPL programs typically run on top of the Alto Operating System, which is itself written in BCPL. Like most OSs, this one provides a number of basic facilities, not all of which are needed by any one program. Because the small memory of the Alto is precious, a technique called ``Junta’’ exists which permits BCPL programs to get rid of unneeded portions of the OS during their execution. ``Counter-Junta’’ brings them back. You can read about the layers of the OS in {8}.

Mesa programs do not use the Alto OS at all, mostly because Mesa and BCPL have rather different philosophies about the run-time world in which they exist. So the first thing that a Mesa program does when running on an Alto is to Junta away almost all of the OS, and set about building a separate Mesa world. It is a considerable nuisance for Mesa and BCPL programs to communicate, since their underlying instruction sets are completely different. So, most of the important OS facilities (e.g., the file system) have been (re-)implemented directly in Mesa. Mesa’s memory management strategies replace the revolutionary tactics of ``Junta’’ and ``Counter-junta’’ with the (relative) anarchy of segment swapping.

There is a program called the Executive which runs on top of the OS and provides a command interpreter with a number of natural facilities, such as ``tell me what files are on this disk’’, ``run this program’’, ``execute this command file’’, ``go away’’. System maintainers will tell you that the Executive is ``just another program—if you don’t like it, you can write one yourself’’. That’s true—you could also write a Mesa compiler yourself, but ... . In all fairness, however, the Executive is one of a number of programs that have reached the state where maintenance consists of aggravating details. Consequently, requests for feature enhancement are not likely to fall upon receptive ears. Perhaps the most useful features of the Executive are file name completion (ESC) and *-expansion, particularly in conjunction with subsystem invocation. You should also read about control-X and control-U in the Executive section of {10}. Also, check out keyi.cm for i=1, 2, and 3.

No matter what program you are running, there are times when you want to say ``get me out of this mess and back to somewhere more comfortable!’’ Unless things are really messed up, you have two choices, both of which require you to know where the Swat key is. (This invaluable key is unlabelled! On most keyboards, it is at the extreme lower right, next to the shift key; on ADL keyboards (in case you ever find one), it is at the extreme upper right, separated somewhat from the main keyboard area.) By hitting shift-Swat, you can normally get back to the Executive—note that you must use the left-hand shift key to type ``shift-swat’’, not the right hand one: the right hand one is too close to Swat itself for comfort. Control-shift-Swat will normally get you into Swat (the BCPL debugger). What you do there is your own business (see {10}). Control-Swat will get you to the Mesa debugger if you are in a Mesa program, and there is a Mesa debugger on your disk, and it is installed, and your core image isn’t too badly screwed up. If you are just trying to abort whatever program you are running, you probably don’t want to be in the debugger anyway. If these last-ditch facilities don’t seem to work, things are very confused, and you will have to boot your Alto, using the little white button that is not only unlabelled, but hidden behind the keyboard.

The folks in SDD have produced a new operating system, written in Mesa, called Pilot. Pilot does not run on Altos, but it does run on D-machines such as Dolphins and Dorados. Furthermore, by running Pilot on your D-machine you get all the advantages of virtual memory and multiprocessing, which you don’t get while pretending that you’re running on an Alto. Note that there are currently two different systems that someone can be talking about when they say ``Mesa’’: Alto Mesa and Pilot Mesa.

There are several facilities available over the Ethernet that do not require a disk. You can boot any one of these programs into your Alto by pressing down a strange collection of keys simultaneously and hitting the boot button, but there is an easier way. If you hold down the BS and ’ (single quote) keys and hit the boot button, you get the NetExec, a simple executive to which you can type the name of the program you want to boot into your machine. Typing "?" will tell you what is available. If you type the name of a program that should exist, and the screen flashes in discontent, it just means that you had the bad luck to contact a boot server without the complete set of programs. If you just type carriage return again, the NetExec will try to talk to a different boot server, and that might cure the problem. The most frequently used facilities are the Scavenger, Chat, CopyDisk, and FTP. You can also get a variety of diagnostic programs, the most popular being DMT. And you can get an assortment of games. Warning: many of the games use special Alto microcode, and hence will not run on Dolphins and Dorados.

It is a little known fact that typing shift-swat to DMT will boot the NetExec. Then, typing ``BootDP0’’ to the NetExec will boot your machine. And typing ``NetExec’’ to the standard Alto Executive will boot the NetExec. Knowing all this, you can manage to avoid hitting the actual physical boot button almost entirely, if such should be your wish.