Whole_ALTO_World_Newsletter_1977 1980 Whole ALTO World Newsletter 1977

Whole_ALTO_World_Newsletter_1977-1980 Whole_ALTO_World_Newsletter_1977-1980

User Manual: Whole_ALTO_World_Newsletter_1977-1980

Open the PDF directly: View PDF .
Page Count: 389

Download
Open PDF In Browser	View PDF

Xerox
Private
Data

Whole ALTO World Newsletter
Technology and Tools

XEROX

December 31, 1977

SPECIAL ANNOUNCEMENTS
WHOLE ALTO WORLD MEETING - The next Whole Alto World meeting is scheduled to
be held from 9AM- 3PM, February 7, 1977 at XEOS in Pasadena. Liz Bond is our hostess.
The last page of the newsletter is a flyer announcing the meeting. Please detach your copy
and post it on an appropriate bulletin board. See you all at the meeting!

GENERAL NOTES
WRC JOINS THE NETWORK - On December 17th the line connecting the gateway at
Webster with the gateway at PARC became operational. This, and the soon to be installed
IFS, will promote the sharing of tools and information, much of which is currently under
development at WRC. Attached to the newsletter is a diagram of the current network.
HARDWARE CATALOG - The first edition of the Alto Hardware Catalqg is included with
this issue of the newsletter. It lists by hardware type, e.g. Printers, Scanners, etc., devices
that have been hooked to an Alto or the Ethernet. For an item to be included at least one
working, reproducable copy must exist. Gathering this type of information tends to be a
hit- or- miss proposition so if you know of an item that should be included, please contact
the coordinator. It could save someone a lot of time and effort searching for or designing
and building something that already exists.
TIME STANDARD CHANGE - The Alto's internal date and time standard is going to be
changed because it is: 1) location dependent (WRC's Altos indicate PST), and 2) not
monotonic (daylight saving time). The change will involve modifications to the Operating
System and subsystems that deal wi th dates and times.
It is suggested that users update their disks promptly as subsystems are rereleased. Version
14 of the Operating System and a new release of BRAVO are expected at the end of January.
Subsystems that incorporate the time standard changes, such as the afore mentioned
BRA va, will SWAT on the current Operating System (version 13). Old subsystems will
continue to operate in the current manner on the new Operating System until April 30th
when they begin reporting in GNIT.

If you maintain such subsystems you should read  AltoTinle.bravo and
(Taft>Time.tty. Briefly, the current standard is a 32- bit integer denoting the number of
seconds since midnight, January 1, 1901, PST. It is manually reset for Daylight Savings time
as appropriate. The new standard will denote the number of seconds since midnight,
January 1, 1901, GMT. This time will be modified by local time zone, begin daylight
savings date, and end daylight savings date. These parameters will be kept in server hosts
(gateways, IFSs, etc.) and in reserved locations in Alto main memory and on Alto disk (for
the convenience of stand- alone Altos), and updated whenever a timeserver is accessible.

Whole ALTO World Newsletter

~v~ Xerox
~Q~ Private
~O'" Data

PROPRIETARY INFORMATION • The patent department, in response to specific
questions of general interest and after consulting with appropriate members of management,
has made the following recommendations on Alto, Dover, and Sequoia.
What can we tell job applicants during an interview?

Only information that Xerox has made public or is otherwise in the public domain.
Can we demonstrate Alto to outsiders using University of Rochester software?

Yes. (Ed note: A list of public software is being developed.)
Can Consultants and/or Co· op students work on Alto?

Yes, providing they each sign an appropriate agreement containing a confidential
disclosure provision.
Can outsiders see Dover or Sequoia?

They may be shown the outside of the units providing each has signed an
appropriate agreement containing a confidential disclosure provision. The internals
may not be shown.
Can consultants be shown Dover or Sequoia?

Only information absolutely necessary to perform the consulting services may be
shown, and then only if the consultant has signed an appropriate agreement
containing a confidential disclosure provision.
Can the outP:It from Dover or Sequoia be distributed outside Xerox?

Yes, provided the copy does not identify its source or method of generation.

TOOLS
HARDWARE
DEAD ALTO'S . The following text was received in a memo from Ron Cude this last
month. It is filed on [MAXC]  DeadAlto.memo.
This memo is intended to point out a potential problem that some of you may be experiencing with
your Alto U's. Have you ever had your Alto not want to re- boot after running out of the Cram? If
so there may be a fix.
To see if this is your problem, you will need two files:
Ramload.run and AltoIICode2.mb
Try the following:
Ramload AltoIICode2.mb/F O/V cr
Ramload will display some information and ask for a confirm. After confirming, it will load the
Cram with the .mb file. When it comes back and says Boot?, confirm with a carriage return. The .mb
file is now running out of the Cram. Type Ramload/T and confirm with a cr. Ramload will write
random numbers into the Cram blowing up your Alto (not literally, just the microcode). If you can
now re- boot, you don't have the problem. If you can't re- boot, you have the problem and should
investigate as shown below.

2

Whole ALTO World Newsletter

~V1~ Xerox

~.Q~ Private

~LJ~ Data

Check your Cram module (assy. #216365) to make sure that note K. (page 2 of the Cram module
print) has been done. This note is an etch cut to hole next to label "R7". If this etch cut has not
been made, it will blow one and possibly two components on the Disk Control module. If the cut has
not been made, please make it and also install a new MPQ3303 in A1 on the Disk Controller and a
new 74HOO in All also on the Disk Controller. If your Cram module already has the etch cut but you
are experiencing the problem anyway, try replacing the same two components on the Disk Controller.

ALTO II ENGINEERING CHANGES· A list of the current revision levels for Alto II
components was mailed this last month to the people that perform Alto maintainence.
Future Engineering Orders will also be mailed as they are ready for distribution. If you
maintain Altos and have not received the current revision level list, contact the coordinator.

SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available
from your local IFS under the directories < Alto> and < AltoDocs>. If they are not available
or if you are in doubt about the version, they may be retrieved from [MAXC] under the
appropriate directory. Files stored under other directories are on [MAXC] unless otherwise
indicated, such as [XEOS].
NEW RELEASE: CALCULATOR - This boot program from Joe Maleson pictures a TI SR52 on the display which is operated by using the mouse to select the appropriate keys. Not
all functions are implemented (Le. it is not programmable). It may be run by booting the
NetExec and entering "calculator" or by booting while depressing the , It, ], and
 keys. Documentation is the SR- 52 manual.
NEW RELEASE: MICROFLOA T - Joe Maleson has made available a microcoded version of
the FLO AT package. It is four to six times faster than the assembly language version (about
80 p,sec for multiply and divide, 40 p,sec for add and subtract). The documentation,
< AltoDocs> Float.tty, is appended.
NEW RELEASE: SIGMA/ETH . This is a pair of subsystems by Thomas Holladay and
Keith Knox to transfer arbitrary ,files between an Alto and a SIGMA 3 over the Ethernet.
They will be made available on request. The documentation, a Xerox Internal Report
"Ethernet Software for Data Transfer between the SIGMA 3 and an ALTO", Accession No.
X7704459, has not been included with the newsletter.
NEW RELEASE: SPLINE - This is a set of packages by Patrick Baudelaire to both compute
cubic splines and to map them onto an Alto display bitmap. The documentation,
Spline.tty, is appended.
NEW RELEASE: TYPE - This is a small subsystem by Roger Bates for use in place of the
Executive supplied "type."''' that displays a larger page, suppresses Bravo trailer information,
can backup, etc. It can be retrieved from Type.run and is documented under
< AltoDocs)Type.tty. The documentation is appended.

ReRcleases .- Subsystems
COpy DISK . This version fixes a bug which prevented copying the second disk of a twodisk system. The change makes this new version incompatible with previous version. The
new version is available on boot servers or may be retrieved from  DMT.boot(17- Dec-77) and boot servers
(Gateways are boot servers). If you have access to a Gateway~ simply delete DMT.boot from
your disks and the executive will automatically retrieve it when you "quit".
EMPRESS· In addition to several bug fixes, the new version applies the / c option to press
files, will merge two or more single page press files appending one additional press or text
file if specified, and can personalize individual copies of a document. It is filed on
 Empress.run(14- Dec-77). The documentation,  Empress.tty (14- Dec-77),
has been revised.
PEEKSUM . Peek disks should be rebuilt periodically using PeekDisk.cm. See the revised
documentation  DMT .tty.

TECHNOLOGY
Several methodolgies of information retrieval are being investigated at the Webster Research
Center. One of them, QUANSY~ is an empirical natural language question- answering system
by A vi Ben David. Currently operating at the forth grade level over a narrow range of
subjects (as measured by standard tests)~ the next level of QUANSY is expected to show
substantially improved capability.
Three papers have been written and will soon be available as Xerox Internal Reports
(Accession numbers are not yet assigned). The first, "A Parser Analyser of Emperical
Design for Question- Answering"~ AFIPS Conference Proceedings, NCC, Vol. 46, pp. 669678~ is easily available and so is not reproduced here.
The second paper, "A Memory
Structure of Empirical Design for Question- Answering", presents the relationship bctween
natural language and the empirically developed memory structures.
The most recent of the papers "Memory Interaction and Question- Answering in the
QUANSY Question- Answering System" provides a sample dialog, an overview of the system,
brief descriptions of the parser- analyser, memory structures and question- answering
routines, and an in- depth discussion of concepts behind the intcraction between the parseranalyser and memory structures.

4

Whole ALTO World Newsletter
Technology and Tools

XEROX

February 28, 1978

SPECIAL NOTE
NEW OPERATING SYSTEM· As previously announced, the timestandard implementation
is being changed. This last week a new OPERATING SYSTEM and BRAVO were released.
As future releases of this and other subsystems will not necessarily operate properly with the
old operating system, you should change over as soon as possible by retrieving and
executing NEWOS.cm from your local IFS or MAXC. You will need about 300 free pages
on your disk. Check with your local support people for special procedures. The
documentation,  OS.press, has been revised.

GENERAL NOTES
WHOLE ALTO WORLD MEETING· The Whole Alto World meeting was hosted by Liz
Bond of XEOS in Pasadena on February 7, 1978. Fifty- five people, representing virtually
every Alto using group, attended.
The Distributed Message System(DMS), an upcomming, Alto- based replacement for the
MAXC MSG system, was described by Frank Ludolph. Under DMS, messages are stored on
IFS stations (or MAXC for the immediate future) only during transit. Received messages
will be stored on the user's Alto disk in one or more user- designated files managed by Alto
resident software. The user interface will be familiar to Alto users, consisting of several
windows, menus, and Bravo style editing facilities. Although it is a research project, it is
expected that DMS will be available to MAXC MSG users this summer.
Dick Sonderegger, SD Support, reports that MESA is now available through the Whole Alto
World coordinator on a limited basis, by specific request, and depending on the proposed
application.
The language is still evolving and should not be used for long term
development projects. Questions and problems should also be channeled through the
coordinator's office to  .
Barry Smith, Sheldon Raizes, Terry Anderson, and lrv Keschner, lawyers with the Xerox
Patent Department, attended the meeting to discuss the methods used to protect intellectual
property, trade secrets, patents, and copyrights, as they apply to the Alto. Barry will be
working with W AW in the near future to develop written material on this subject. The
material will be printed in the Newsletter when it becomes available.
Terry Haney spoke on SPG's board repair activity. Boards should be sent to Terry, along
with a description of the problems and, if from Orbit or Dover, a copy of the printer's
output. Boards are logged and their repair scheduled in conjunction with SPG's other
activities.
Jim Hall announced that his 1200 group is very interested in providing maintenance service
for as many Altos as possible. Existing spares inventories can be turned in for credit.
Contact Jim for pricing particulars.

Whole ALTO World Newsletter
The 7th Alto build will proceed on schedule according to Doug Stewart. This will be the
last Alto build. There has been some difficulty obtaining 7000 bases for the Dover build
(marketing has been quite successful in placing them recently), but it is not expected to
significantly delay Dover deliveries.
Sam Losh of XEOS reports that Sequoia development is continuing. He requested that
organizations interested in obtaining Sequoias contact him. If there is sufficient interest,
deli veries could begin in the fall.
John Ellenby briefly described Advanced Systems Division's role in marketing test probes
based on Alto technology. ASD has requested information on the Fuji Xerox mag brush
developer, used on their 7200, for possible retrofit to Dover. The unit would improve solid
area development. Additional information will be printed in the Newsletter as it is
available.
The reasons for developing Altos as gateways were outlined by Ted Strollo. Essentially, the
current Novas present maintenance problems, the small memory (32K) prevents further
software development, and the Nova operating system is not as malleable as the Alto's. The
number of gateways is expected to increase to as many as ten this year. Though the DO will
eventually be used in this capacity, they will not be available for this application for some
time.
The meeting was then adjourned to permit attendees to see the Boca Raton Insurance tape,
hosted by John Ellenby, and demonstrations of the touch screen (Dave Moulding), Smalltalk
(Alan Kay), FIRST (Bob Datolla), and HSIL (Marion Suggs, Paul Lam).
ALTO MAINTAINERS MEETING· A meeting of Alto maintainers was held of February
8th, 1978 at EI Segundo. The meeting was hosted by Doug Stewart, SPO. The primary
subjects of discussion were hardware problem areas, centralized repair reporting, and SPG
repair service.
The biggest problem area seemed to be the disk drives. Typical adjustments for the read
gate are 460/440 n sec for the long/shoft one shots though this may vary from drive to
drive. Also, the write head current is normally cut past track 128 due to the reduced track
length. Cutting resistor F- 63 on the J-I0 board to raise write head current is common but
Diablo advises against it suggesting instead that the value of resistor H - 64 (part of the same
voltage divider network) be varied starting with lK and working down as necessary. The
heads should be cleaned periodically (approximately 3 months) using a lint free material
such as TexWipes. Q- Tips should not be used as they will leave fibers on the head.
Aligmnent is generally performed after cleaning heads. So~e groups keep spare heads for
replacements.
The 15 volt Sorenson power supply (and to an extent the 12 volt supply) is the other major
problem area~ As these units are under a five year warranty they should be returned to the
manufacture. Sorenson will also update units returned for repair.
It's useful to have a few memory chips on hand as this is the most common chip failure and
it is easy to repair. Bad 16K memory chips should be returned to Terry Haney for failure
evaluation. Memory Chips rnay be purchased from SPO. These are the only chips available
from that group.
Keyboards have multiple character and mechanical sticking problems.
The Key test
diagnostic can be used to adjust the key producing multiple characters. The electronics are
on the AIM module and keyboard printed wiring board.

2

Whole ALTO World Newsletter
Modules will be repaired by spa in conjunction with their other activities. No headcount is
specifically assigned to repair acti vity. Boards should be returned to Terry Haney along with
a description of the problem and, if applicable, a copy of printer output.
There is considerable interest in developing a repair data base. The only data of this type
currently available is maintained by Jim Hall's 1200 group on the machines maintained by
them under contract. Doug Stewart will set up a mechanism for collecting failure
information including net address, date, subsystem affected, serial number (if applicable),
failure symptoms, and corrective actions. Jim Iverson reports that a paper log is currently
being kept for each machine in his group for the convenience in the multiple user
environment and to identify recurring failures in a specific unit.
It was requested that Frank Ludolph set up a system to more quickly disseminate
maintenance information.
ALTO MAINTAINTER'S MESSAGE LIST· An immediate result of the Alto maintainers
meeting is
the
establishment of a
MAXC MSO
distribution
list file,
 AltoMaintainers.msg, to Simplify the communication of general interest
information among Alto maintainers. To use this feature when sending a message, the
response to ''TO:'' is "t b  AltoMaintainers.msg CR CR The rest of the sndmsg
procedure is normal. The message will be sent to all accounts listed in the .msg file.
It.

MESSAGING FOR SPECIAL INTEREST GROUPS . The same messaging mechanism
referred to in the preceeding item is used by several special interest groups including; AIS,
PROM (ProLog users), SIL, and AltoMaintainers. If you are actively involved in any of
these are sndmsg to Jennette  for inclusion. A complete listing of all distribution
lists can be retrieved from [MAXC]  All.masterlist.
DON'T LEAVE YOUR DISK IN AN ALTO· As pointed out in a recent issue of SDD's
Randotll Items, a disk is locked inside the Alto's disk drive when power is removed from the
unit or when the 15 volt power supply fails. Failure of this supply is one of the most
common Alto ailments. It is suggested that you not leave your disk in an Alto overnight.

TOOLS
HARDWARE
NEW HARDWARE MANUAL - The Alto Hardware manual has been revised and made
available in Press format. If your print server does not have two disk drives, the file
 AltoHardware.press may have to be broken into two pieces using PRESSEDIT
and the pieces sent to the printer.
ORBIT BUG· Severo Ornstein reports that there is a timing problem in the Orbit adapter.
It appeared that Pimlico had problems aligning the sucessive color passes on a page. In
reality the Output Scanline counter (SLN /SLWN) wasn't resetting properly due to a race
situation resulting. from an ding the clock pulse with the clear level using an N163
(synchronous clear). This situation also exists with Dover but isn't very noticable because it
shifts the image by only a fraction of a band.
The fix is simple; replace the three N163s in locations 02, 03, and 04 on the Input board
with N161s. Severo suggests that the fix be made on all Orbits, regardless of attached
printer, because it could create a very difficult bug to locate someday if printers are
exchanged.

3

Whole ALTO Wortd Newsletter
MAKING A DUAL· DRIVE ALTO· Doug Stewart has written a memo listing the items
necessary to connect a second drive to the Alto. All items can be ordered directly from
Diablo. The memo is appended to the Newsletter.
DISK DIAGNOSTIC DOCUMENTATION
Jim Cucinitti recently wrote some
documentation for the Model 31 disk diagnostics that have been in use for quite sometime.
It describes diagnostic initiation, use of the debugger, understanding the failure data, and
modification of the diagnostics. It is intended for maintainers only. The document, which
of
the
programs,
can
be
retrieved
from
includes
assembler
listings
[MAXC]  Subsystems> AISmagnify .run.
The
documentation
is
[WRC]  MEMOS> AISmagnify.press.
BRA VO • The new version, 7.1, contains bug fixes and implements the new time standard.
It will be retrieved and installed automatically when installing the new operating system.
Documentation
on
the
new
color
facilities
can
be
retrieved
from
[ IRIS] < Bravo> ColorBravoChanges.bravo.
CHA T· This rerelease, TTY version 9, Display version 15, contains bug fixes and minor
improvements. Retrieve < Alto> Chat.run. The documentation, Chat. tty , is updated to
include the I and 0 commands which toggles the USER.cm entry TYPESCRIPTCHARS.
COPYDISK • This subsystem, found on boot servers, has been updated to include the new
time standard.
DMT • This subsystem, found on boot servers, has been updated to include the new
timestandard. Also, the bug in the Dec. 10 version, which fails to indicated the bad RAM
chip location, has been corrected.
IFS . The new release, 1.14, includes commands for accessing and manipulating file
protections. Users should retrieve and read < IFS> HowToUse.prcss.
PRESSEDIT . An experimental release of this subsystem can be found on
 PressEdit.run. The documentation PressEdit.tty is on the same directory. It
provides a new, simpler method of combining illustrations with text documents. Official
release will occur in March after sufficient testing. The experimental version is reasonable
robust.
PROM· The nature of the changes is unknown to me. Retrieve < Alto>PROM.run. New
documentation is available on < EOD> PROM.bravo.
seA VENGER - The nature of the changes is unknown to me.
unchanged. Retrieve < Alto> Scavenger.run.

The documentation is

SETTIME - The new version implements the new timestandard. Is is automatically
retrieved when installing the new operating system with NewOS.cm.
SIL . Several changes have been made and are summarized in < SIL> SILupdates.press.
Retrieve < SIL> SlL.run. The documentation SILmanua1.press and SILsummary.press, also on
 , have been revised.

ReRclcases - Packages
ALTODEFS, ALTOFILESYS, DISKS, STREAMS, SYSDEFS . These definition files have
changed in conjuction with the new operating system. If they currently reside on a disk they
will be updated when NewOS.cm is run. For a description of changes see the change history
in the rereleased OS Manual.

5

Whole ALTO World Newsletter
TECHNOLOGY
This month's paper, GUS, A Frame- Driven Dialog System by Daniel Bobrow, Ronald
Kaplan, Martin Kay, Donald Norman, Henry Thompson, and Terry Winograd, is the third
in a series on methods of making machines more amenable to the naive user. While this
work is strictly research and not being performed on Altos, it gives us a glimpse of possible
future directions.
The Understander project at PARe is exploring the process of language comprehension and
the cognitive structures and operations which underlie it. GUS was written to assess
progress and suggest area of future effort.

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not
to pe shown to non· Xerox people. Copies are available on [MAXC]  WAWnews.press or may be
obtained from the editor, Frank Ludolph, XEOS, by messaging  or calling Intelnet 8*923·4356.

6

GUS,

A Frame- Driven Dialog System

Daniel O. Bobrow, Ronald M. Kaplan, Martin Kay,
Donald A. Norman, Henry Thompson, Terry Winograd1
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

GUS is the first of a series of experimental computer systems that we intend to construct as
part of a program of research on language understanding. In large measure, these systems
will fill the role of periodic progress reports, summarizing what we have learned, assessing
the mutual coherence of the various lines of investigation we have been following, and
suggesting where more emphasis is needed in future work. GUS (Genial Understand er
System) is intended to engage a sympathetic and highly cooperative human in an English
dialog, directed towards a specific goal within a very restricted domain of discourse. As a
starting point, GUS was restricted to the role of a travel agent in a conversation with a client
who wants to make a simple return trip to a single city in California.

There is good reason for restricting the domain of discourse for a computer system which is
to engage in an English dialog. Specializing the subject matter that the system can talk about
permits it to achieve some measure of realism without encompassing all the possibilities of
human knowledge or of the English language. It also provides the user with specific
motivation for participating in the conversation, thus narrowing the range of expectations
that GUS must have about the user's purposes. A system restricted in this way will be more
able to guide the conversation within the boundaries of its competence.

MOTIV ATION AND DESIGN ISSUES
Within its limitations, GUS is able to conduct a more- or-less realistic dialog. But the
outward behavior of this first system is not what makes it interesting or significant. There
are, after all, much more convenient ways to plan a trip and, unlike some other artificial
intelligence programs, GUS does not offer services or furnish information that are otherwise
difficult or impossible to obtain. The system is interesting because of the phenomena of
natural dialog that it attempts to model and because of the principles of program
organization around which it was designed. Among the hallmarks of natural dialogs are
unexpected and seemingly unpredictable sequences of events. We describe some of the forms
that these can take below. We then go on to discuss the modular design which makes the
system relatively insensitive to the vagaries of ordinary conversation.

1 This work was done by the language understander project at the Xerox Palo Alto Reseach Center. Additional
affiliations: D. A. Norman, University of California. San Diego; H. Thompson, University of California,
Berkeley; and T. Winograd, Stanford University. To appear in Artificial Intelligence, Spring 1977 (8:1)

2
Problems of natural dialog.

The simple dialog shown in Figure 1 illustrates some of the language- understanding
problems we attacked. (The bracketed numbers are for reference in the text). The problems
illustrated in this figure, and described in the paragraphs below, include: allowing both the
client and the system to take the initiative, understanding indirect answers to questions,
resolving anaphora, understanding fragments of sentences offered as answers to questions,
and interpreting the discourse in the light of known conversational patterns.
Mixed Initiative. A typical contribution to a dialog, in addition to its more obvious
functions, conveys an expectation about how the other participant will respond. This is
clearest in the case of a question, but it is true of all dialog. If one of the participants has
very particular expectations and states them strongly whenever he speaks, and if the other
always responds in such a way as to meet the expectations conveyed, then the initiative
remains with the first participant throughout. The success of interactive computer systems
can often be traced to the skill with which their designers were able to assure them such a
dominating position in the interaction. In natural conversations between humans, however,
each participant usually assumes the initiative from time to time. Either clear expectations
are not stated or simply not honored.

attempts to retain the initiative, but not to the extent of jeopardizing the natural flow of
the conversation. To this extent it is a mixed- initiative system (see Carbonell, 1970a, 1970b).
This is exemplified in the dialogue at [1] where the client volunteers more information than
GUS requested. In addition to his destination, the client gives the date on which he wants to
travel. Line [3] illustrates a case where the client takes control of the conversation. GUS
had found a potentially acceptable flight and asked for the client's approval. Instead of
either giving or denying it, the client replied with a question of his own.
GUS

Indirect answers. It is by no means always clear what constitues an answer to a question.
Frequently the purported answer is at best only a basis on which to infer the information
requested. For example, when GUS asks "What time do you want to leave?" it is seeking
information to constrain the selection of a flight. The client's response to this question, at
[2], does constrain the flight selection, but only indirectly. In general, the kinds of
inference necessary to interpret indirect answers can be very complex. GUS can handle the
problem in its simpler manifestations, thanks largely to the very narrow expectations it has
about the subject matter and the client's goals.
Resolving anaphora. A central issue in dialog is ensuring that both parties understand a
given word or phrase as referring to the same object or event (see Norman and Rumelhart,
Chapter 3, 1975 for a discussion of the general problem of reference). One problem occurs
when a short phrase refers back to sOlnething that was introduced earlier. GUS provides for
this problem in some of its simpler manifestations. At line [3], for example, the client's
query refers to the flight m·entioned in GUS'S immediately
preceding utterance. In [4] there
,
is a reference to the flight mentioned earlier in the conversation, at (2). Note that "next
flight" in [3] was to be interpreted relative to the order of flights in the airline guide
whereas "first one" in [4] refers to the order in which the flights were mentioned. Another

3
implicit referent underlies the use of "Friday" to specify a date in [6]. Resolution of this
reference requires some complicated reasoning involving both the content and the context of
the conversation. Since May 28th has been given as the departure date, it must presumably
be the following Friday that the client has in mind. On the other hand, suppose that the
specifications were reversed and Friday had been given as the departure date at line [ 1]. It
would then be most readily interpretable as referring to the Friday immediately following
the conversation.

GUS:

[1]

Client: I want to go to San Diego on May 28 .
GUS:

[2]

I have confirmed the following flight:
P.S.A. flight 102 on Wednesday May 28 from San Jose to San Diego
that leaves at 7 :30 AM and arrives at 9 :15 AM.
What date do you want to return on?

Client: On Friday in the evening
GUS:

[7]

In what name should I make a reservation, please?

Client: Dan Bobrow
GUS:

[6]

Air California flight 310 that leaves at 8:30 AM and arrives at 10:00 AM

Client: I'll take the first one
GUS:

[5]

Would you like P.S.A. flight 102 that arrives at 9:15 AM?

Client: What is the next flight?
GUS:

[4]

What time do you want to leave?

Client: I must be in San Diego before 10 AM
GUS:

[3]

Hello. My name is GUS. I can help you plan a simple trip by air.
Where do you want to go?

Would you like the flight that leaves at 7:45 PM?

Client: That's fine.
GUS:

Figure 1.

I have confirmed the following flight:
P.S.A. flight 307 on Friday May 30 from San Diego to San Jose
that leaves at 7:45 PM and arrives at 9:30 PM
Thank you for calling. Goodbye.

A transcript of an actual dialog with GUS

Sentence fragments. Utterances in natural conversation are by no means always complete
sentences. This is not to say that there are no rules governing the ways in which fragments
can be used. We collected a number of dialogs between people and examined the sentence

4
fragments that occurred: most appeared as answers to direct questions. Furthermore, a rule
can almost invariably be derived from a question that will convert a fragmentary answer into
a complete sentence expressing the same information. For example, the client's response in
[5] to the request for a name is not a sentence but, when inserted in the blank space in the
skeleton "You should make the reservation in the name of _ _ It, it yields a sentence.
Nonnal processing of the sentence so constructed gives the required interpretation of the
fragment. This works even for the fragment in [6] which is not even a complete phrase. 1

IThe SRI speech system (Walker, et al., 1975) uses a number of other techniques for handling a different set of
fragments.

These skeletons are systematically related, in the sense of transformational grammar, to the
corresponding questions. The blank space in the skeletons usually occurs at the end. If SgaU
and the linguists of the modern Prague school are right, then this follows from a strong
tendency to organize sentences so that given information comes at the beginning and new
infonnation at the end. In this case, the given information is clearly that which is shared by
the question and its answer.

Conversational patterns. Conversations conform to patterns, which are still only poorly
understood, and there are specialized patterns that are used in special circumstances such as
those that obtain in a travel agency. Realism requires that GUS fit its conversational strategy
to these patterns. For example, flights are usually specified by departure time, but in
response to [2], GUS specifies an arrival time, because the client had specified the arrival
time to constrain the choice of flights. This is in accordance with a typical conversational
convention; a speaker says as little as will suffice to communicate the point to be made.
Grice [1975] calls these conventions conversational postulates and implicatures.
It seems also to be important to use conversational implicatures with respect to the goals of
the client and the system in interpreting and generating the dialog (see Gordon & Lakoff
(1972) for a general discussion of this issue). For example, in [1] the client says where he
wants to go. GUS interprets this as a request for an action, that is, inserting the appropriate
information into the travel plan being generated.

Principles of program organization
One of the major methodological issues we addressed in designing and building GUS was the
question of modularity. We realize that language understanding systems, and other systems
exhibiting some degree of intelligence, will be very large and complicated programs, and the
flow of processing within them will be correspondingly complex. As Simon (1969) has
pointed out, one way of reducing the complexity of a system is to decompose it into simpler,
more readily comprehensible parts, and to develop and debug these in isolation from one
another. When the separate modules have been constructed, however, the task of integrating
them into a single system' still remains. This can be difficult: truly complex systems are
more than just the sum of their parts; The components, when put together, interact in subtle

5
but important ways. We implemented GUS in order to determine whether a modular
approach for a dialog system was at all feasible and to test our notions of what reasonable
lines of decomposition might be. We are aware of alternative decolnpostions, and are not
committed to this one; it was convenient given the program modules already available, and
the issues we wished to focus on. GUS provided a context in which to explore tools and
techniques for building and integrating independent modules.
The major knowledge- oriented processes and structures in GUS- - the morphological analyzer,
the syntactic analyzer, the frame reasoner, and the "language generator- - were built as
independent processes with well defined languages or data structures to communicate across
the interfaces. They were debugged separately, and tied together by means of an overall
asynchronous control mechanism.

Control: The organization of the system, is based on the view that language- understanding
systems must operate in a multiprocess environment (Kaplan, 1973b, 1975). In a system with
many knowledge sources and a number of independent processes, some part of the
mechanism must usually be devoted simply to deciding what shall be done next. GUS puts
potential processes on a central agenda. GUS operates in a cycle in which it examines this
agenda, chooses the next job to be done, and does it. In general, the execution of the selected
task causes entries for new tasks to be created and placed on the agenda. Output text
generation can be prompted by reasoning processes at any time, and inputs from the client
are handled whenever they come in. There are places at which information from a later
stage (such as one involving semantics) are fed back to an ealier stage (such as the parser). A
supervisory process can reorder the agenda at any time. This process is similar in function
to the control module in the BBN SpeechEs system (Woods, 1974; Rovner, Nash- Webber &
Woods, 1974), except that it can resume processes which are suspended with an active process
state. Preserving the process state is necessary because the flow in the system is not
unidirectional: for example, the state of the syntactic analysis' cannot be completely
abandoned when domain dependent translation starts. If a semantically and pragmatically
appropriate interpretation of an utterance cannot be found from the first parsing, the
syntactic analyzer must resume where it was suspended. INTERLISP'S coroutine facility makes
it possible to completely preserve the active state of the various processes (Teitelman, 1976;
Bobrow & Wegbreit, 1974).
Procedural attachment. Broadly speaking, procedural attachment involves redrawing the
traditional boundary between program and data in such a way as to give unusual primacy to
data structures. Most of the procedures that make up a program, instead of operating on
separate data structures, are linked to those structures and are activated when particular items
of data are manipulated in particular ways. This technique lies at the heart of the reasoning
component which is described in more detail later. It provides a natural way of associating
operations with the classes or instances of data on which they are to operate. It is in some
ways extensions of ideas found in SIMULA (Dahl & Nygaard, 1966) and SMALLTALK
(Goldberg and Kay, 1976).
Monitoring and debugging:
In a multiprocessing system with processes triggered by
procedures attached to complex data structures, special tools are needed for programmers to

6

monitor the flow of control and changes in the data structures. Tightly linked with the
agenda scheduler there is a central monitor with knowledge about how to summarize the
current actions of the system. The monitor interprets special printing instructions associated
with potential actions and particular items of data. In effect, the principle of procedural
attachment has been extended to debugging information.
External data-bases: We believe that an important application of specialized dialog systems
like GUS may be to help users deal with large files of formatted data. In the travel domain,
the Official Airline Guide is such an external data- base. GUS can use an extract of this database, but the information in the file does not form part of its active working memory for
the same reason that the the information in the Official Airline Guide does not have to be
memorized by a travel agent. Only that portion of the data base relevant to a particular
conversation need be brought into the working memory of the system.

7
PROCESSES AND KNOWLEDGE BASES

Figure 2 illustrates the knowledge structures and processes in GUS. Each numbered row
corresponds to a single knowledge based process in the system. The input to each process is
shown in the left hand column. Each input is labelled with a number in parentheses
indicating the row number of the process which produces it. Processes usually provide input
to the ones listed below them. The third column names the process which produces the
output structures specified in the fourth column, using for the processing the permanent
knowledge bases specified in column two.

Input Structures

1. Text String
word
(input)
structures

Permanent Knowledge
Structures

Processes

Output Structures

Stem dictionary;

Dictionary lookup;

Morpholog ical

Morpholog ical

'rules
2. Query context(6);
of a
Chart(1)
sentence

Transition

3. Parsing of a
frame
sentence (2)

Case-frame

4. Case-frame
Frame change
structure (3)
description

Speech patterns;

net grammar

dictionary

Domain specific

Chart of
data·

analysis
Syntactic

Parsing

analysis
Case-frame
analysis

Casestructure

Domain dependent
translation

frame forms
5. Frame change
Frame change
descriptions(4,5);
descriptions
Current frame
response
instances (5)
descriptions;

Prototype frames
and attached
procedures

Frame
reasoning
Output

Current

8

frame
instances
6. Output response
Dialog query map;
Eng !ish text;
description (5)
Flight description
context
template

Response
generation

Query

Figure 2. Knowledge structures and Processes in GUS

Figure 3 shows the output structures of the earlier stages of processing of the sentence "I
want to go to San Diego on May 28
Starting with an input string of characters typed by
the client, a sequence of words is identified by a lexical analyzer consisting of a dictionary
lookup process and a morphological analysis. The analysis program has access to a main
dictionary of more than 3,000 stems and simple idioms and a body of morphological rules
specifying how the information in the dictionary can be used to partition character sequences
into known lexical items (Kay & Kaplan, 1976). The output of this stage is a chart (Kay,
1973), a table of syntactic and semantic information for use by the parser.
ft.

CLIENT: I want to go to San Diego on May 28
[S

MOOD =DCL
... the syntactic analysis of the input
SUBJ =[NP HEAD =[PRO CASE =NOMIN NUMBER =SG ROOT =1]]
FVERB =[V TENSE =PRESENT ROOT =WANT]
HEAD =WANT
OBJ =[S MOOD =FOR-TO
SUBJ =1
HEAD =[ V TENSE =PRESENT ROOT =GO]
MODS =(
[PP PREP =[PREP
ROOT =TO]
POBJ =[NP HEAD =[NPR PROPERTYPE =CITY-NAME
ROOT = SAN-DIEGO]]]
[PP PREP =[PREP
ROOT =ON]
POBJ =[NP HEAD =[NPR PROPERTYPE =DATE-NAME
MONTH =MA Y DAY =2811])]]
[CLIENT DECLARE
... the case' frame structure
(CASE FOR WANT IE (TENSE PRESENT)
(AGENT (PATH DIALOG CLIENT PERSON»
(EVENT (CASE FOR GO (TENSE PRESENT)
(AGENT (PATH DIALOG CLIENT PERSON»
(1'0- PLACE (CASE FOR CITY
(NAME SAN- DIEGO»)
(DATE (CASE FOR DATE
(MONTH MAY)

9
(DAY 28]
CMD: [CLIENTDECLARE
... the domain dependent translation, a
(FRAME ISA TRIP- LEG
... frame change description
(TRA VELLER (PATH DIALOG CLIENT PERSON»
(TO- PLACE (FRAME ISA CITY
(NAME SAN- DIEGO»)
(TRA VEL- DATE (FRAME ISA DATE
(MONTH MAY)
(DAY 28]

Figure 3. Processing the client's first utterance

The syntactic analyzer is based on the General Syntactic Processor (Kaplan, 1973a). Using a
transition- network grammar and the chart, the parser builds one or more canonical syntactic
structures, depending on whether or not the sentence is syntactically ambiguous. It finds one
parse, and can continue to find others if the sentence is ambiguous and the first parse is
rejected as uninterpretable by a later process. The syntactic analysis of the input sentence is
shown in Figure 3.
The case- frame analysis uses linguistic knowledge associated with individual lexical items to
relate their appearance in canonical syntactic structures to their uses in a semantic
environment. It uses a dictionary of case- frames based on the ideas of case grammar
originated by Fillmore (1968; see Bruce, 1976 for a general review of case systems). This
cOlnponent uses knowledge about such things as selectional restrictions and the mapping
between surface cases (including prepositions) and semantic roles. As seen in Figure 3, the
cases for GO are AGENT, TO- PLACE, and DATE.
As we have already observed, interpretation of an utterance must include knowledge of
conversational patterns for the appropriate domain. Domain dependent interpretations of
utterances were implemented by a simple structure- matching and reconstruction program
that operates on case- frames. The example in Figure 3 illustrates how the domain- dependent
translation module handles a COlnmon conversational pattern for the travel domain: it
interprets a statenlent of desire (the WANT IE) as an instruction to insert the specified event
into the trip plan being constructed. In addition, the case frame involving GO is transformed
into a description of the TRIP- LEG which is part of the planned trip, with the AGENT of GO
beconling the TRAVELLER in the TRIP- LEG and the DATE becoming the TRA VEL- DATE. This
simple translation Inechanism is obviously very limited; in a more realistic system, the
purposes of the client would have to be understood more deeply.
The frame reasoner component of the system was the focus of most of the research and
developnlent. It was based on the assumption that large scale structures closely tied to
specific procedures for reasoning constitute a framework for producing a mixed initiative
dialog system. It uses the frame change description (labelled CMD in Figure 3) to fill in the
appropriate information in the trip plan it is building and trigger associated reasoning, as

10

described later.
The generation of output English is guided by a query- map, a set of templates for all the
questions that might be asked by the system. GUS uses a table lookup mechanism to find the
appropriate template and generates the English by filling in the template form. This simple
generation mechanism is sufficient for the dialog system; generation was not one of the areas
of substantial work.
The module that generates questions for the client simultaneously produces one or more
skeletons into which his responses can be inserted, if they do not prove to be sentences in
their own right. What is being done here is surprisingly simple and works well for most of
the fragments we have encountered in response to simple WH- questions. Note that the
language generator communicates with the syntactic analyzer using English phrase fragments
rather than using a specially constructed formalism. This contrasts with other approaches to
the fragment problem, in which the various components of the system are more deeply
affected.

11

THE REASONING COMPONENT
Frames: It is widely believed in artificial intelligence that intelligent processing requires
both large and small chunks of knowledge in which individual molecules have their own
sub- structure. Minsky's 1975 paper on frames discusses the issues and suggests some
directions in which to proceeed. But, as Minsky stated, his ideas were not refined enough to
be a basis for any working system. Our intuitions about the structure of knowledge resemble
However, our
Minsky's in many ways, and we have appropriated the word frame.
conceptions are by no means identical to Minsky's, and the two notions should not be
confused. The frame structures used in this system were a first step towards a more
comprehensive knowledge representation language whose current development is described in
Bobrow and Winograd (1977).
Frames are used to represent collections of information at many levels within the system.
Some frames describe the sequence of a normal dialog, others represent the attributes of a
date, a trip plan, or a traveller. In general, a frame is a data structure potentially containing
a name, a reference to a prototype frame, and a set of slots. Frame names are included
primarily as a mnemonic device for the system builders and are not involved in any of the
reasoning processes. In fact, names are not assigned to any of the temporary frames created
during a dialog.
If one frame is the prototype of another, then we say that the second is an instance of the
first. A prototype serves as a template for its instances. Except for the most abstract frames
in the permanent data base, every frame in GUS is an instance of some prototype. Most
instances are created during the process of reasoning, although some (for example those
representing individual cities) are in the initial data base.
A frame's important substructures and its relations to other frames are defined in its slots.
A slot has a slot- name, a filler or value, and possibly a set of attached procedures. The
value of a slot may simply be another frame or, in the case of a prototype, it may be a
description constraining what may fill the corresponding slot in any instance of the given
frame. Figure 4 shows the prototype frame for date and the specific date May 28, which has
no external name. The fact that it is an instance of date is indicated by the keyword ISA
followed by the prototype name.
The date prototype illustrates several of the ways in which the values for instance slots can
be described. For example, the slot labelled MONTH specifies that only a name can be used as
value; that is, only a literal LISP atom. GUS interprets a standard set of type terms such as
name, integer, list, and string. The slot for WEEKDAY stipulates that a value for that slot
must be a member of the list shown in the frame. 'The slot DAY can only be filled by an
integer between 1 and 31. The terms BOUNDED-INTEGER and MEMBER have no special
meaning to the interpreter. Any LISP function may occur in this position as a predicate
whose value must be non- NIL for any object filling the slot.
Not all of the slots of an instance frame need to be filled in. For example, in May 28, only
the MONTH, and DAY are filled in, and not the WEEKDAY. A prototype frame provides slots

12
as placeholders for any data that might be relevant, even though it may not always be
present. Only those slot values which are required for the current reasoning process need be
put into instances.

[DATE
MONTH
DAY
YEAR
WEEKDAY

a.

NAME
(BOUNDED- INTEGER 1 31)
INTEGER
(MEMBER (SUNDAY MONDAY TUESDA Y WEDNESDAY THURSDAY
FRIDA Y SA TURDA Y)]

Prototype for date
[ISA DATE
MONTH
DAY

MAY
28]

b.

The instance frame for May 28
Figure 4. Examples of frames

Procedural attachment: We have already referred to procedural attachment, a concept first
discussed by this name by Winograd (1975), as a central feature of GUS. Procedures are
attached to a slot to indicate how certain operations are to be performed which involve
either the slot in the given frame or the corresponding slot in its instances. We have found
that there are many slots for which some processing is best done by idiosyncratic procedures.
For example, there may be special ways of finding fillers for them or for doing other kinds
of reasoning about them. This might include verifying that the value in an instance is
consistent with other known information or propagating information when the slot value is
obtained.
The procedures associated with slots fall into two general classes: servants and demons.
Demons are procedures that are activated automatically when a datum is inserted into an
instance. Servants are procedures that are activated only on demand. The expanded date
prototype in Figure 5 contains exalnples of both classes. On the slot WEEKDAY there is a
demon marked by the keyword WHENFILLED and a servant nlarked by the keyword TOFILL.
When a value is filled into the WEEKDAY slot of a date instance, the WHENFILLED statement
on the prototype causes the interpreter to invoke the demon FINDDATEFROMDAY. This
procedure attempts to compute the appropriate date to fill the other slots in the frame, using
the name of the day just entered and contextual information to identify the value uniquely.
The servant GETWEEKDA Y on the same slot is only invoked when the name of the week day

13
is needed. The requirement is satisfied by calling the LISP procedure GETWEEKDA Y with the
current instance as an implicit argument. The servant attached to the slot YEAR indicates
how a default value can be filled in. If the year is given by the client, then this servant will
never be activated. However, if the client does not mention the year explicitly, the system
will fill in the default value 1975 when any part of the reasoning process calls for it.

[DATE
MONTH
DAY
YEAR
WEEKDAY

NAME
(BOUNDED- INTEGER 1 31)
INTEGER (TOFILL ASSUME 1975)
(MEMBER (SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY
FRIDA Y SA TURDA Y»
(WHENFILLED FINDDA TEFROMDA Y)
(TOFILL GEJWEEKDA Y»
SUMMARY (OR (LIST MONTH DAY) WEEKDAY»]

Figure 5.

The frame for date with attached procedures and summar!}' form

The system provides a number of standard servant procedures. ASKCLIENT causes the client
to be asked for information that will determine the value of the slot. CREATEINSTANCE
indicates that a new instance of a specified prototype should be created and inserted at that
location. Some of the values of the newly created frame may be filled in by the procedure,
others may be left to be filled through later reasoning or interaction with the client. In
addition to standard servants, the builders of the system can program special procedures to
cOlnpute appropriate values, such as the GETWEEKDA Y mentioned earlier.

Summarizing data structures. In Figure 5, the frame for dHte includes a slot with the special
name SUMMARY. A SUMMARY slot appears only in a prototype frame, never in an instance.
It gives a format for describing the instances of the prototype to heJp programmers monitor
and debug the system. Thus, instances of date will be described by printing the month and
day, e.g. (May 28) or, if they are not known, just the day of the week.

14
USING FRAMES TO DIRECT THE DIALOG

Frames are used at several levels to direct the course of a conversation. At the top level, GUS
assumes that the conversation will be of a known pattern for making trip arrangements. To
conduct a dialog, the system first creates an instance of the dialog frame outlined in Figure
6. It goes through the slots of this instance attempting to find fillers for them in accordance
with the specifications given in the prototype. When a slot is filled by a new instance of a
frame, the slots of that instance are filled in the same way. GUS follows this simple depthfirst, recursive process, systematically completing work on a given slot before continuing to
the next. This is how GUS attempts to retain the initiative in the dialog. Notice, however,
that slots may occasionally be filled out of sequence either through information volunteered
by the client or by procedures attached to previously encountered slots.
In Figure 6, boldface atoms are frame names, representing pointers to other frames.
(Substructures for the frames for Person, Date, City, PlaceStay, TimeRange, and Flight are
not shown.) Each of the slots shown in Figure 6 must be filled in during the course of the
dialog, usually by invoking a servant attached to the prototype slot. The servants for some
slots calculate the desired values from other known data, or (as in the case of frames like
TripSpccification) simply create a new frame. The servant ASKCLIENT obtains information
needed to fill a slot by interrogating the client. The default organization of a dialog is
determined by the order of the slots which have ASKCLIENT as servant, since appropriate
questions will be asked if those slots have not been filled by the time they are encountered.
Now let us follow the system as it goes through part of a dialog, with special emphasis on the
process of filling in the slots of frames. The dialog and the relevant information about the
state of the system are shown in Figure 7. This figure is the beginning of an actual
transcript of a session, and the information shown there is provided to allow us (in the role
of system builders) to follow the actions of the system.
The dialog starts when GUS outputs a standard message ("Hello. My name is GUS. I can help
you plan a simple trip by air."). At this point, GUS knows that it is about to conduct a dialog
on travel arrangements, so it creates an instance of the prototype Dialog frame shown in
Figure 6 and starts to try to fill its slots. (From now on, all numbers in brackets refer to the
corresponding lines of the frames of Figure 6. All references to the dialog refer to Figure
7.) The slot CLIENT at [1] contains a servant which fills this slot, when necessary, by
creating a new instance of Person. This is indicated in the first line of the transcript of
Figure 7, where the instance of person is shown as {ISA PERSON}. After the slot is filled in, a
demon associated with the CLIENT slot is triggered, which then puts the same person instance
in the TRAVELLER slot in [16]. GUS fills the NOW slot in [2] by constructing a frame
instance for today's date. It then creates a TripSpecification instance [3], summarized by
ROUNDTRIP TO ? in the transcript of Figure 7, to fill the TOPIC slot [3].

15

Slots

Fillers

Servants

CLlEN,};

Person
Create
GetDate
Date
TripSpecification Create

Demons

Dialog

[ 1]
[ 2]
[ 3]

NOW
TOPIC

Link to TRAVELLER

TripSpecification

[ 4]
[ 5]

HOMEPORT

[ 6]
[ 7]
[ 8]

OUTWARDLEG

FOREIGNPORT

City
City

Default - Palo Alto
Link to OUTWARDLEG,

TripLeg
PlaceStay
TripLeg

Create

AWAYSTAY,INWARDLEG
AWAYSTAY
INWARDLEG

Create

TripLeg
[9]
[ 10]
[11]
[ 12]
[13]
[ 14]
[ 15]
[ 16]

City
City
Date
TimeRange
TimeRange

FindFrom HOMEPORT
AskClient
TRAVELDATE
AskClient
Propose- Flight- By- Departure
DEPARTURESPEC
AskClient
Propose- Flight- By- Arrival,
ARRIVALSPEC
Link to DEPARTURESPEC
PROPOSEDFLIGHTS (Set Of Flight)
FLIGHTCHOSEN
Flight
AskClient
TRAVELLER
Person
AskClient
FROMPLACE

TOPLACE

F'igure 6. An outline of key frame structures for our dialog

At this point the Dialog frame has been completely filled in so GUS proceeds to fill in the
slots of the TripSpecification frame. In [4], a HOMEPORT which is a City is required; GUS
assumes, on the basis of an attached servant, that the home port is Palo- Alto. There is no
attached servant to find the FOREIGN PORT in [5], so GUS just leaves that slot empty for the
moment. When a TripLeg instance is created for the outward leg of the journey, GUS begins
trying to fill its slots. A servant for FROMPLACE specifies that it should be filled with the
city used for HOMEPORT in the TripSpecification frame, so PaJoAlto is filled in. The first slot
which has an ASKCLIENT servant is at [ 10], which requires a city to fill the TOPLACE in the
Trip Leg, which is the OUTW ARDLEG of the TripSpccification [6].
GUS issues the command
(CMD) shown at the bottom of Figure 7, which directs the generation of the English
question. This is done by a rather elaborate table look up: the result is shown as the last line
of Figure 7.

16

GUS: Hello. My name is GUS. I can help you plan a simple trip by air.
CLIENT ={ISA PERSON} in {ISA DIALOG}
TODA Y =(MA Y 15) in {ISA DIALOG}
TOPIC =(ROUNDTRIP TO ?) in {ISA DIALOG}
HOME-PORT =PALO-ALTO in (ROUNDTRIP TO 1)
FROM- PLACE =PALO- ALTO in (TRIP TO 1)
CMD: (GUSQUERY (DIALOG TOPIC TRIP-SPECIFICATION OUTWARD-LEG TRIP-LEG
TO- PLACE CITY»
GUS: Where do you want to go?

Figure 7. The beginning of the transcript for the dialog

We continue the trace of the analysis in Figure 8, starting with the client's response to the
question. The domain dependent translation contains the information needed to fill the
frame slots. The result of the client's English input is that both the TOPLACE [10] and the
TRA VELDATE [11] of the TripLeg are filled in.
The system then continues working its way through the entire tree specified by the frames,
asking questions of the client. Many of the slots have demons which propagate information
to other places in the data structure. For example, when the city that fills the slot
FOREIGNPORT [5] is found, GUS will insert that same City as the place to stay in the
AWAYSTAY [7]. The FOREIGNPORT city also serves as the destination of the OUTWARDLEG of
the trip and the starting point of the return trip (the INWARDLEG). To handle this
information, GUS estabishes two instances of the frame TripLcg, one for the outward leg, the
other for the inward leg, and puts the city names in the appropriate slots.
Once a departure specification (some time range before, near or after the desired flight
departure) is determined, a delTIOn attached to DEPARTURESPEC calls a program which uses
this information to propose a flight. Each proposed flight is added to the slot for
PROPOSEDFLIGHTS [14]. This slot can be used to resolve anaphoric references to flights,
based on the order of their mention in the conversation. GUS then tries to determine which
of the flights is appropriate to fill in the FLIGHTCHOSEN slot [15]. When that has been
determined, it . will ask for the name of the traveller and confirm the flight.
Many of the slots are marked in such a way that they need not be filled for the dialog to be
completed. For example, the arrival specification [131 in each TripLeg frame is never
requested. This slot is provided as a place to put constraints about the arrival of the flight,
if the client volunteers information constraining the desired arrival time. Demons associated
with that slot would then be activated to propose a flight based on the arrival time. In a

17
similar way, the AWAYSTAY slot in the trip specification [7], is never asked for. If the client
specifies something about the time range of the AWAYSTAY, as he did in the dialog of Figure
1, there is a place to store that information in the frame structure and a demon to put it into
the appropriate TripLeg.

CLIENT: I want to go to San Diego on May 28
CMD: [CLIENTDECLARE
... the domain dependent translation
(FRAME ISA TRIP- LEG
(TRA VELLER (PATH DIALOG CLIENT PERSON»
(TO- PLACE (FRAME ISA CITY
(NAME SAN- DIEGO»)
(TRA VEL- DA TE (FRAME ISA DATE
(MONTH MAY)
(DAY 28]
TO-PLACE =SAN-DIEGO in (TRIP TO ?)

... filling in the requested information

TRA VEL- DATE =(MAY 28) in (TRIP TO SAN- DIEGO) ... and the volunteered information
dowhen TO- PLACE is put in (TRIP TO SAN- DIEGO)
...propogating information to other slots
(LINK TRIP- SPECIFICA TION FOREIGN- PORT CITY)

Figure 8. The reasoning from the first input utterance

Figure 9 illustrates how a sentence fragment is processed. GUS asks "What date do you want
to return on?" Generation of the question also generates a context for the expected
interpretation of the next answer. The context is an inverted form of the question; that is, "1
want to return" is a potential prefix to the next response. The preposition "on" may be
optionally inserted in this prefix. The client responds "on Friday in the evening". Since this
is not a sentence, the question context is used in the interpretation and the actual parsed
structure which is interpreted is derived from the sentence "1 want to return on Friday in the
evening."
The time is taken as a departure specification and the date is specified in terms of the day of
the week. The day of the week is filled, into the appropriate place and date, and then the
demon associated with that slot in date is activated. That demon cOlnputes the date relative
to the previous date specified in the conversation. The phrase evening is taken as being
equivalent to "around 7 :30 PM". From this departure specification, GUS proposes the flight
that leaves nearest to that tilne. Information is provided to the client about the leaving time,
not the arrival time, because the client constrained the choice of flight by leaving time.

18

GUS: What date do you want to return on?

... a query generated by GUS

The context of the next answer is:
(I WANT TO RETURN «ON) (*SKIP*») - -

... The expected context of the query response

CLIENT: On Friday in the evening
CMD: [CLIENTDECLARE
... the domain dependent translation, including context
(FRAME ISA TRIP- LEG
(TRAVELLER (PATH DIALOG CLIENT PERSON»
(TRA VEL- DATE (FRAME ISA DATE
(WEEKDA Y FRIDAY»)
(DEPARTURE-SPEC (FRAME ISA TIME-RANGE
(DAY-PART EVENING]
WEEKDA Y = FRIDA Y in {ISA DATE}
dowhen WEEKDAY is put in {ISA DATE}
(FINDDA TEFROMDA Y)

... triggering a demon to find the I?riday's date

DA Y =30 in (MAY 30)
DA Y- PART =EVENING in {ISA TIME- RANGE}
...evening is interpreted as around 7:30 PM
DEPARTURE-SPEC =(AT 7 30 PM) in (TRIP TO PALO-ALTO)
dowhell DEPARTURE- SPEC is put in (TRIP TO PALO- ALTO)
(PROPOSE- FLIGHT- BY- DEPARTURE)
... this demon proposes a flight using a departure spec
GUS: Would you like the flight that leaves at 7:45 PM?
CLIENT: That's fine.

Figure 9. Processing a sentence fragment

This sample dialog illustrates how GUS attempts to control a conversation by fitting it to the
mold laid down in a structure of related frames. It has a place prepared in this structure for
each piece of information that might potentially be used for making travel arrangements. It
also has a strategy that will cause the pieces of information that the client must supply to be
elicited in a natural order. The sequence of slots in the frames determines the usual course
of the conversation, but it will change if, for example, the client volunteers information or
asks questions.

19
REAL ·AND REALISTIC DIALOGS

There is an important difference between real and realistic conversations. The simple
dialog in Figure 1 is a realistic conversation that was actually carried on with GUS. It is
much too easy to extrapolat~ from that conversation a mistaken notion that GUS contained
solutions to far more problems than it did. To get an idea of some problems that GUS does
not approach, we collected a variety of travel dialogs that clients of a full- fledged system
(perhaps the final version of GUs) might expect to conduct. We did this by simulating the
system, asking the clients to arrange for round trip air flights between Palo Alto and San
Diego, typing all queries and responses on the computer terminal, and pretending that a
computer system was interacting with them. In fact, the role of GUS was played by an
experimenter sitting at another computer terminal, airline guide, travel books, and calendar
in hand, responding to the client.2

2 The experimental dialogs were collected by Allen Munro in the LNR research laboratory at the University of
California. San Diego.

GUS
CLIENT
GUS

Do you want a flight leaving at 4:00 PM
Do you have something a little closer to 7
Do you want the flight at 7 :00 PM
a) Interpreting politeness

GUS
CLIENT
GUS
CLIENT
GUS

Do you want the flight arriving at 8:00 PM
When does it leave?
6:30 PM
How much?
$25.50 round trip
b) Some pronominal reference problems

GUS
CLIENT

When would you like to return?
I would like to leave on the following Tuesday, but I have to be back before
my first class at 9 AM.
c) Giving a reason for flight preference

Figure 10. Fragments of real dialogs, with a person simulating the role of GUS

The two participants - - client and experimenter - - were each seated in independent,

20
individual sound- isolated experimental booths.
They communicated with a special
experimental program (designed for tutorial instruction) that presented the experimenter's
responses in a block presentation, so it appeared as a realistic approximation of a computer
output, without the slow typing rate that would occur otherwise. The system delays were
approximately what one would expect for the operation of a complex program (10 to 60
seconds response time).
Some of the problems we found were unexpected. For example, people spent a lot of time
telling us about their thought processes and reasons. They made excuses for changing their
minds. They hedged a lot about what they wanted. Figure lOa illustrates a type of
conversational interaction our current system cannot even begin to handle. When the system
proposes a flight at 4 PM, the client requests something a little closer to 7. A literal
interpretation of that request would be to find a flight that is as close to 4 PM as possible,
but in the direction of 7 PM: perhaps the 5 :00 PM flight. That, of course, is not at all what
was desired by the client. The human experimenter made the natural response of offering
the flight that left at 7.
Figure lOb indicates some pronominal reference problems which we did not attack at all.
When the client says "when does it leave" it is quite obvious that he wants the departure time
of the flight referred to in the previous sentence. For his question "how much," a response
that "all of the plane leaves" seems somewhat inappropriate. In this case, the client is not
referring to the previous system response, but rather is asking about the cost of the flight.
But a response such as "how much" can sometimes refer to the previous system response.
Suppose the system had just stated "They serve food on that flight." In this case, the client's
query could be appropriately interpreted by the system as referring to the quantity of food.
GUS cannot solve the problem of determining when a response is meant to refer to the
previous question and when it is not.
Figure IOc illustrates how people provide extra information about their motivations. In a
system with a better model of human needs and desires, this would be useful for suggesting
alternatives that might otherwise be ruled out.
CONCLUSION
Computer programs in general, and programs intended to model human performance in
particular, suffer from an almost intolerable delicacy. If their users depart from the
behavior expected of them in the minutest detail, or if apparently insignificant adjustments
are made in their structure, their performance does not usually change commensurately.
Instead, they turn to simulating gross aphasia or death. The hope, which has been at least
partially realized in GUS, is that the notions of procedural attachment and scheduling, as well
as being realistic cognitive models, will make for more robust systems. We were pleased, for
example, by the way the system's expectations could evolve in the course of a single
conversation. The client would occasionally seize the initiative, volunteering information
that was not asked for or refusing to answer a question as asked and GUS was able to respond
appropriately in many cases. It would be misleading to press these claims too far. GUS never
reached the stage where it could be turned loose on a completely naive client, however

21
cooperative. But, to one familiar with other systems of the same general kind, the
impression of increased robustness is clear.
represents a beginning step towards the construction of an intelligent language
understanding system. GUS itself is not very intelligent, but it does illustrate what we believe
to be essential components of such a system. An intelligent language understander must have
a high quality parser, a reasoning component, and a well structured data base of knowledge.
The knowledge is of several types, from language specific information and expertise in the
topic areas in which it can converse to broad general knowledge of the world that must be
used to interpret people's utterances. This knowledge tends to be taken for granted by most
native speakers of the language, hence often left for the listener to infer. The system must
be capable of giving direction to the conversation, but it must also be flexible enough to
respond to novel directions set by the clients. The system must be able to make use of a
large external data base and to understand what information must be retrieved and processed
in depth. There must be an intimate connection between its representation of structural
knowledge and the procedures used to process knowledge. A general framework for
representing knowledge must be able to enCOlnpass all the different necessary forms of
knowledge. In our future studies of GUS, we intend to broaden the general framework for
representing knowledge, as well as to increase the power of the components of the system.
Preliminary steps in this direction include the development of improved systems for
language analysis (Kay & Kaplan, 1976) and a knowledge representation language (KRL:
Bobrow & Winograd, 1976).
GUS

22

References
Bobrow, D. G. & Collins, A. M. (Eds.) Representation and Understanding:
Cognitive Science. New York: Academic Press, 1975.

Studies in

Bobrow, D. G. & Wegbreit, B., A model and stack implementation of multiple environments,
Communica tions of the ACM, 1973, 16, 591- 603
Bobrow, D. G. & Winograd, T. An overview of KRL, a Knowledge Representation Language.
Cogniti ve Science. Vol 1. No 1. 1977
Bruce, B., Case systems for natural language.

Artificial Intelligence, 1975, 6, 327-360.

Carbonell, J. R.
AI in CAl: An artificial intelligence approach to computer- aided
instruction. IEEE Transactions on Man- Machine Systems, 1970, MMS-II, 190- 202.
Carbonell, J. R. Mixed- initiative man- computer instructional dialogues. Unpublished Ph.D.
dissertation. Cambridge, Mass: Massachusetts Institute of technology, 1970.
Dahl, O. J., & Nygaard, K., SIMULA- - an ALGOL- Based
Communications of the ACM, 1966, 9, 671- 678.

Simulation

Language,

Fillmore, C. The case for case. In E. Bach and R. T. Harms (Eds.), Universals in Linguistic
Theory. New York: Holt, 1968.
Goldberg, A. & Kay, A. (Eds.) SMALLTALK-72 instruction manual. Xerox Palo Alto Research
Center SSL-76- 6. Palo Alto, Ca. 1976
Gordon D., & Lakoff, G., Conversational postulates, Papers from Seventh Regional
Meeting, Chicago Linguistic Society, Chicago: University of Chicago Linguistics Department,
1972.
Grice, H. P. Logic and conversation. In P. Cole & J. L. Morgan (Eds.), Studies in Syntax,
Volulne III. New York: Seminar Press, 1975.
Kaplan, R. A general syntactic processor. In R. Rustin (Ed.), Natural language processing.
New York: Algorithmics Press, 1973a.
Kaplan, R. A multi-processing approach to natural language. Proceedings of the 1973
National Computer Conference. Montvale, N.J: AFIPS Press, 1973b.
Kaplan, R. On process models for sentence analysis. In Norman, D. A., Rumelhart, D. E.,
and the LNR Research Group. Explorations in cognition, San Francisco: Freeman, 1975.

23
Kay, M. The MIND system.
Algorithmics Press, 1973.

In R. Rustin (Ed.) Natural language processing.

New York:

Kay, M. & Kaplan, R. Word recognition. Palo Alto, California: Xerox Palo Alto Research
Center, 1976.
Minsky, M. A framework for representing knowledge. In P. Winston (Ed.), The psychology
of computer vision. New York: McGraw- Hill, 1975.
Reddy, D. R., Erman, L. D., Fennell, R. D., & Neely, R. B. HEARSAY speech understanding
system: An example of the recognition process. Proceedings of the Third International
Joint Conference on Artificial Intelligence, Stanford University, August 1973.
Norman, D. A., Rumelhart, D. E. and the LNR Research Group, Explorations in cognition.
San Francisco: Freeman, 1975.
Rovner, P., Nash- Webber, B., & Woods, W. A. Control concepts in a speech understanding
system. Proceedings of the IEEE Symposium on Speech Recognition, Carnegie- Mellon
University, April 1974.
Simon, H. Sciences of the artificial.
Press, 1969.

Cambridge:

Teitelman, W. INTERLISP reference manual.
Research Center, December, 1975.

Massachusetts Institute of Technology

Palo Alto, California: Xerox Palo Alto

Walker, D., Paxton W., Robinson, J., Hendrix, G., Deutsch, B., Robinson, A. Speech
understanding research. Annual report, Project 3804. Artificial Intelligence Center. Stanford
Research Institute, 1975.
Winograd, T. Frames and the dec1arative- procedural controversy, In D. G. Bobrow and A. M.
Collins (Eds.), Representation and Understanding. New York: Acad~mic Press, 1975.
Woods, W. A. Motivation and overview of BBN SPEECHLIS: An experimental prototype for
speech understanding research. Proceeding of the IEEE Symposium on Speech Recognition,
Carnegie- Mellon University, April 1974.

Inte r- Office Memo randum

To

File

Date

February 3, 1978

From

Dick Shoup

Location

Palo Alto

Subject

Color and the Alto

Organization

SSL

Filed on [XEOS]  Hardware> ColorOnAlto.press

I'm frequently asked about the possibility of putting a color display on the Alto.
quick summary of what I know about the subject.

o.

Here's a

Contact me for additional info.

History

About

3

years

ago

I

modified

an

Alt01

to

provide

maxc(shoup)coloraltodoc.press or .bravo for more details.)

a

color

display.

(See

Its characteristics were:

640x480 points in a 525-line raster, 4:3 aspect ratio (standard TV format), 1 or 2 bits/pt or
320x240 points at 4 bits/point. Thus full resolution in 2- or 4- color mode, half resolution in
16- color mode. Colors displayed on the screen were determined by table lookup ("color
map") so that, for example, in 2 bit/pt mode any 4 colors in the range of the display
phosphors could be used. This color display replaced the standard Alto 875- line display.
The color Alto was subsequently remodified to again have a standard display due to lack of
interest in color at that time and because of lower resolution and partial incompatibility with
respect to the standard display.

1. The facts of life.
The bandwidth required to drive a 525-line standard TV raster, 4:3 aspect ratio and square
pixels (same resolution horizontally as vertically) is about 12 Mpts/sec.

The bandwidth

required is therefore 12 x n, where n is the number of bits/point. Thus a 2- bit/pt picture
requires 24 Mbits/sec of peak bandwidth.
The total available Alto memory bandwidth (shared among all devices via the CPU
microcode) is about 32 Mbits/sec.

Of this, the standard Alto display uses about 20

Mbits/sec (also 20 Mpoints/sec since it's 1 bit/point). The extended memory Alto has no
more bandwidth, just more memory.
Monitors: Standard 525· line color monitors are readily available and cost from $300 to $6K
depending on size and quality.

Recently, double- density shadow- mask CRTs (twice as

many color phosphor dots) have become available. Text and small detail look much better
on these tubes than conventional ones, even at the same 525· line scanning rates.

2
However, such monitors currently cost $3K to $6K. Higher line- rate monitors using these
CRTs are also becoming available, but their cost is currently )$10K.

AU color monitors

have some misconvergence, especially near the edges of the screen.

This annoyance is

often quite noticeable on text or other sharp edges. Trinitrons have color stripes instead of
dots and thus exhibit less convergence error, but are lower resolution than color dot CRTs.
Flicker can be quite noticeable on color CRTs at standard 30 frame/sec rate, particularly
with text and small detail.

Slower color phosphors are not readily available.

2. Alternatives.
There are several major alternatives to consider for a color display capability on the Alto:
2.1 With a reasonable amount of effort.
2.1.1 As the primary (working) display, compatible (i.e., 875-line, 3:4 aspect).

This

alternative is the simplest, but only 2 colors are possible due to bandwidth limitations.
However, by judiciously loading the color table, different pairs of 2 colors can be
displayed in different bands on the screen (See color Alto document). Monitor very
expensive.

Convergence and flicker may be quite annoying for day- to- day use.

2.1.2 As the primary (working) display, incompatible (conventional 525-line is the
only reasonable alternative).

This was the color Alto solution described above.

480x640 =300K pixels as compared to 808x606 =480K pixels with the standard Alto
display. Compatible in the sense that scan lines in the color Alto are longer (640 vs.
606) so that most display bit maps will display properly (operating system exec,
Bravo, etc.) and the displayed area will just be shorter in the vertical direction.
bits/pt (4 colors) possible at full resolution.
2.1.3 As a secondary (additional) display.

2

Convergence and flicker.

If the standard Alto display remains

available, then questions of software compatibility are avoided. Both displays could
not be on at the same time,however, due to bandwidth limitations.
2.2 More radical schemes. Other possibilities include: increasing the memory bandwidth
via a new memory card or memory bus design, plugging in some new memory which
contains the display bit map, encoding color pictures (run or area coding) and accessing
via a new display controller, encoding color information separately and combining it with
the bit stream from the standard display controller, etc.

Inter- Office Memorandum
To

ALTO II Users

Date

February 23, 1978

From

Doug Stewart

Location

El Segundo

Subject

Second Disk Drive For ALTO

Organization

ED/SPG

XEROX
Filed on: [XEOS]  Hardware>SecondDisk.press

The following is a list of all of the equipment required to put a second Diablo Model 31
disk drive on an ALTO system. All may be purchased directly from Diablo.
Item

Qty. Req'd

Description

1

1

Model 31 disk drive, PIN 15532- 06, with:
Option - 004, 1562 KBS
Option - 019, Extended format

2

1

Power Cable, PIN 11188

3

1

Cable, Diablo P /N 11245- xx, where xx is .
the length in inches (should be about 60
inches if drive is to sit on top of ALTO
cabinet).

c: Frank Ludolph

Whole ALTO World Newsletter
Technology and Tools

XEROX

January 31, 1978

SPECIAL ANNOUNCEMENTS
FINAL ALTO II SPARES BUILD· spa is now taking orders for the final Alto II Spares
Build. This is for Alto II boards excluding accessories such as Orbit and Trident. TI,e
closing date for this build is March 1, 1978. Contact Terry Haney, SPG.
WHOLE ALTO 'VORLD MEETING· The next Whole Alto W orId meeting is scheduled to
be held from 9AM to 3:30PM February 7,1978, in the Green Room at XEOS, Pasadena. Liz
Bond is our hostess. The topics discussed will include maintenance, build activity,
protection of intellectual property, software, and a demonstration of Smalltalk.

GENERAL NOTES
SUBSYSTEMS CATALOG . The Subsystems Catalog has been revised to include new
subsystems and a functional cross reference. The latter aids in locating a program to
perform a gi ven task. When a program has been located, the alphabetical listing can be used
to obtain a more complete description and direction to the documentation.
ALTO NETWORK DIAGRAM· This diagram, illustrating server location by Ethernet, has
been revised to include the servers' names and addresses. A copy is attached.

TOOLS
HARD\VARE
ALTO II WORKSTA lION MULTIPLEXER ADAPTER· An Alto II Keyboard Buffer is
now available that permits the Workstation Multiplexer to be used with Alto II keyboards.
(The multiplexer itself is used to build a 4X4 arrangement of Altos and workstations such
that any workstation may be manually switched to any Alto for exclusive use.) Cost of the
keyboard buffer is $275 plus $125 per workstation interface (one per Alto II workstation).
Also required are cables and the tllultiplexer (total cost is $2.5K to $3K depending on exact
configuration).
TRIDENT MULTIPLEXER . The following was excerpted from a message by Ron
Freeman, SPG:
The 74161s used for the sector counters on the Trident Multiplexer boards are being used improperly
resulting in erroneous operation of the sector counters unless the 74161 happens to be manufactured by
National Semiconductor...
As this problem does not exist in the design of the 74LS161. an E.O. is being written to use the LS
device for this design.
Several of these modules have been delivered and installed in Alto lIs, all apparently with the National
part used. You can suit yourselves as to the desirability of replacing the 74161s on these units;
however, should theY' be returned to spa for repair in the future, the 74161s will be replaced at that
time with the 74LS161s.

Whole ALTO World Newsletter

2

SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available
from your local IVY server under the directories < Alto> and < AltoDocs>. If they are not
available, or if you are in doubt as to the version, they Inay be retrieved from [MAXC]
(same directories). Files stored under other directories are on [MAXC] unless otherwise
indicated, e.g. [XEOS].
ReReleases • Subsystems
CHA T • Minor fixes have been made and a curve displaying protocol added.
< Alto>Chat.run. The documentation is unchanged.

Retrieve

FIND . Enhancements to this subsystem include switches to distinguish upper and lower
case, to print the entire Bravo paragraph containing a match, and to print all text between
blank lines containing a match. Retrieve  Find.run. Updated documentation is
available from < AltoDocs> Find.tty.
FRED· The restriction limiting the range of character codes to 7- bit ASCII has been lifted.
Load < Alto> Fred.dm. The documentation is unchanged.
MADTEST· The nature of the changes are unknown to me. This subsystem is available
from the bootserver or retrieve < Alto> Madtest.run. There is no documentation.
OEDIT· This subsystem has been extended to provide a simple search command and to
Retrieve < Alto>Oedit.run.
New
display a range of values for rapid browsing.
documentation is on < AltoDocs>Oedit.tty.
SCA VENGER . Changes involve improved DiskDescriptor reconstruction.
< Alto> Scavenger.tty. The documentation is unchanged.

Retrieve

SETTIME . If this subsystem is unable to obtain the date and time from a time server, it
will now display an appropriate message and prompt you to type in the date and time. It
has also been altered for the new time standard. Retrieve SetTime.run. The updated
documentation is on < AltoDocs> SetTime.tty.
TYPE . This version fixes the bug that caused long lines to scroll off of the top of the
screen. Retrieve < Alto> Type.run. The documentation is unchanged.

ReReleases . Packages
ETHERBOOT· This new version conforms to the new time standard, can direct its bootload request to a specific address, and can take alternative action if a boot-load request fails
to be honored. The documentation, < AltoDocs> EtherBoot.tty, has been updated.
GP . This package for parsing command lines deletes the DefaultArg routine and slightly
alters the ReadParam routine.
The revised documentaion may be retrieved from
 GP.tty.

Whole ALTO World Newsletter
DOCUMENTA 'fION DISCREPANCY • It has been reported that there is a discrepancy
between the documentation and implementation of the UtilStr package. For the routine
DblSub, the parameters DblMinuend and DblSubtrahend are reversed. Also, the DblDiv
routine returns the remainder in the first word and quotient in the second, not a 32- bit
quotient as some have understood the documentation to say.

TECHNOLOGY
The topic of this month's paper is the emergence of an applied psychology that can be used
by designers to develop user interfaces, to predict user performance on various design
alternatives, and, in some cases, to compare it to the theoretical limit. While a substantial
theory does not yet exist, the authors present a view of what an applied psychology might be
like and assert that a sufficient amount of knowledge exists now to begin impacting the
human side of Office Information Systems.

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not
to be shown to non- Xerox people. Copies are available on [MAXC] < AltoDocs) WAWnews.press or may be
obtained from the editor, Frank Ludolph, XEOS, by messaging SilManua1.press.
SORT: a very small subsystem which will sort files containing less than 1000 entries
delimited by a carriage return.
DOCUMENTATION: Subsystems.ears.
SPRUCE: a printer server that utilizes the ORBIT buffer to drive Press printers, e.g. Dover
and Sequoia.

6

ALTO SUBSYSTEMS CATALOG

Xerox
Private
Data

DOCUMENTA TION: Under revision.
SW AT: a emulator-level code debugger with BCPL oriented features used with the Alto
operating system.
DOCUMENT ATION: Swat.tty or Subsystems.ears.
SYS.BOOT: the operating system boot file on the Alto disk.
DOCUMENTATION: None.
TFU: a file utility used to initialize a Trident pack with a virgin file system and to perform
various file copying, deleting, directory listing operations. This is not a part of the IVY
System, rather it initializes and maintains packs operated on by the TFS package.
DOCUMENT ATION: TFS.tty or Sybsystems.ears.

TRANSFILE: a part of the ICARUS2 System that translates the intermediate files generated
by Mike into human- readable form. The files it produces are fully instantiated.
DOCUMENTATION: [MAXC] < ICARUS) TransfileDoc.press.
TRIEX: a Trident diagnostic used to initialize, verify, and exercise Trident disk packs and
drives.
DOCUMENTATION: Self-contained.

TYPE: a functional replacement to the Executive supplied "type ..... " that displays a larger
page, suppresses Bravo trailer information, can skip forward and backward, etc.
DOCUMENTATION: TYPE.tty.
UGH: an in- core text editor utilizing both mouse and keyset.
facilities are available it is used primarily for programming.
DOCUMENTATION: UGH.tty.

While some formating

VIEWDATA: a subsystem to display on the Alto screen three- dimensional data stored as a
two- dimensional array of single- word values.
DOCUMENTATION:· ViewData.tty.

VIEWIC: a part of the ICARUS2 System that displays the data created by Mike on the Alto
screen, simulating the actions of the pattern generator.
DOCUMENTATION: [MAXC]  AltoNetwork.press

D

ALTO Server
(ALTO + Device)

O

NOVA

(G is wi pup Gateway
software)

<0

Other Resource

Whole ALTO Wor1d Newsletter
Technology and Tools

XEROX

March 31, 1978

GENERAL NOTES
MAINTENANCE NOTES· A new subsection is being added to the Newsletter to circulate
knowledge of specific hardware problems t solutions t and maintenance techniques. les
located between the HARDWARE and SOFTWARE subsections under TOOLS. While
many of the items will be directed to the people that maintain the hardware t some will be of
general interest to Alto users t so dontt just skip over this section.
MESA - The information on MESA in the last Newsletter needs some clarification.
Although MESA as a language is still evolving and should not be used outside SDD for
tightly scheduled projects t it is a reasonably robust and complete system and will be highly
compatible from the Alto to successor machines. As such it should be seriously considered
fot both short and long term projects. Remember t the W AW coordinator, Frank Ludolph t is
the MESA contact for non- SDD, non- PARC users.

TOOLS
HARDWARE
SEQUOIA BUILD . This is the last opportunity to indicate your interest in purchasing a
Sequoia from the proposed October build. Contact Sam Losh at XEOS now, Intelnet 8*8442501.
HUSHING THE TRIDENT· Jensen Engineering will custom build quiet boxes for the T80
and T300 drives. Externally the units will look identical. The prototype will be "Alto" grey
but the production color(s) is not yet certain. Preliminary price estimates are $450 to $500
for the T80 box and $350 to $400 for the T300 box. (The T80 box costs more because a
platform is necessary to raise it to the same height as the T300.) If interested please send a
message to Barbara  and . If they are not
available, or if you are in doubt as to the version, they may be retrieved from [MAXC]
(same directories). Files stored under other directories are on [MAXC] unless otherwise
indicated, e.g. [XEOS].
NEW RELEASE: AISshow.run - This new addition to the AIS (Array of Intensity Salnples)
system was written by Paul Roetling. As the name implies, the program displays AIS picture
files on the Alto screen. If the image is larger than the screen, the image will be
demagnified using a nearest neighbor algorithm. It operates on either 1 bit/pixel and 8
bit/pixel images; the 8 bit/pixel images will be displayed using a Floyd halftone routine.
Demagnified 1 bit/pixel images may show substantial Moire patterns.
Retrieve
[WRC]  Subsystems> AISshow.run. The documentation,  Memos> AISshow.memo
is appended to the Newsletter.

2

Whole ALTO Wor1d Newsletter

ReReleases .. Subsystems
AISdump .. An error which printed some incorrect values for windows of odd length was
fixed. The new version, 1.1, is available from [WRC] < AIS> Subsystems> AISdump.run.

COpy DISK .. The .,[ thisHost] device" bug has been corrected and the default value of
WRITEPROTECT is now TRUE. This subsystem is available from boot servers.
DDS .. This new version conforms to the new time standard.

Retrieve < Alto> DDS.run.

DMT .. This new version conforms to the new time standard.

Retrieve  DMT.run.

EXEcu'nVE .. This new version conforms to the new time standard, fixes a few bugs, and
has some enhancements including the ability to load CHAT, FTP, Scavenger, and NetExec
over the ethernet, a FILEST AT command to report file attributes, and a SETTIME that
obtains the time over the ethernet (delete SetTime.run). Use < Alto> N ewOS.cm to update
The documentation,
this subsystem as well as the new OS/15 and FTP.
< AltoDocs> Executive.tty, has been revised.
FTP .. The 21 March 78 version fixes more file date bugs and contains new features
including a typescript of the user window, new commands (Open, Close, and Compare) in
the command line, and improved command line error handling. This subsystem will be
updated when installing the new operating system.
See the revised documentation,
< AltoDocs> FTP.tty.
KEYTEST .. This diagnostic, available from boot servers, has been enhanced to display the
correct keyboard, i.e. Alto I or Alto II. Retrieve < Alto> KeyTesLrun only if boot servers, e.g.
gateways, are not on your ethernet.
LISTSYMS .. This new version conforms to the new time standard. Retrieve
< Alto> ListSyms.run. The documentation,  ListSyms.run has been revised.
MICRO/MICROD .. A primary reason for the rerelease is to alleviate a space constraint
which prevented certain diagnostics from assembling. Also the filename extension, .MC, is
now defaulted rather than forced. Retrieve  MICRO.run. The changes document,
< AltoDocs> MICRO.tty has been updated.
MU .. A bug which failed to give an error message when a semicolon was left off the end of
a predefinition was corrected, the filename extension now defaults to .Mu, and the listing
file contains constants sorted by value as well as by address. Retrieve  MU.run and
the revised documentation,  MU.tty.
NETEXEC .. This boot file has been enhanced to poll boot servers for the boot files they
can supply, and has some new user command functions such as PROBE and HOST. No .run
file need be retrieved. The new documentation is available on < AltoDocs> NetExec.tty.
OPERA TING SYSTEM .. This version fixes bugs in the file date code which caused the FTP
update command to fail. Retrieve and execute  NewOS.cm. Verify that there are at
least 300 free pages on your disk before executing the command file. This will also update
FTP and Executive.
PEEK .. This new version conforms to the new time standard. Retrieve < Alto> PEEK.run.

3

Whole ALTO World Newsletter
PRESSEDIT - The experimental version reported last month has been officially released. It
enables the merging of one page graphics onto a text document at any location on the
document page, so now it's an easy matter to edit text after inserting graphics (re- edit the
Bravo file, make a Press version, and remerge). It also fixes bugs concerning Private Data
Labels and very complex pages. Retrieve  PressEdit.run and the new documentation,
< AltoDocs> PressEdit.tty.
PROM - The nature of the changes are unknown to me.

Retrieve < Alto> PROM.run.

READ PRESS· The new version properly recognizes Press file elements that have just come
into use. Retrieve < Alto> ReadPress.run.
TRIEX . This release incorporates the new time standard. Do not use it under ass prior to
version 14. Retrieve < Alto> Triex.run and updated documentation, < AltoDocs>TFS.tty.
TFU . This release incorporates the new time standard. Do not use it under ass prior to
version 14. Retrieve < Alto>TFU.run and updated documentation, < AltoDocs>TFS.tty.

ReReleases . Packages
PUPPACKAGE - The new version contains changes to the BSP code that improve
performance when communicating through Gateways and also fixes several bugs. Several of
the modules have been broken into smaller pieces to permit substantial overlaying. The
documentation, < AltoDocs> PupPackage.tty, has been updated.
11ME - The new version conforms to the new time standard. If you are responsible for
subsystems that deal with time in any way, you are requested to begin converting such
subsystems to use the new software. The backward conlpatiblility measures that have been
implemented in as 14 will cesae to work correctly on April 30, 1978, so it is desirable that
the revised subsystems be released well before that time. Announcements of new releases
should include a warning that they will not work under pre- as 14 versions. Load
< Alto> Time.dm.
The packages is documented in < AltoDocs>Time.tty; the new time
standard is described in < AltoDocs> AltoTime.Bravo.
TFS . This release contains the modifications necessary to conform to the new Alto time
standard. It will run only under as 14/15. Also, the microcode source file has been broken
up to facilitate combining it with other microcode, however the microcode binary is
unchanged.
Load < Alto>TFS.dm.
Updated documentation
is available on
< AltoDocs> TFS.tty.

TECHNOLOGY
Most users are familiar with the printing of text and graphic information but there is a
third type, imaginal. Continuous tone pictures (e.g. photographs) are of this third type. The
problelTI of printing continuous tone images is essentially that of representing many shades
of grey with only black ink on white paper. A solution of the printing industry was the
halftone, a pattern (usually regular) of black dots which vary in size and, possibly, shape.
Pictures in the newspaper are an example. Two papers are included, one which describes the
halftone process and a second that presents the resolving limits of the eye, why we see
groups of black dots as multi- grey tone images.

4

Whole ALTO World Newsletter
The first, PRESS, Halftones, and You by Joe Maleson, is something of a tutorial on
halftones and the halftone process as implemented in Press. The Press specific information
applies to Press 1. Press 2 has a different halftone screen pattern and no longer uses error
distribution. The new screen pattern, similar to that used in the printing industry, has
dramatically improved image quality. Joe has written a memo describing the halftone screen
being used in Press 2. -Since the electronic form does not contain the image and graphic
information, contact Frank Ludolph by message, , or phone, 8*923- 4356, for a
copy.
There is an interesting problem in the printing of papers that demonstrate methods of image representation,
namely that of accurately representing the image. It is the appearance, not the content of the image that is
important. Since imaginal data can currently be printed at Xerox only on low speed, low volume printers
and because of distribution volume, the Newsletter contains a copy made on the 4000 copier (with resultant
image degradation). It is appended at the very end rather than in its usual place following this introduction.
An original (from the Slot- 3100) is being sent to each site for posting.

The second paper, by Paul Roetling, Visual Performance and Image Coding, presents data
on the eye's ability to resolve what it sees and develops guidelines for determining how
much information must be captured and retained in digital form to meet the eye's
requirements. Continuous tone images contain a hugh amount of data; retaining more than
necessary severly impacts storage requirements and processing times.
Paul has written several other papers of a tutorial nature that contain continuos tone images.
Check the library for the published versions because the image quality suffers in
reproduction. The first describes several methods of representing continuous tone images,
the second is a specific method for improving the appearance of halftones, and the third a
discussion of factors affecting halftone image quality.
Binary ApprOXimation of Continuous Tone Images, Photographic Science and Engineering,
Vol. 21, No.2, March/April 1977.
Halftone lVfethod with Edge Enhancement and Moire Suppression, Journal of the Optical
Society of America, Vol. 66, No. 10, October 1976.
Analysis of Detail and Spurious Signals in lIalftone Images, Journal of Applied
Photographic Engineering, Vol. 3, No.1, Winter 1977.

Paul's paper, which originally appeared in SPIE/OSA Vol. 74 (1976) Image Processing, had
to be rekeyed and the graphs redrawn for inclusion in the Newsletter. The editor accepts
sole responsibility for its appearance and accuracy.

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not
to be shown to non- Xerox people. Copies are available on [MAXC] (AltoDocs> WAWnews.press or may be
obtained from the editor, Frank Ludolph, XEOS, by messaging (Ludolph) or calling Intelnet 8*923~ 4356.

5

XEROX
To

Internal Memo

Distribution

From

Paul G. Roetling
Mgr., Image Processing Area

W128/22037

Subject

New Program AISshow.run
Version 1.0

Date

March 7, 1978

A new ALTO program, AISshow.run Version 1.0, is available from the WRC ivy system
under SUBSYSTEMS>AISshow.run. As the name implies, this program is intended to
allow a person to examine AIS picture files by presenting them on the ALTO screen.

Program Operation
When you run the program, the first screen display will come up as a menu similar to that
used in AISmagnify and AISdump (if you're not familiar with using the menu, look in the
documentation for AISmagnify). All that is needed is the picture file name, the window can
be defaulted. Selecting start will remove the menu from the screen and start showing the
picture file. If the picture window selected is larger than will fit on the screen, the image is
demagnified (by a nearest neighbor routine) so that the complete window shows on the
screen. If the selected window fits on the screen, it is shown full size without magnification,
and a notation appears above the image stating that the window is shown full size. As with
magnify and dump, the program operates on either eight bit or one bit per pixel files. If
the file is eight bits per pixel, a Floyd halftone routine is used to show the image. One bitper- pixel images are shown without halftoning. The photometry sense is noted from the
attributes and is used to show the image in the "correct" sense. A cautionary note should be
added here. Demagnificaton of bit- per- pixel halftone images may cause substantial moire
patterns. Do not assume that the moires are really in your picture unless the picture has the
notation that it is being shown at full size, in which case you are seeing the correct image.
Display control
As the image is in the process of being displayed on the screen, if you realize you do not
want that image, or already have enough to see what you wish to see, typing a control- Swill
terminate additional display to the screen, leaving the portion of the picture which it has
already displayed. In its current form, it sometimes takes a long time to produce a large
image in reduced form, thus this is a short cut.
Once the picture is completely displayed on the screen, (or stopped by control- S), a set of
instructions will appear above the picture on the screen. These are various key- in
possibilities:
I - will invert the sense of the screen. Use this if your impresssion of "correct" is different
from that in the photometry section of the file. You can tell when you are opposite to the
normal photometry because the rest of the screen will be black· instead of white.
Carriage return - will remove the picture and return to the menu.
Q - will quit the program without returning to the menu.
Escape - will reset the window parameters to full picture, remove the old display and start
displaying the complete picture without returning to the menu.

M - is used to show the area selected by the mouse (see below).
Selection by mouse
If, while the image is displayed, you point the cursor to one corner of an area you wish to
see, depress the left mouse button, move the cursor to the diagonally opposite corner of the
area you wish to see displayed, and release the left mouse button, a box will appear
surrounding the area you have just selected. If you wish to change the selection, simply
repeat the process and a new box will appear after you release the left button. If you try to
select an illegal area, for example, outside the area shown, no box will appear and any
previous one will be erased. If there is a box on the screen at the time M is keyed, the area
outlined by the box is used to define the new window both for the display and for writing
into the window parameters in the menu.
In our limited use of this program, we have found this last feature to be very useful. A file
name is selected, and the full picture is shown initially. We then use the mouse to select the
area we wish to see, key an M to see the region, repeat the process to window down further,
until we get exactly the area we want. We then use carriage return to return to the menu
and copy down the window parameters for usc in other programs as for example, magnify.
The primary purpose of this program is to allow us to experiment with user interaction both
for image display and window selection. Thus, we expect that portions of the program will
be revised frequently as we conduct experiments. We would also appreciate comments from
users on their reactions to program features. Please contact either Keith Knox or myself
with comments.
POR/sm

c: lEBollman
TMHolladay
lEStinehour
LBHolt
DEDamouth
WMReilich
LDMailloux
KTKnox

VISUAL PERFORMANCE AND IMAGE CODING
Paul G. Roetling
ABSTRACT: Sample spacing and quantization levels are usually chosen for digitizing images such that the eye
should not see degradations due to either process. Sample spacing is chosen based on the resolution (or high
frequency) limit of the eye and quantization is based on perception of low contrast differences at lower
frequencies. This process results in about 8 bit/pixel, 20 pixel/mm digitization, but, being based on two
different visual limits, the total number of bits is an overestimate of the information perceived by the eye. The
visual MTF can be interpreted in terms of perceptible levels as a function of spatial frequency. We show by
this interpretation that the total information perceived by the eye is much less than 8 bits times the number of
pixels. We consider the classic halftone as an image coding process, yielding 1 bit/pixel. This approach
indicates that halftones approximate the proper distribution of levels as a function of spatial frequency;
therefore we have a possible explanation of why halftone images retain most of the visual quality of the
original.

1. INTRODUCTION
In this paper we consider the problem of how visual performance characteristics can be
related to the average number of bits per pixel (picture element) in a sampled and quantized
image. If we establish an average number of useful bits per pixel in the sense that only
these are used by the eye, we then have a number against which to compare the efficiency of
various image coding or bandwidth reduction schemes for cases where system performance is
related to the visually perceived image quality.
It is well- known that visual performance is a function of spatial frequency. That is, at high

spatial frequencies we do not see as well as at lower spatial frequencies and, without
magnification, we cap see no detail at spatial frequencies above about 10 line pairs per
millimeter. By examining how visual performance varies as a function of spatial frequency,
we should be able to establish guidelines for image coding experiments as to which pictorial
information is useful to the eye.
In the following sections we will examine the selection of sampling interval and
quantization levels based on visual performance, thereby establishing design guidelines and a
useful number of bits per pixel as a function of sampling interval. We then examine a
simple halftone binary- image code and a similar code applied to multilevel images and
estimate the performance of these simple codes on the basis of established limits.

II. SAMPLING AND QUANTIZATION CHOICES
To bound our problem we first assume that the images will be examined at unity
magnification at normal reading distance. We lose no generality by this assumption, since
all results can be scaled by the magnification. We aSSUlTIe ideal sampling, that is, we ignore
sampling aperture effects and display spot (Kell factor 1) effects. We can then assume that
if we sample at an interval Il. we can adequately represent pictorial information to a spatial
frequency (21l.f 1.
A simple example serves to show how we use visual performance limits in everyday
estimates of coding efficiency. Let us consider the case where the image is sampled 40 times
per millimeter. By our assumptions, and the fact that the 'eye does not see detail beyond 10
line pairs per millimeter, we lose no visible information by taking alternate samples (or
perhaps averaging every pair of samples). We have therefore reduced the total number of

2

samples in the two dimensional image by a factor of four without losing perceived image
quality. Most of us would argue that this four- to-one bandwidth reduction should have
been obvious. because the information eliminated by the bandwidth reduction was
information not being used by the visual system. Thus, we tend to judge the bandwidth
reduction in terms of the visually useful information in the original.
To count the useful bits in a picture, we would certainly limit the sampling interval to
approximately 20 per tnillimeter. Similarly, we would limit the quantization levels to about
8 bits (256 levels) since we know that the eye cannot perceive more levels in the output
picture. Nevertheless, if we were to multiply 8 bits per pixel by the number of pixels (20
per millilmeter sampling interval) we get a considerable overestimate of the number of
useful bits in the image. We have failed to take into account how visual performance varies
with spatial frequency. In different words, we have established the sampling interval based
on the high frequency performance of the eye and the quantization levels based on the low
frequency performance of the eye, without taking into account the translation from one to
the other.
A

VISUAL MTF

We describe an improved approximation to the determination of visually useful bits of
information by basing ourselves on known psychophysical data on visual performance in
terms of the modulation transfer function (MTF).

2

Text books, such as Cornsweet's,

3

consider various sources of such data. Dooley gives a convenient functional form which
approximately fits most of the vision data. His fitted curve, in terms of modulation
transfer function (MTF), is given by
MTF =5.05 (e

- 0.I38f
-O.If
) (I-e
).

(1)

This curve has been normalized and f is spatial frequency in cycles per degree. The peak of
the curve represents a just detectable modulation of 0.005. The psychophysical data to
which this curve was fitted were measurements of the just detectable lllodulation of a sine
wave as a function of the spatial frequency of that pattern. It should be noted that we do
not use the data in MTF form, but rather we determine directly the detectable contrast, i.e.,
we use the original form of the experimental data.
We now assume, for our approximation, that at every spatial frequency we should quantize
levels such that the just detectable modulation represents one quantization step. If we
further assume that, for all sine waves, the average luminance was mid- grey, then the
modulation can be written
(2)
M -l\4A"X-l\4.JN =detectable difference
MAX -+MIN
total range
In other words, the number of intervals is the reciprocal of the just detectable modulation,
and the number of levels we must represent is the number of intervals plus one. That is, we
can write the number of detectable levels as a function of spatial frequency by taking out
the normalization from the given MTF curve and adding one, or
# of Levels = IOIO(e- 0.138(5v» (1- e- 0.I(5v»

+1

(3)

3

To convert from the cycles per
degree measurement common to
psychologists to the cycles per
millimeter more common in
image processing~ we have used a
conversion factor of one cycle per
millimeter equals five cycles per
degree. This curve has a peak at a
spatial
frequency
of
approximately one cycle per
millimeter.
There is evidence3
that threshold measurements are
not a good measure of visual
performance for all contrasts at
frequencies below one cycle per
To
obtain
a
millimeter.
conservative estimate~ we have
used Eq. (3) only above one cycle
mil1imeter~
using
its
per
maximum value below that point.
This curve is shown in Fig. l.

B.

100

# OF LEVELS
DISCERNABLE

10

2

8
4
6
SPATIAL FREQUENCY

10

12

Fig. l. Visual Performance Limits

VISUALLY USEFUL INFORMATION

We can now express visually useful information in a sampled and quantized picture as an
average number bits per pixel~ by utilizing the visual perfonnance curve in Fig. l. We take
an image area L by L~ sampled at an interval /:l. bytJ.~ as shown in Fig. 2a .

••

••

I//:l.

II

lid
a) IMAGE SPACE

8) FREQUENCY SPACE

Fig. 2. Image and Frequency Sampling
The visual performance data is described in spatial frequency space. We therefore convert
to the image transform space as shown in Fig. 2b. The defined transform space has a
frequency range ..±1/2d, with frequency samples spaced at intervals IlL. In each space~ the
total number of samples is the same~ that is, n 2 equals (L//:l.)2. To arrive at an average
number of bitsperpixel~ we evaluate the total number of useful bits and divide by the total
number of pixels. In frequency space~ we arrive at the total number of useful bits by

4

multiplying the number of bits per frequency sample (log2[ #LEVELS]) by the number of
samples per unit frequency interval (L2), times the frequency interval, and integrating over
the frequency range. These operations are combined and expressed as
#bits/pixel =1
n2

ff

{log2[ #LEVELS(p.,v)] }(L2)dp,dv

(4)

where p"v are spatial frequencies. Putting together the above relations between constants
and the fact that the visual performance data has approximate circular symmetry we can
rewrite the expression as
#bits/pixel =2TIA2 0 vMAX{log2[ #LEVELS(v)] }vdv
(5)

f

Finally, for any high enough sample rate, we can perform a numerical integral
approximating Eq. (5) which will give
#bits/pixel =2TIA 2(177.5)

(6)

If we now insert A as approximately 20 samples per millimeter we find that the average
visually useful information in an image is approximately 2.8 bits per pixel, substantially
below the 8 bits per pixel which we would have estimated had we not taken into account the
fall- off of visual performance with spatial frequency.
It is also of interest to note that if we decrease the sampling interval, that is sample more
often, the useful information per pixel drops with the square of the sampling interval. We
can therefore also calculate a sampling interval at which the average information per pixel
would be aapproximately 1 bit. Substitution in Eq. (6) yields 1 bit/pixel at a sample
interval of 33.4 per mm. This result states that, at that sampling interval, an efficient
binary code might be found which could represent the image at no loss of visual quality.
We therefore consider next simple binary image codes.

III. HALFTONE CODES
One simple form of binary image code has been used for somewhat over a century4 by the
graphic arts industry. The binary images are referred to as halftones, and are used to give
the appearance of grey while printing only full black and white. Such images are generated
by combining a non- image related pattern (called the halftone screen) with the pictorial
data by addition or multiplication. The combination is then subjected to a threshold to turn
the continuous tone to a binary image. This process has been applied to sampled imagery by
many authors (for example, see Ref. 5) and the image detail for given screen patterns has
been described..6

5

We now ignore the design of the halftone screen
to consider what optimal encoding might
achieve. The halftone process is essentially one SIGNAL
of trading off grey scale for texture. That is, a LEVELS
combination of black/white spots is generated
which, when averaged over some area, give the
illusion of various shades of grey.
Again
considering ideal sampling, we examine how a
+AI2
gi ven periodic structure can be represented.
Clearly, we must have available at least one
sample for every half wavelength of the pattern
to be represented. Fig. 3 shows a small region of
the picture with two regions identified, each a
half wavelength of the desired sample in length.
To represent the sample of minimum modulation
s....-achievable at this spatial frequency, one bit must
change between these two areas of image. This is
equivalent to asking how many different levels
can be represented by turning on different
numbers of bits within the image area whose
length is one- half wavelength for the desired Fig. 3. Image Areas A vailable to Encode
spatial frequency. This can easily be seen to be
A One Grey Level Change

~~
~AI2

11

# of LEVELS =(1/(2Fs»2(l/ A2)+t

-1

=_x--,--::----,1

(7)

where fs is the object frequency, and A the sample interval. It is convenient to immediately
generalize this result by asking what would happen if each pixel could take on more than
black or white values. If each pixel is described by m bits, rather than 1, each element now
adds 2m-l additional non-black values. Thus the same type of coding applied to a
multilevel image yields the possibility of representing additional grey levels, given by
# of LEVELS =«2 m -l)/(2fsA»2 +1.

Fig. 4 compares the original curve from
Fig. 1 with the number of levels
achievable as a function of spatial
fr.equency for the binary case with a
sample rate of 20 per millimeter and for
the case of 3 bits per pixel at the same
sample rate.

VISUAL LIMIT
BINARY IMAGE
3- BITS/PIXEL

100

\

# OF LEVELS
AVAILABLE

\

\
10

1

"
o

2

4

6

8

10

SPATIAL FREQUENCY

Fig. 4. Texture Code Limits

(8)

12

It is interesting to note that the 3 bit per
pixel curve indicates that a texture type
code should be able to represent almost
all information visible to the eye. Since
we found that the actual useful
infonnation averages approximately 2.8
bits per pixel at this sample interval, we
have an indication that the texture type
code could be reasonably efficient. In
the binary case, at this sample interval,
we see that the 1 bit per pixel code falls
short of that needed to avoid visible
degradation of the image. The manner
in which the curve falls with spatial
frequency, however, gives an indication
of why hal ftoned images look as good as
they do, since the curve shapes are
somewhat similar.

6

IV. CONCLUSION
We have described an approach in which visual data for modulation transfer function of the
eye can be utilized to determine the useful information in an image. At a sample interval
of 20 samples per millimeter, we have found that the visually useful infonnation
corresponds to approximately 2.8 bits per pixel. The shape of the visual performance curve
indicates that more levels need to be represented at lower spatial frequencies and less levels
at higher spatial frequencies. Thus, it has been shown that halftone or texture codes,
although simple, represent image information in a manner which tends to be compatible
with the characteristic of the visual system.

v.

ACKNOWLEDGEMENTS

The author wishes to express his gratitude to his co- workers for many useful discussions
which have helped to clarify the concepts described in this paper. In particular, D.
Kermisch and K. Knox provided many helpful suggestions.

REFERENCES
1Costigan, D. M., Fax, Chilton Book Co., Philadelphia, Pennsylvania 1971, p. 121.
2Cornsweet, T. N., Visual Perception, Academic Press, New York, New York 1971, p. 330- 342.
3D ooley, R.P., "Predicting Brightness Appearance at Edges Using Linear flnd Non- Linear Visual Describing
Functions", presented at SPSE Annual Meeting, May 14, 1975, Denver, Colorado.
.

4Pocket Pal, Tenth Edition, International Paper Compoany, New York, New York, 1970, p. 11.
5Klensch, R. J. "Electrically Generated Halftone Pictures," RCA Review p. 511- 533 (September 1970).
6Kermisch; D. and Roetling, P.G., "Fourier Spectrum of Halftone Images," Journ. Opt. Soc. Am. 65: p. 716-723
(1915).
-

Whole ALTO World Newsletter
Technology and Tools

XEROX

APRIL 30, 1978

SPECIAL ANNOUNCEMENTS
WHOLE ALTO WORLD MEETING - The next Whole Alto World meeting is scheduled to
be held from 9AM to 3:30PM on Thursday, June 1, 1978, at El Segundo in the Executive
Dining Room. Dick Sonderegger and SOD are hosting. The last page of the Newsletter is a
flyer announcing the meeting. Please detach your copy and post it on an appropriate bulletin
board. Start your trip to the National Computer Conference right by first attending the
Whole Alto World meeting.

GENERAL NOTES
EIA BOARD LOAN REQUEST - ASD needs the use of an EIA board for software
development until July 1. If you know of one that can be be spared for a time, contact John
McNeley at Intelnet 8*823-2011. It would be greatly appreciated.
THE ALTO USER'S PRIMER - A new document has been prepared for the new Alto user
(and the experienced user too) by Frank Ludolph, the Whole Alto World coordinator. It
presents, in a non-technical fashion, an overview of the Alto network, hardware and
operation, and provides pointers to the documentation. It is included in the Newsletter in
the TECHNOLOGY section.
ADDRESS LABEL FORM - Have you wondered about the label used to mail the Newsletter
to you? The mailing labels are maintained with Bravo using a form made up by Barbara
Baird. The form, complete with instructions, positions each address in just the right place
for the Xerox gummed labels, 3R311 (three across by eleven high). Retrieve
[MAXC] and . If they are not"
available, or if you are in doubt as to the version, they may be retrieved from [MAXC]
(same directories). Files stored under other directories are on [MAXC] unless otherwise
indicated, e.g. [XEOS].
NEW RELEASE: ShowAIS - Joe Maleson has provided us, via boot server, a program that
halftones and displays 8 bit/pixel AIS files from a remote file server. It is similar in
function to AISshow which expects the file to be on the local disk. The documentation from
[IVY]ShowAIS.bravo is attached to the Newsletter. Note: This program can
degrade the performance of the file server. If this seems to be happening, please delay use
until the need, "by others, of· this scare resource is reduced.

ReRelcases - Subsystems
CHAT - Only minor changes were made to this release. It is available from bootservers.
DRAW - The clandestine "Color-DRAW" is' now officially released as DRAW 4.0. Load
DRAW.dm. A documentation update is available on DRAW-new.press.
PRESSEDIT - Only minor changes were made. Retrieve PressEdit.run.
PUT - Version 1.1 has been enhanced to work on disks using the 'big disk' feature of the
new operating system. People with model 44 disks who use 'big disk' will need the new PUT.
Retrieve PUT. run.
READPRESS - The floating point spline description is now printed out in decimal floating
point rather than it octal representation. Retrieve ReadPrcss.run.
TRIEX - The latest version runs on Alto's successor machines and also has a few bug fixes.
Retrieve Triex.run.

5

Whole ALTO World Newsletter
ReReleases . Packages
MICROFLOAT.DM . Double precision floating load of the value zero now functions
properly. Load MicroFloat.dm.

TECHNOLOGY
This month, instead of the usual technology paper, we present a new, introductory level
paper for the new and not-sa-new Alto user. Most existing documentation tells a person
how to use a specific item. By contrast. this paper describes, in non-technical tenns, the
system's existing facilities, provides an overview of the documentation scheme, updates some
basic operational procedures and documents some procedures that are unrecorded elsewhere.
Of specific interest to current users are the documentation scheme overview in chapter 3 and
the machine check-out procedures in chapter 4 (which were serialized in these last two
editions of the Newsletter).
This document, along with a copy of local procedures. should enable the new user to get
started in a shorter time and with a minimum of fnlstration.

The Whole Alto World Newsletter is a montly publication for Xerox employees that use the Alto. It is not to
be shown to non-Xerox people. Copies are available on [MAXC1WAWnews.press or may be
obtained from the editor, Frank Ludolph, XEOS, by messaging  or calling Intelnet 8*923-4356.

6

ThiS

document

IS

tor

XcHUX

Internal use omy

THE ALTO USER'S PRIMER
BY FRANK LUDOLPH

APRIL 1978

XEROX WHOLE ALTO WORLD

This document is for XEROX internal use only

THE ALTO USER'S PRIMER

2

INTRODUCTION

I.

THE NETWORK
Alto
Ethernet
Transmitting data
Receiving data

Gateway
Servers
Printers
File Storage
Electronic Mail
Boot Files
Time
Device Name List

Network diagram
U. THE FILING SYSTEM
Alto Filing System/Filenames
File Servers
III. WHAT YOU NEED
Documents
Overview
Basic Document List

Subsystems
Accounts
Keeping Up-To-Date
IV. OPERATIONAL PROCEDURES
Operating the Alto
On/Off
Loading/Unloading a disk
Booting

Checking Out Your Machine
Workstation
Disk Drive
Alto Processor

Using the Executive
Starting a service
Correcting typing errors
Aborting a service

Initializing/Installing a New Disk
Copying
Using the network
Installing a new disk
Retrieving a basic set of files

Normal Disk Maintenance
Listing filenames
listing file attributes
Display a file's content
Deleting files
Grouping files

Disk Crash!
The User Command file
Printing
Press files
Bravo files
Ears files
Gypsy files
Text ·.files
TTY files
Other printers

THE ALTO USER'S PRIMER

3

INTRODUCTION

Most of the existing documentation for the Alto and its systems tell you how to use the Alto,
Bravo, FfP, etc. The purpose of this paper is to present what exists and where to get it. It
is intended as a first reading for the new user and is primarily non-technical in its
presentation. The first chapter, THE NETWORK, presents a brief overview of the system's
services, components, and their interconnection. The second describes the filing systems,
both Alto and IVY, and their interaction. The chapter, WHAT YOU NEED, presents an
overview of the documentation available, lists the minimal set of documents and subsystems
needed to get started and where to get them, and tells you how to keep up-to-date. Lastly,
there is a how to chapter comprised of operational procedures that either have been revised
or are unrecorded elsewhere.
Many of the sections reference documents for further study. While many of them should be
available from your local file server, the orginal source is indicated. [t is advised that these
papers not be read until reading of the Primer is completed and fully understood.
Many sites have established local procedures to cover establishing accounts and methods of
obtaining and initializing disks. Ask other machine users in your group or area to direct you
to the appropriate people. In case you find yourself all alone or no one seems able to help
you, call the Whole Alto World coordinator. Currently the coordinator is Frank Ludolph.
You can reach him at Intelnet number 8*923-4356 or sending by a message to , especially

PUP.ears.

THE GATEWAY

The Gateway's primary function is to transmit packets between Ethernets. It is a- small
computer (currently Novas but soon to include Altos) that attaches to an Ethernet in a
manner similar to any other computer except that it responds to all packets addressed to
other nets. Each off-net packet is picked up, encapsulated, and routed over the appropriate
lines to other Gateways. Transmission of data packets through Gateways is transparent to
the sending and receiving programs; packets, after passing through Gateways to the
destination Ethernet, are identical to the original packet;
More than one Gateway may be attached to an Ethernet and there may exist more than one
path between two Ethernets, that is, there may be loops forming a tnle network structure.
(Remember that it is the responsibility of the communicating programs to recognize and
discard duplicate packets.)

THE ALTO USER'S PRIMER

6

The Gateway also provides bootfile, time, and name look-up services. These functions are
described below.
See: [MAXC] for some papers on

Gateway protocols.

SERVERS

Servers provide services that can be provided more effectively in a centralized fashion. In
general these services require special hardware~ use intermediate facilities to provide aroundthe-clock access, extend local facilities (file storage), or provide backup.
PRINTERS A printing server consists of an Alto, a printer, and usually some additional disk
storage (a second Diablo 31 or a Trident T-80). Like all other Altos on the network it has
an address and usually a name (see the Ethernet Description above). To send a file to a
printer, the printer's name or address must be indicated. To save you the extra keystrokes of
entering the printer's name or address every time, a default printer can be specified in the
[HARDCOPY] section of the User.crri file. (See the PRINTING and USER COMMAND FILES
sections under OPERATIONAL PROCEDURES). Once the User.cm file has been modified,
you need to specify a printer's name or address only when you wish to use a different
printer.

The most common printers are Spruce printers (Spruce is the name of the software that runs
on the printer's Alto). They will print Press format files containing text and graphics, e.g.
line drawings, of limited complexity. (For directions on how to send a file to a Spruce
printer see PRINTING). The server listens to the Ethernet, waiting for a print request. When
a request is detected, the file to be printed is transferred as soon as possible to the printer's
disk (but not until the printer has finished printing the current file). These spooled files are
then converted, in the order received, to a format suitable for printing and printed.
Spruce is normally run on two types of printers: Dover and Sequoia. Dover is a high volume
printer, its output looking very much like a good clean xerographic copy. Sequoia has better
solid area development, that is, the blacks are blacker, but is intended for low volume (not
over 200 sheets at a time). Dovers are generally available 24 hours a day, Sequoias only
during normal working hours (due to limited component life). Your User.cm should
probably specify a Dover, if possible, as your default printer.
Press printers, i.e. printers running Press software, will print not only text and graphics of
unlimited complexity, they will also print images' such as halftoned photographs. Press is
rather more complex to use and generally does not run in server mode; you must personally
supervise the transfer of the print file and initiate printing (although a form of serY~r mode
can be setup when appropriate). Press can be run on any of the printer hardware but is
normally run only for experimental purposes on printers other than Dover and Sequoia.
(Images cannot be printed on Dover by .Press because of the Dover's high speed).

THE ALTO USER'S PRIMER

See:

[IVY] directory. Documents
are placed in the  directory. There are some exceptions which will be pointed
out below. A program, when retrieved onto the Alto disk is immediately usable, though some
first must be installed (normally performed by typing program name/i). Documents may be
viewed on the screen using Bravo if they have the extensions .bravo or .memo, using Markup
if the extension is .press, or with Type, an Executive routine, if in a .tty fi1e. If you want
printed documents, see the section on printing under OPERATIONAL PROCEDURES.

DOCUMENTS

One of the most difficult problems when learning to use a new system is finding the
existing documentation. A hierarchy of documentation has been created with this document
as the root. The overall documentation scheme is illustrated in the figure below.

ALTO USER'S
PRIMER

PREPRINTED
DOCUMENTS

I

~

LOCAL
FOLKLORE
DOCUMENTS

_

CATALOGS

~

ENGINEERING
DRAWINGS

W ~OLE ALTO WORL ~
NEWSLETTER

SUBSYSTEMS

I

I

HARDWARE

MANUALS
SUBSYSTEMS
AND
PACKAGES

HARDWARE
DOCUMENTS

~

I~IVIDUAL MANUAL S

Several commonly used documents have .been printed and bound. These include the Alto
User's Handbook, the Bravo Course Outline, and the MESA Language Manual. The
Handbook contains introductory material on how to get started on the Alto and manuals for
several commonly used subsystems: Bravo, DDS, Draw, FTP, and Markup. Though it was
written in late 1976 and is somewhat out of date, it is well done. It is certainly accurate
enough for the beginner; most of the changes have been in the form of enhancements or
additions.

THE ALTO USER'S PRIMER

13

The Bravo Course Outline is a comprehensive teaching and reference guide to using Bravo, a
widely used text editor. There is a companion workbook that contains practice material.
Both have been recently updated.

Local folklore covers a number of papers written to document local procedures and
supplement program manuals for several subsystems. Though intended primarily for use at
the site for which they were written, you will find them useful at other sites as well.
Folklore documents known to exist are:
ORGANIZATION
SOD
PARC
XEOS

FILE(S)
[IRIS]Packages.ears
(AltoDocs)Gypsy.press

If you wish to use MESA and are outside SOD, PO, ASD, or PARC, contact the coordinator.
Design Automation System users will need the SIL Manual on [IRIS](SIL)SilManua1.press.
It includes documentation on the other programs in the system.

SUBSYSTEMS

When a new disk is built, what subsystems should be put on it? That, of course, depends on
what it will be used for, but that normally breaks down into justa few categories: document ,
creation, BCPL or MESA programnling, or Design Automation. (Of course there are several
specialized functions but if you know about that, this Primer probably isn't necessary.)
Almost everyone needs a non-programmers disk (document creation), even if they intend to
program, so we'll start there. The disk should contain:
BASIC SYSTEM SUPPORT
EXECUTIVE
INSTALLSWAT run to put SWAT and SWATEE on the disk
USER.CM
contains user settable defaults for many subsystems
FILE MANAGEMENT

FTP

or

moves files between Altos and a file server
SCAVENGER restores a flaky disk (if space is tight, use the boot server)
simplifies disk maintenance
DDS
for disk maintenance, smaller than DDS but fewer functions
PUT

DOCUMENT CREATION
BRA VO
text editor
SIL
diagrams of vertical and horizontal lines with captions
and/or MARKUP
diagrams that include diagonal lines and mouse tracks
and/or DRAW
diagrams that include curves
PRESSEOIT
merges text and diagrams
EMPRESS
sends files to a printer (.press and .tty formats)
NPPR
converts .sil format files to .press for printing
FONTS (files containing characters of different
TIMESROMAN*.AL
several sizes of
HELVETICA *.AL
several sizes of
MATHIO.AL
math and logic
LOG024.AL

letters

styles)
characters with serifs (like these)
characters without serifs (like these)
symbols for BRAVO

X,E,R

and

0

THE ALTO USER'S PRIMER

HIPPOIO.AL
GATES32.AL

15

Greek alphabet e.g. a{J~fJ6.Tp. ...
arrows and things for use with SIL

This is a minimum set but it will get you started. Most of these files can be obtained easily
by retrieving and executing the NPDISK command file. See the disk initialization procedure
in the OPERATIONAL PROCEDUAESchapter.
Other command files exist to simplify the retrieval of other file groups. These are the most
commonly used; the list is by no means comprehensive.
BRAVO.CM
MESADISK.CM
PDISK.CM
SIL.CM

adds Bravo 7 (automatically retrieved by NPDISK.CM)
makes an initialized disk into a MESA programmer's disk
makes an initialized disk into a BCPL programmer's disk
adds Design Automation programs to an initialized disk

ACCOUNTS

[f your machine is a part of the network you will probably need to obtain IVY and message
accounts. IVY is a file storage facility (server) usually located at sites having ten or more
Altos. (IVY's old name is IFS.) Stored on IVY are documents, files, and subsystems
(computer programs or services) that you will need later on. Contact the local IVY
administrator. [n case you can't get an account right now, most IVY servers have a guest
account, GUEST, password: Guest, that can be used to retrieve files. This is especially useful
when retrieving files from other than the local IVY server.
If you are at PARC, you may need access to MAXC, a large computer that is part of the
network. [n general, MAXC accounts will not be issued to non-PARC people.
The question of message accounts is somewhat up in the air at the moment due to the
changeover to Laurel. Once Laurel is in general use. local administrators will handle the
assignment of accounts. Until then, message users must have access to a MAXC account.
PARC, SDD, and ASD people are regularly assigned accounts. Group accounts are issued so
that other individuals may also use the message facilities.

KEEPING U P~ TO-OATE

The Alto exists in a rapidly changing environment. It requires some effort on your part to
keep up-to-date, but you do have help. Some of the software developers use the message
system to announce new or rereleased subsystems and p~ckages, usually with updated
documentation. The Whole Alto World Newsletter gathers these announcements together,
along with unannounced changes, on· a monthly basis. (It also includes docurrientation on
newly released software, information about the hardware, notes on system operation, and
papers on technologies affecting or affected by the Alto. If you would like to receive the
Newsletter, contact the coordinator as indicated in the INTRODUCT10N.)

THE ALTO USER'S PRIMER

Once you know of revised documentation, retrieve and print it. Using the Subsystems and
Packages Manuals as a base, replace the updated sections with the documents just printed.
Many of the documents contain a revision history as the last section. Review the changes
indicated there and in the Newsletter and you will find that you can remain up-to-date with
just a couple of hours effort each month.

16

THE ALTO USER'S PRIMER

. 17

IV. OPERATIONAL PROCEDURES

OPERATING THE ALTO

The Alto itself is a very simple machine for people to operate. There are only three things
you need to know: loading a disk, booting, and turning it on and off. (Of course there are
additional procedures for controlling each of the subsystems.)
ON/OFF The Alto was designed and is intended to be leji. on at all times. When the
machine is off, all lights are dark. Look for a red POWER light on the front of the machine.
Older Altos (Alto l) generally have the power switch on the back of the display base; reach
around to the right. On newer Altos (Alto II) the power switch is inside the processor
cabinet (the big box on the floor). Using your thumbs, push in on the bnlshed alumninum
plates (left and right front) and pull out a couple of inches. The switch is inside the top, left
corner. Don't turn the machine off unless local procedures tell you to. When turning ON or
OFF always verify the the disk is off, i.e. the RUN/LOAD switch is in the LOAD position and the
yellow READY light (right, front) is out and the white LOAD light is on.

The Diablo Model 31 disk drive used with the Alto has a
protection mechanism that prevents the disk access door from being opened when the disk is
spinning or when the power is off. If you look carefully through the smoked plastic panel,
you can see a little flag that says LOCK just to the left of the disk pack hand hold when the
disk is on (spinning). Don't try to open the access door when this j1ag is up, something may
break if forced.

. LOADING/UNLOADING A OISK

To load the disk, verify that the Alto is on, the LOAD/RUN switch (front, top, left) is in the
LOAD position, and the white LOAD light is on. Open the access door by pulling out and down
on the handle (cross bar at the top, front), and gently slide the disk in while holding the
pack by the hand grip. Close the access door and push the LOAD/RUN switch to RUN.' The
white LOAD light will go out and, after about a minute, the yellow READY light will come on.
The disk is now loaded.
To unload a disk, push the LOAD/RUN switch to LOAD, wait about about a minute for the
white LOAD light to come on, open the access door, and slide the disk out. Some of the doors
get sticky, so if it doesn't open easily, verify that the LOAD light is on and try again. (If you
want to make really sure that it isn't locked, look for the flag through the smoked panel; it
should be down.)
BOOTI NG The purpose of booting is tf) 10ad into the Alto a copy of a program from an
outside source. Normally, the Alto is booted from the disk (diskboot), so the first step is to
load an initialized disk. [f you have one, ready it. To boot using a disk, depress the boot
button located on the back of the keyboard about an inch to the right of the thick, black
cable. You should hear the disk rattle and a few seconds later, some text should appear at
the top of the screen and a ")" about halfway down the left side. The boot operation is
complete. The ")" is the prompt from the Executive; it is requesting you to type in a
command. See the section below on USING THE EXECUTIVE.

THE ALTO USER'S PRIMER

If you don't have a disk, try to perform an ethernetboot. Depress and hold down the QUOTE
and BACKSPACE keys on the keyboard, push and release the boot button while continuing to
hold the' other two keys until a small square with holes in it appears on the screen (several
seconds). The keys can be released now. Some seconds after the square appears, it will
disappear, some text will be displayed accross the top of the screen, and ")" about halfway
down the left side. The ")" is the prompt from the NetExecutive. This is not the same thing
as booting off your own disk, only a few programs can be run this way. (Type "?" to list
them). One of the things you may be able to do though is initialize a own disk over the
network.
If the small square fails to appear, a boot server is not available: you will have to locate and
ready .an initialized disk to boot from.

CHECKING OUT YOUR MACHINE

There are several diagnostic programs that you can run to verify that the various pieces of
your Alto ·are operating properly: DMT, CRTTEST, KEYTEST, and MADTEST. If the Alto
is connected to the network, each can be obtained from a boot server, such as a Gateway. To
execute any of them, boot over the Ethernet (boot while depressing the BS and quote keys)
or type the netexec CR command to the Executive. At this point the NetExec will appear on
the screen. Type the name of the diagnostic to be performed and you're off and running.
(Enter a '?' to list the boot files that can be called by the NetExec; the diagnostics listed
above should appear. Do not use DISKTEST. It's intended only for maintainers and could
wipe out a readied disk. Commonly used subsystems are also available.) If the tests indicate
something is amiss, contact your local maintenance group.

THE WORKSTATION consists of the display, keyboard, keyset, and mouse. The action of the

keys and mouse movement are tested by KEYTEST, the adjustment of the display by
CRTIEST.
CRTIEST aids you in making a subjective judgement about the quality of the display's
focus and linearity by drawing parallel vertical and horizontal lines. The thing to look at is
the sharpness of the lines, especially near the edges of the display, and the shape of the
boxes formed by the intersection of the lines. The boxes should be square, not tall or wide
or diamond-shaped (romboid). There will be a little distortion at the corners so don't worry
about that. The lines will be redrawn with a different spacing (three in all) when the space
bar is depressed (or any other key for that matter). When finished either boot to get to the
Executive or type SHIFT-SWAT to retun to DMT.
KEYTEST will verify that each key makes positive contact, generating only one character.
When the program starts, the keyboard, keyset, and mouse are drawn on the screen (the
mouse may be hidden in the upper left hand corner). The display should picture the correct
keyboard, either Alto I or Alto II. To flip to the other keyboard picture, move the cursor to
the bottom of the screen (it should change to an arrow) and click any mouse button. Depress
,each key, one at a time; the corresponding key on the display should turn black. If it stays
white, flickers, or more than one key turns black, there is a problem. When finished either

18

THE ALTO USER'S PRIMER

boot to get to the Executive or type

19

SHIFT-SWAT

to retun to DMT.

THE DISK DRIVE There are no user diagnostics for the disk drive. Problems may be indicated
by the need to run SCAVENGER on your disk more often than, say, once a month, though
this may also indicate a bad disk. (The CopyOisk verify command, v
_ erify DPO against
DPOCR, can be used to scan a disk for errors.) Regular preventative maintenance every three
to six months. should be sufficient to maintain proper head alignment and write current
levels. Do not run DIS KTEST on a machine with a regular work disk readied.: it may be
destroyed by being overwritten.

THE ALTO PROCESSOR can be roughly broken into several functional pieces: main memory,
microprocessor memories (RAM and PROM), arithmetic-logic unit (ALU), registers, and
data paths. [t isn't necessary for you to know each of these or what they do, only that there
are two diagnostics, DMT and MADTEST, which test the operation of most of the
processor.
DMT tests the main memory, the area occupied by your data and most, if not all, of the
subsystems that you run. When DMT is executed, the display will be black except for a small
white square that bounces randomly about the screen.
DMT should be run for long periods, say overnight or over the, weekend. If the Alto is left
in the Executive, DMT will be called after 20 minutes. In the morning, when you come in
and load the disk, while waiting for it to spin up to speed, depress and hold the's' key. A
three line message will be displayed a few inches from the bottom of the screen. The second
and third lines should begin "0 Errors ... ". If some errors have been found, the memory chip
location(s) will be indicated. Don '{ boot your Alto: the machine may not work and the
location information will be destroyed. Inform the local maintenance group.
MADTEST, the Microcode Alto Diagnostic Test, exercises much of the rest of the processor.
It is actually a collection of routines that test the RAM, PROM, ALU, registers, and data
paths.
It is run in the same manner as KEYTEST and CRTTEST, namely, execute NetExec by
booting from the Ethernet or typing netexec CR to the Executive, and then type madtestCR .
The screen will indicate at the top the test routine being run, the number of passes
completed, and the errors detected (if any). The middle of the screen will contain trash (the
unformated contents of memory) and below that a band containing the phrase "Black on
white means DO TEST". lmmediatly below the band are the various tests that will be run.
The cursor consists of the usual arrow (like Bravo) with a changing series of black and
white horizontal lines through it. The number and location of the lines change to let you
know that ~0mething is happening because it isn't always apparent from the rest of the
screen. The cursor also moves about the screen in its usual fashion except that sometimes it
jumps (after a few seconds delay) rather than moving smoothly as is customary. You may
also notice the screen "tearing". Both of these effects are a result of the level at which the
diagnostics operate.

THE ALTO USER'S PRIMER

20

MADTEST will automatically run all the tests, over and over. The number of passes
completed is displayed near the top of the screen; allow MADTEST to run several passes. If
any errors are reported (they will be displayed about one-third the way down the screen),
write them down and pass them along to the maintenance people. Note: depressing the
SPACE bar will halt the program and clear the screen. To suspend execution without
clearing the screen, move the cursor into the area of the test list. Moving it out will reSUlne
execution. After the test has run several passes, either boot to get to the Executive or type
'SHIFT·SWAT for DMT.
To prevent any of the
bug the test not to be
it to be executed, bug
start of a pass will

tests from being run, move the cursor into the area of the test list and
run. [t should change to white letters on a black background. To cause
it again. Any tests shown in black letters on a white background at the
be executed. The default is to execute all tests.

USING THE EXECUTIVE

This is the service that runs after a disk boot. It is used primarily for starting up other
services, such as CopyDisk which can be used to initialize a disk.
STARTING A SERVICE

To start a service, type its name followed by a

RETURN (CR).

For

example
>copydiskCR

(If you did this, you will want to abort it. See ABORTING A SERVICE below.) Some services
require additional information, say the name of a document on the disk. To display a
document, "Notes", on the screen, use the service Type. Enter
)type notesCR

It doesn't matter if words are typed in capital letters, lower case, ora mixture of the two.
When typing a filename, it isn't necessary to enter the entire filename, only enough
characters to unambiguously identify it. While entering a filename, if the ESC key is hit, the
Executive will" finish the name if it can. If the screen flashes black, there are two or more
files that begin with the characters typed so far. Enter a few more characters (you needn't
start over) and hit ESC again.
CORRECTING TYPING ERRORS Typing mistakes can be corrected using some special keys.
To erase the last character typed use the BS (backspace) key. rL'O erase the last word, type "w"
while holding down the CTRL (control) key. Both the BS and wC keys can be used to erase as
many times as necessary. To erase the whole line and start over, type DEL (delete): it prints
"XXX" and starts a fresh line.
ABORTING A SERVICE Usually a service can be suspended by swatting. To swat, depress the

key while holding down the left SHIFT key. The location of the SWAT key depends on
which style of keyboard you have. On the Alto II keyboard there is a vertical column of tlve
keys to the right of the standard keys; the SWAT key is the top key on the right column. On

SWAT

THE ALTO USER'S PRIMER

the Alto I, the

SWAT

21

key is the blank key in the lower right corner. In both cases it is blank.

After swatting, the service SWAT takes over. To get back to the Executive type kC (depress
the "k" key while holding down the CTRL key); to resume the service that was running, type
pC (this doesn't work with some services).

INITIALIZING/INITIALIZING A NEW DISK

There are several ways to initialize a new disk, some better than others for reasons that will
be explained. Usually local procedures will describe the best method for obtaining and
building new disks at that site. One method, using the network facilities (ethernet and file
server) requires that your machine be a part of the network and that you have access to a
file server (IVY or MAXC). An alternate method, copying an existing disk, requires an
initialized disk and either an Alto with two disk drives or two Altos connected by an
ethernet.
In general, initializing a disk over the ethernet is preferred. Unless the source disk used for
copying has been specifically built for that purpose (and not used otherwise) the new disk
will contain an unknown assortment of programs and fragmented freespace.
You've located an initialized disk and a dual drive Alto.
Load the initialized disk into the lower drive (called OPO) and the new disk into the upper
drive (DPl). After both are ready, boot the machine (ethernetboot preferred) and perform
the following dialog.
COPYING - DUAL DRIVE ALTO

>copydiskCR
(The screen will change appearance)
NOTE:
CopyDisks elsewhere on the net can't write on
your disks. Type "WRITEPROTECT" to allow it.
*writeprotect off
*QQQ~Jrom dpOCR
(Zero, not Oh)
Copy to dp1 CR
Copying onto dpO will destroy its old contents.
Are you sure this is what you want to do? [Confirm] y
es
Are you still sure? [Confirm] y _es

The machine will now copy the lower disk, DPO, to the upper disk, DP!, verify that the two
disks are identical and then ask for another command. Type

After installing (see INSTALLING A DISK), the new disk can be used to boot the Alto and to
store programs and data.
COPYING .. TWO ALTOS You've located an initialized disk and two Altos on the same
ethernet. Etherboot each machine. If this is successful, load each machine with a disk.

THE ALTO USER'S PRIMER

22

If the Altos won't boot without a disk, load the initialized disk into one of the Altos, boot it
(boot button only), and type copydiskCR . Without disturbing the keyboard, unload the that
disk and load the new disk. Now take the good disk to the other Alto, load the disk, boot,
and type copydiskCR .
Both machines should now be running the copydiskprogram and their screens should look
the same. At the Alto containing the new disk, perform the following dialog.
NOTE:

CopyDisks elsewhere on the net can't write on
your disks. Type "\/VRITEPROTECT" to allow it.

*writeprotect off
*fQQLfrom [nnn # ]dpOCR .

(where nnn is the number of the Alto with the
good disk. Look in the black band.)

copy to dpOCR
Copying onto dpO will destroy its old contents.
Are you sure this is what you want to do? [Confirm] y

es

Are you still sure? [Confirm] y _es

The machines will now copy the initialized disk (0 the new disk, verify that they are the
same, and ask for another command. Type quitCR at both machines. The new disk should
now be installed (see INSTALLING A DISK) and then can be used to store. programs and data
files such as documents.
You will need a new disk, an Alto connected to a network with a
file server (IVY or MAXC), and access (an account) to the server. Again, local procedures
should be consulted if available.
USING THE NETWORK

Load the new disk, perform an ethcrboot, type operating-system CR , and answer the
questions as indicated.
Do you want to install this operating system? y _es
Do you want the long installation dialog? y _ es
Do you want to ERASE this disk before installing? y es
Type the name of a host from which I can get Alto programs: name of file serverCR
Type the name of the directory where Alto Programs are kept: Alto CR
(Usually)
If you wish to change disks, please do so now. When the disk is ready
type OK to proceed, A to abort: OKCR
The disk is configured with the multiple-version feature enabled.
Do you want to change this setting? n_o
Do you want to change the error logging address (currently x # yyy # zz #)? n 0
. Do you want to disable parity error detection? n _0
Do you want t.o disable phantom parity reporting? n_o
What is your name? Ludolph CR
(Generally identical to your IVY IMAXC account)
Please give your disk a name? Whole Alto Worid CR
Do you wish to give the disk a password y _es or Q.o
What is the password? asdfgh CR
(Generally identical to your IVY IMAXC account)

THE ALTO USER'S PRIMER

23

The system will now boot itself and call the rL'P service. This service retrieves files from
file servers, in this case the one you named in the preceeding dialog. You will need a valid
account on that server. The Executive and FTP programs will be retrieved inorder to assure
your having the latest versions on your disk. Disk. installation is a part of this procedure, so
it won't have to be done again. The disk is pretty empty so you will want perform the
operations under RETRIEVING A BASIC SET OF FILES below.

INSTALLING A DISK Disk installation (short dialog) is used to identify the owner of a disk,
to give the disk a name, and to optionally require a password each time the disk is booted.
To install a disk, load it, boot the Alto, and type INSTALLCR. The system will then start a
dialog with you.

Do you want the long installation dialog? n _ a
(Generally identical to your IVY IMAXC account)
What is your name: Ludolph CR
Please give your disk a name: Whole Alto World cR
Do you wish to give the disk a password? y _es or flO
What is the password: asdfgh CR
(Generally identical to your IVY IMAXC account)
The system will now boot itself, request the password if specified, display the owner's and
disk's names at the top of the screen, and prompt for a command.
RETRIEVING A BASIC SET OF FILES Now that you have a very basic disk you will want to
assure that it contains the subsystems required for its intended use. If it was created using
DiskCopy, it probably has what you need. Typing a TAB will list the files that are on the
disk. Check the list in WHAT YOU NEED against the names displayed on the screen. If most
of the files aren't there or if the disk was initialized over the Ethernet, you will probably
want to use FTP to retrieve and execute a command file which will, inturn, retrieve the files
you need. To do this type the following line to the Executive where "file server" is the name
of the file server you have access to:

)FTP file server RET IC (AL TO)command file CR
)@command file@CR

(Retrieves the command file)
(Executes the command file)

where "command file" is NEWNPDISK.CM if the disk is for document creation or
NEWPDISK.CM if it is for BCPL programming.
The FTP program will open a connection to the file server and retrieve the command file.
That file contains commands that in turn will use FTP to retrieve a number of files. When
everything finally comes to a stop you will probably be left in Bravo. Type a qCR to quit
and return to the Executive. Your disk is now ready to do some work.

NORMAL DISK MAINTENANCE

The Executive provides routines to list filenames, list a file's attributes (e.g. type, size, and
creation date), display a file's contents, delete a file or files, and group files together as a
single file for storage or shipment (and the inverse operation). Two programs, Put and DDS,

THE ALTO USER'S PRIMER

24

can be used to simplify file deletion. Copying files between drives on a dual disk Alto can
be performed by Put and Copydisk. The copying of files to and from the Alto disk is done
using FTP.
LISTING FILENAMES To find out if a particular file is on the Alto disk, type the name of
the file followed by a TAB. All the files whose names begin with the typed-in characters
will be displayed on the screen. If, while entering a command to the Executive, you get part
way through the filename but don't remember how it ends, type a"?". All the filenames
beginning with the characters typed so far will be listed on the screen. Find the name you
need and finish typing the name.

If you name your files in a .systematic way, groups of filenames can be listed by substituting
pattern characters for parts of the name, followed by a TAB. The two pattern characters are
"#" and "*". Any single character can replace a "#"; any string of characters can replace a
"*". For example "*.memo" represents any filename ending in ".memo" while "# .memo"
represents only the files that have three character main names followed by the extension
".memo", such as "ABC.memo". Any. combination of pattern and filename characters is
valid.
lISTIN!l FILE ATTRIBUTES Enter the Executive command, File filename, to list a files size,
type, creation and write dates, and serial number and disk address.
DISPLA Y A FILE'S CONTENTS Enter the Executive command, Type filename. A portion of
the file will be displayed, followed by the word MORE? Type n to terminate, SPACE to

procede.
DELETING FILES To delete a file, type delete filename 1 filename2 ... CR. Pattern characters

can be used in the filenames, but be careful because once deleted, you can't get a file back.
If there is more than one version, only the oldest version (the one with the lowest number)
is deleted.
GROU PING FILES Many related files may be grouped as a single unit for storage using the
Executive command, Dump dumpfilename filename filename ... The dump filename usually
has a .dm extension regardless of content. To recover the individual files, enter Load
dumpfilename.

Additional details on the preceeding operations is contained in the Executive section of the
Subsystems Manual. For information on the capabilities and use of the other programs
mentioned in the first paragraph, see their respective subsections in the Subsystems Manual
(except for Put, which has self-contained documentation).

DISK CRASH!

There are various ways the Alto disk can be damaged. The most typical symptom is the
failure to boot properly. Using Scavanger and various techniques, it is almost always possible
to recover a disk or, at the minimum, the irreplacable files on it. Since a fair amount has
already been written, it won't be repeated here. The discussions can be found in:

THE ALTO USER'S PRIMER

Alto User's Handbook
OS. press
Subsystems.press

. 25

pp. 8-9
pp. 30-33
Scavenger section

All of this discussion has been brought together, along with additional comment on [IFS2]SDDocs>Scavenger.bravo.

THE USER COMMAND FILE

This file contains user-settable default infonnation for many of the system's services. It
should be on the disk now, but if not try retrieving New-User.cm from the  directory
on your local file server and rename it (rename oldname newname). Some of the settings
may have to be altered before placing the disk in general use. Of specific interest are the
[HARDCOPY] and [EXECUTIVE] entries. To see what they contain, enter the command
type user.cm CR to the Executive. This will display on the screen some of the text in the file
User.cm. When you have finished looking at what is on the screen, touch the SPACE bar
(actually, any key except "n" will do). When the whole file has been displayed, Type will
return to the Exective. If you want to abort Type, enter "n" when it asks "More?".
Look at the [EXECUTIVE] entry; it's usually the first one. You should see something like
the following. Ordering isn't particularly important.
[EXECUTIVE]
eventBooted: I I eventBooted
eventRFC: FTPII eventRFC
eventInstall: I I eventInstall
EventAboutToDie: I I eventAboutToDie
eventUnknown: I I eventUnknown
eventClockWrong: Settime I I eventClockWrong
In this case, the words on the left are things (events) that happen that the Executive knows
about. If one of these events occur, the Executive will call the service listed following the
":". For example, if the Executive notices that the time value it has doesn't look like a valid
time value, it will call the service Settime which will attempt to get the time from another
source on the network or, failing that, ask you for the correct date and time. The "I I" is the
start of a comment that is displayed on the screen when that event occurs. Nlany people
change "eventBooted" to say "Hi (your name)", then, every time the disk is booted, the screen
displays a greeting.
If you have a message account you may wish to call MailCheck when you boot, like so:
eventBooted: Mailcheckl I Hi Frank
To change the User.cm you will want to use Bravo vr one of the other text editors.' Because
they take a little experience to learn, altering the User.cm won't be described here. You
should look at the chapter, WHAT YOU NEED, to see about getting a text editor and its
documen tation.

THE ALTO USER'S PRIMER

The other entry you should look at is [HARDCOPY]. This one might actually have to be
changed so make a note to do it later when you learn how. This entry defaults where
documents on your disk are sent for printing. This assumes that your machine is part of a
network that has an attached printer. If so you will need to learn its name before making
the change. The entry looks like this:
[HARDCOPY]
PREFERREDFORMAT: Press
EARS:
PRESS: . Menlo
PRINTEDBY: "your name"
There· are two fannats used to encode documents for printing, Press and Ears. The one you
indicate as preferred should be the one you intend to use most often. Since there is only one
Ears printer and it is located in Palo Alto, you probably want to specify "Press". The
"EARS" and "PRESS" entries identify the default printers you would like your documents to
go to. Even if you_specify "Press" as your preferred fonnat, if you are in Palo Alto you may
want to use the Ears printer from time to time so that entry should read
EARS: Palo
If you're not in Palo Alto, you needn't bother. You will want to specify the name of your
local press printer, usually either a Dover or Sequoia. If you know what ethernet your on,
look at the Alto Network diagram for the name.
As an alternative to specifying the printer's name, you may wish to specify its address in the
fonn nn#mmm#. nn is the ethernet's address; mmm is the address of the Alto that drives
the printer. The reason for doing this is to cover the infrequent occasion when the name
server, usually a gateway, is down. These numbers can also be found on the Alto Network
diagram. Don't forget to reinstall Bravo (Bravo/i) after editing this section.
There are also entries for other services; Bravo, DDS, Chat, SIL, and Draw are commonly
used. See the documentation on each of these for descriptions of their entries.

PRINTING

Almost all documents are stored in electronic fonn on file servers. As a result, you will have
to retrieve and print the documents you need. Printers that nln Spruce and Press (Spruce is
run on Dover and Sequoia) software require that files sent to them for printing be in press
fonnat. However, several other fonnats (bravo, gypsy, tty, text, and some -ears) can be
converted and printed as described below.
You should first assure that the [HARDCOPY] section of the User.cm file is in the proper
fonnat, that is, it should reference a nearby printer. While each of the printing services
provides overide facilities, it is easier and less error prone if you start with a HARDCOPY
specification. See the USER COMMAND FILE section for a full explaination.

26

THE ALTO USER'S PRIMER

PRESS FILES Empress will send a press file to the press printer indicated in the
HARDWARE section of your User.cm file; just type Empress filename. The number of

copies can be specified as well as a different printer. See the· Empress section of the
Subsystems manual for a complete description.
BRAVO FILES Bravo has a Hardcopy command that will properly format and transmit the
current work file to the printer specified in the [HARDCOPY] section of the User.cm file.
Options are available to specify a different printer (@printer name ESC) and multiple copies
(cnumber of copies ESC). An option also exists to create a press file without printing.
EARS FILES Some ears files, which are normally printed only on the ears printer at PARe,

can be converted to press format for printing on. a local printer. The ears file must contain a
defined font set and may not contain diagrams. The only way to discover this is to try to
convert it by calling Pressedit, Pressedit Name.press +- Name.ears. [f sucessful, this will
create a press format file on the Alto disk which may be treated as any other· press file. See
the Pressedit section in the Subsystems Catalog for more detail.
GYPSY FILES Gypsy, like Bravo, will format its workfile into press format and transmit it

to the printer specified in the User.cm file.
TEXT FI LES The various text editors, e.g. Bravo, Gypsy, and UGH, maintain their source as a

text file. Empress will automatically recognize and convert text files to press format before
transmitting them to the printer. However, this is not commonly done. Empress does not
attempt to use the formatting information in these tiles; it is simply stripped off. The Bravo
and Gypsy editors both contain facilities to properly format th~ir work files in press format
and transmit them to the printer.
TTY FILES Empress will automatically recognize and convert .tty files to press format before
transmitting them to the printer: just type Empress filename. The same options that apply

to press files apply to tty files. See the Empress section of the Subsystems manual for a
complete description.
OTHER PRINTERS Dovers and Sequoias are not the only printers, though they are the most
common. Other printers include the Versatec electrostatic printer, the Diablo HyType, and
the Slot 3100. The Versatec and Slot 3100 normally run press software which will print press
files as described above. If !bey have been set up as servers, Empress can be used to transmit
the files to the printer, otherwise the file to be printed will have to be transferred between
machines using FTP.

The HyType was the original hardcopy printer used with the Alto and is available as an
option. Both Bravo and Gypsy will output their workfiles to this typewritter like device; for
Bravo, use the Hardcopy command with the D option. Though the output is right justified, it
is printed in a single font.

27

ShowAIS Documentation
April 4, 1978
ShowAIS is a program for display 8 bit per sample AIS files on the Alto display. Two
versions are available: [IVY] -- Remove (or Restore) the six line text display from the screen.
o -- Display on or off: the speed of printing a picture is approximately doubled
when the display is turned off (the area painted so far is indicated by a black
rectangle of increasing size).
Q (Quit) -- In the network version, a new AIS file name is requested (hitting
carriage return will terminate the program). In the disk version, Q immediately
terminates the program.
In addition to the manual commands for setting the window, a window may be specified
interactively using the mouse. After typing the appropriate command, point to one corner
of the desired rectangle; hold down any mouse button as you move the mouse to the
opposite corner of the desired rectangle. A flashing area will indicate the window being
selected. Releasing the mouse button causes the new window to be displayed. The
commands are:
U (Update zoom) -- display the indicated rectangle, and update the current
window parameters (XS,YS,XL,YL) to be the rectangle coordinates.
Z (Zoom) -- display the indicated rectangle, but leave the current settings active.
(After a zoom, the previously displayed image can be restored by typing P).

laltoiimem.sil

AL Tall MEMORY LAYOUT
20000·37777

0·17777

40000·57777

60000-77777

100000117777

120000·
137777

140000·
157777

160000176777

BIT

EVEN

ODD

EVEN

000

EVEN

ODD

EVEN

ODD

EVEN

ODD

EVEN

ODD

EVEN

ODD

EVEN

ODD

0

1·16

1-18

1·26

1-28

1·36

1·38

1-46

1·48

1·56

1-58

1·66

1·68

1-76

1-78

1·86

1-88

1

2-16

2-18

2·26

2·28

2·36

2·38

2-46

2-48

2·56

2-58

.2·66

2-68

2·76

2-78

2-86

2-88

2

3·16

3-18

3·26

3-28

3·36

3·38

3·46

3·48

3-56

3-58

3·66

3-68

3-76

3·78

3-86

3·88

3

4·16

4·18

4·26

4-28

4·36

4·38

4-46

4·48

4-56

4·58

4·66

4-68

4·76

4-78

4-86

4-88

4

1·11

1-13

1·21

1·23

1-31

1·33

1-41

1-43

1-51

1·53

1·61

1·63

1·71

1·73

1·81

1-83

5

2·11

2-13

2·21

2·23

2-31

2-33

2·41

2·43

2-51

2-53

2-61

2-63

2·71

2-73

2·81

2·83

6

3·11

3-13

3·21

3·23

3-31

3-33

3·41

3-43

3·51

3-53

3·61

3-63

3·71

3-73

3·81

3-83

7

4·11

4·13

4·21

4·23

4-31

4·33

4·41

4-43

4·51

4·53

4·61

4·63

4·71

4·73

4·81

4·83

8

1·17

1·19

1·27

1·29

1·37

1·39

1·47

1·49

1·57

1·59

1·67

1·69

1·77

1·79

'·87

1·89

9

2·17

2'19

2·27

2·29

2-37

2·39

2·47

2·49

2·57

2-59

2·67

2·69

2·77

2·79

2·87

2·89

10

3·-17

3·19

3·27

3·29

3-37

3·39

3-47

3·49

3-57

3-59

3·67

3-69

3-77

3-79

3-87

3·89

11

4·17

4·19

4-27

4·29

4·37

4·39

4·47

4·49

4·57

4·59

4·67

4-69

4-77

4·79

4-87

4·89

12

1·12

1-14

1-22

1-24

1·32

1·34

1·42

1·44

1·52

1-54

1·62

1·64

1·72

1-74

1·82

1·84

2·24

2-32

2·34

2·42

2·44

2-52

2-54

2-62

2-64

2-72

2-74

2-82

2-84

3·24

3·32

3-34

3-42

3·44

3·52

3-54

3·62

3-64

3·72

3·74

3-82

3-84

4·42

4-44

4·52

4·54

4·62

4·64

4·72

4-74

4-82

4-84

13

2·12

2·14

2-22

14

3-12

3-14

3-22

15

4-12

4-14

4-22

4·24

4-32

4·34

HO

1·20

1-30

1·40

1-50

1·60

1-70

1·80

1·90

Hl

2·20

2·30

2·40

2·50

2·60

2·70

2·80

2·90

H2

3·20

3·30

3·40

3·50

3·60

3·70

3-80

3-90

H3

4·20

4·30

4·40

4·50

4·60

4·70

4·80

4·90

H4

1·15

1·25

1-35

1·45

1·55

1·65

1·75

1·85

H5

2·15

2·25

2·35

2·45

2·55

2·65

2-75

2·85

p

3·15

3-25

3·35

3·45

3·55

3-65

3·75

3·85

NOTE:

1. Card-Chip location.
2. The Memory Configuration Switch complements the high-order memory address bit

SSL ALTO II
EXTENDED MEMORY LAYOUT

a

BANK

BIT

0000077777

EVEN
0

1·16

100000177777

ODD EVEN

0000077777

1· 8

1-46

1-48

-56

1- B

1-66

1-68

-76

1- 8

1-86

1-88

2· 8

2-46

2·48

-56

2· B 2·66

2·68

·76

2· 8

2·86

2·88

3·28

3·36

38

3· 6

3·48

3·56

-58

3- 6

3-68

3·76

·78

3· 6

3·88

4· 6

4·28

4·36

38

4- 6

4·48

4·56

·58

4- 6

4·68

4·76

·78

4- 6

4·88

·13

1· 1

1·23

1-31

33

1- 1

1-43

1·51

-53

1- ~

1-63

1·71

·73

1- 1

1-83

·13

2· 1

2·23

2·31

33

2· 1

2-43

2·51

·53

2· 1

2·63

2·71

·73

2- 1

2·83

-53

3- ~

·73

3- 1

3·83

2·26

3·16

·18

3· 6

3
4

4·16

·18

1·11

5

2·11

3· 1

·13
4·13

1·28

3·23

·21

4· 3

3·31
4·31

33

3- 1

4·33

·41

8

1·17

·19

1· 7

1·29

1·37

39

1- 7

9

2·17

-19

2· 7

2·29

2·37

-39

2- 7

10
11

3·17

·19

3· 7

3·29

3·37

39

3- 7

4·17

·19

4· 7

4-29

4-37

39

12

1-12

-14

1- 2

1-24

1-32

13

2·12

·14

2- 2

2-24

14

3·12

·14

3· 2

15

4-12

·14

4· 2

BANK

100000177777

ODD EVEN ODD EVEN ODD EVEN ODD EVEN ODD EVEN ODD

36

2

4·11

1 OOOOO~
177777

36

1

7

0000077777

BANK 3

2·28

·18

3·11

1 OOOOO~
177777

0000077777

ODD EVEN

1·26

1·18

2-16

6

BANK 2

BANK 1

3·43
4- 3

3-51
4·51

4·53

3-63
61

4· 3

3·71
4·71

4·73

-81

4· ~

1·49

1-57

·59

1- 17

2·4~

2-57

~-59

2· 7

2·6~

3-49

3-57

·59

3· II

3-69

3·77

·79

3· 7

3·89

4- 7

4·49

4-57

-59

4- 7

4-69

4·77

-79

4- 7

4-S9

34

1- 2

1-44

1-52

-54

1-

2 1-64 1·72

-74

1- 2

1-84

2-32

34

2- 2

2-44

2·52

-54

2- ~

2-64

2·72

·74

2- 2

2·84

3·24

3·32

34

3· 2

3·44

3·52

·54

3- ~

3-64

3-72

-74

3- 2

3-S4

4·24

4·32

34

4· 2

4-44

4·52

-54

4- ~

4-64

4-72

-74

4· 2

4·84

a

1·69

1-77

-79

1- 7

2-77

2-79

2- 37

1-89
2-8~

BANK 3

BANK 2

BANK 1

1·30

1-40

1·50

1-60

1·70

1-S0

1·90

2·20

2-30

2-40

2-50

2-60

2-70

2-80

2·90

H2

3-20

3·30

3·40

3·50

3-60

3·70

3·80

3·90

H3

4·20

4·30

4·40

4 50

4·60

4·70·

4-80

4·90

H4

1·15

1·25

1-35

1-45

1-55

1·65

1· 75

1-S5

H5

2-15

2-25

2-35

2·45

2-55

2-65

2-75

2-85

P

3·15

3-25

3·35

3-45

3·55

3-65

3·75

3-85

HO

1-20

H1

NOTE: 1. Card - Chip location.
2. The Memory Configuration Switch reverses high and low memory within a bank.

WHOLE ALTO WORLD MEETING
JUNE 1,1978

BOSTON' --------~
SOFTWARE

DALLAS

FONTS

EL SEGUNDO

GATEWAYS

....-WAW

TOOLS

PALO AL TO

1----....
HARDWARE

PASADENA
MAINTENANCE

WEBSTER

KEEP IN SYNC
9:00am to 3:30pm

ExecutLve DLnLng Room

EL Segundo, Ca

Whole ALTO World Newsletter

Xerox
Private
Data

Technology and Tools

XEROX

MAY 31, 1978

SPECIAL NOTES
FONT CHANGE COMMING· As detailed in the attached paper on printing, PARC will be
changing its printing fonts on June 15th. Similar changes are expected to occur at other sites
at about the same time. This will require that everyone retrieve a new Fonts.widths file on
each of their disks soon after local Spruce installers announce the change at their sites. Users
with old Fonts.widths will find their output rather unattractive as a result of bad spacing
and ragged edges.

GENERAL NOTES
WHOLE ALTO WORLD MEETING· The Whole Alto World meeting will be held on June
1 at the Cockatoo Inn near the EI Segundo facility. Our host is Dick Sonderegger, SDD. See
next month's Newsletter for an account of the happenings.

TOOLS
HARDWARE
ALTO BUILD . An 8th build will take place during the last quarter of this year.
Requirements should have been made known to Terry Haney, SPG, by June 1. The
configuration is being altered slightly by replacing the current keyboard with an Alto I
form/function compatible keyboard and deleting the five- finger keyset. Transport trays, a
rolling platform for the Alto which still permits it to be placed under a table, may be
ordered as an option.

SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available
from your local IVY server under the directories  and . If they are not
available, or if you arc in doubt as to the version, they may be retrieved from [MAXC]
(same directories). Files stored under other directories are on [MAXC] unless otherwise
indicated, e.g. [XEOS].
NEW RELEASE: GyPSY . This subsystem has been significantly enhanced so it is being
reported here rather than under ReReleases. GyPSY is a text editor originally derived from
an early version of Bravo. It is modeless, that is, you don't have to enter "i" before inserting
text, followed by ESC when finished; just position the cursor and type. It has only simple
formatting facilities, so it is more suited to programming than document creation. It also
provides a hierarchical file facility to group documents, Le. files, into "folders".
One of the enhancements enables GyPSY to replace Executive.run. Replacing Bravo and
Executi ve with GyPSY will free over 200 disk pages, reduce typing, and integrate source code
editing and compilation activities. After booting, the screen will contain several Find and
Execute menu items (seethe attached hardcopy of the GyPSY screen). Bugging an Execute

Whole ALTO World Newsletter

~VII!. Xerox

@i;Q~ Private
~O'v

Data

item will cause the subsystem in the associated { ...} to be run. Bugging a Find item will
cause that folder to be retrieved and a new screen will be displayed containing a Fetch menu
item for each file. Bugging Fetch will open the associated file for editing. These menu lists
can be expanded by the user at will.
GyPSY permits text within the file to be "executed"; simply select the text and bug Do It (in
the window above the text window). For example, if the text selected is a compile command,
contained as a COlnment in the source file, the compiler will be called after automatically
updating the changes. Following compilation, control is returned to GyPSY. Bugging Find
and F'etch opens the file for additional editing as necessary. A second text window can be
opened so that both the source and error files can be viewed simultaneously.
A "hardcopy" facility will immediately format and transmit the current file to a printer, Of
Empress can be used to print a GyPSY file. GyPSY formatted hardcopy is in a double
column format.
Due to its bulk, the documentation is not reproduced here. Retrieve < AltoDocs>GYPsY.press.
NEW RELEASE: HARDCOPY· This subsystem, designed by Jay Israel to save you keystrokes
and concentration, will automatically invoke the Bravo "hardcopy" command from the Alto
EXECUTIVE. It will also call FTP if necessary to retrieve files from a shared file server such
as MAXC or Ivy. Retrieve  Hardcopy.run. The documentation is appended to the
Newsletter.
NEW RELEASE: SO~FTBITBLT • This package, consisting of three files by Dave Boggs,
emulates the BitBlt instruction in software. It can be retrieved by loading
< Alto> SoftBitBlt.dm. The documentation is attached to the Newsletter.

ReRcleases . Subsystems
EMPRESS· The changes are of a minor, internal nature. The documentation is unchanged.
GOBBLE· A part of the SIL system, Gobble has been modified to treat F- ICType identically
to N- ICType so that the same DicLAnalyse can be used for GOBBLE and ROUTE. Retrieve
< SIL>Gobble.fun. The documentation is unchanged.
GyPSY· Extensive enhancements have been made which enables press output of hardcopy
and permits GyPSY'S use in lieu of Executive.run. See the GyPSY entry under NEW
RELEASE for a more detailed discussion. Load GYPSY.dm and the new
documentation,  GYPsY.press.
MENUEDIT - A part of the BCPL MENU package, this releases corrects isolated cases in
which DeBs wre incorrectly written~ See the MENU package below.
MICROD . The nature of the changes are unknown to me. Retrieve
documentation is unchanged.

 Microd.run.

The

READPRESS . The new version fixes a bug in the interpretation of the SkipControlBytes
command. Retrieve  ReadPresS.run. The documentation is unchanged.

2

Whole ALTO World Newsletter

Xerox
Private
Data

ReReleases • Packages

This version, 1.2, uses BitBlt to manipulate the screen, permits the use of a colon in
a string, generates default names if required, and no longer generates zero DCBs. It is
compatible with the previous version. Load  Menu.dm. The documentation is
unchanged.
MENU·

TECHNOLOGY
This month's paper is on printing within the Xerox Alto community. Dan Swinehart, Joe
Maleson, Patrick Baudelaire, and Edward Fiala have put together on overview of existing
hardware and software with an extensive list of references and a glossary. Although it has
many references to PARC specific items, it is a basic document whose breadth should make
it of interest to all who use the Alto.

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not to
be shown to non- Xerox people. Copies are available on [MAXC]  WAWnews.press or may be
obtained from the editor, Frank Ludolph, XEOS, by messaging  or calling Intelnet 8*923- 4356.

3

XEROX
PALO ALTO RESEARCH CENTER
Computer Science Laboratory
May 11, 1978
To

PARC/SDD

From

Dan Swinehart, Joe Maleson, Patrick Baudelaire, and Edward Fiala

Subject

Printing at Palo Alto

Filed As

[ Maxc]  Printing.Press

This document has the twofold aim of describing the printing facilities that are currently
available, and of announcing two major impending changes.

Key Points
We are currently in transition from one major printing format (EARS) to another (Press), with
a corresponding introduction of new printing hardware (Dover. Pimlico. Sequoia). Some
aspects of this transition will affect users quite a bit, some very little. All will of course affect
those who produce formatted files.
One upcoming change that will have substantial effect on the entire community will be the
distribution, on June 15, of a new Fonts.Widths file, correcting the width specifications for our
major document fonts. Previously produced Press files should continue to print reasonably
accurately, although they may not do so forever. Subsystems that create Press files will be
required to supply the current date (machine readable format) in a new field within each new
Press file.
Another Inajor impact will be felt as the Ears system is decommissioned on the same date
(June 15, 1978). It will be possible to convert most EARS format files to Prcss fonnat, and
thus to print them. This includes all new EARS files that are produced by the Pub system, and
most if not all previously created ones.
A modification of printing resolution (from 350 to 384 dots/inch) for Dover and Sequoia
printers will limit printing to the lower 10.6" of each page; information in the top .4" will be
lost. This is expected to affect very few documents.
The sections that follow survey the current state of Printing Formats and Transmission
Protocols, Fonts, Printing and Formatting Programs, Printer Types, and Impending Changes.
Appendices supply a variety of useful information, including a comprehensive glossary of
terms associated with page imaging. There is also a bibliography of related documents and
manuals. Feel free to skim or skip those sections that do not appear to be of interest.

2
Printing Formats

EARS Format

EARS format [Rider1] was developed as the input format for the Ears printer (see below). It
is a character oriented format, specifying for each page the names and positions of each
character to be printed. An EARS format file must also contain a font directory before it can
be printed. This directory, describing the shape of each character to be printed, can be a
permanent part of the file, or may be inserted just before the file is shipped to the printer,
based on a list of requests (the Doculist) that is embedded in the document. Exception: a
default set of 16 commonly used fonts is available at the printer site, and need not be
transmi tted wi th the file.
In addition to characters, line drawings and passable low- resolution bit maps may be specified
using EARS format, by creating suitable "type faces" containing the required patterns. Ears can
handle most Alto screen resolution bit maps in this way.
In Palo Alto, there is only one Ears system (named Palo).
Press Format

Press format [Newman/Sproull] is 'an attempt to define a "universal" format for describing
documents' for printing and editing. Its major goal is the complete description of document
appearance in a device- independent fashion. A Press file should look the same, within device
-limitations, on any printer.
Press format allows the specification of:
Text characters.
Solid rectangles parallel to the paper edges.
Objects whose outlines are defined by a series of graphic cOlnmands including spline
curves. Character shapes may be defined in this way. (see Jonts section below).
Images specified as a matrix of intensity values at arbitrary resolutions. Bit nlap
patterns are an instance of such images, where intensity values are constrained to one
bit.
Any of these entities may be placed at any location on the page, and may be assigned
brightness (obtained with half- tone shading methods) and color characteristics. Characters to
be printed are specified by name. Custom shapes may be included by sending their splines and
the names to be assigned to them, but one usually depends on the server to locate the necessary
shapes based on the names alone, using established conventions (see the Fonts section below).
A printer that accepts Press format is not required to implement all its provisions. The
descriptions below indicate for each program and printer what subset of the Press facilities it
implements.
Text Files

Programs exist on both Maxc and Altos (see below) for con verting standard Ascii text files to
EARS or Press format, with optional headings and page numbers. These programs often
combine translation with transportation to the appropriate printer. For the results to be
pleasing, the text files must contain explicit line breaks.
Pspool Format

Pspool format [Fiala1] is a simple augmentation of Ascii text files. Escape sequences describe
margin settings, column settings, landcape/portrait selection, font selection, underlining, etc. A
document heading may override default selections for user identification, file identification,
etc.

3
At present, only the printing subsystem on Maxcl or Maxc2 (see Formatting Programs, below)
will honor Pspool format, and then only for files to be sent to Ears. A Press version should be
complete by June 15.
Transmission Protocols
A printer is classified as a "server" if it can operate unattended, accepting files sent to it over
the internetwork using a Pup- based protocol. Otherwise it is a "stand- alone" printer, requiring
each user to attend its operation.
The user of a stand- alone printer may choose any available transmission program to transfer
files to the printer's local disk. The Ftp program [Boggs/Taft], using the FTP protocol
[Shochl], is preferred because of its speed, utility, and availability - - it is the only protocol
currently used by the I FS systems.
All server systems currently use a simpler protocol, EFTP protocol [Shoch2], which is more
easily incorporated into sending programs like Bravo that are tight for space. The EFTP
protocol provides only for the transmission of file data. Thus the only identification
information available to the server is information contained in the file itself. This, combined
with some limitations in Press format, has caused some difficulty in properly identifying the
sender of documents to Press printers.
A final protocol, known as EARS protocol [Taft2], is honored by all servers. It provides a
means whereby user programs can determine a server's current status.
See the Formatting Programs section for more information about protocol usage.

4

Fonts
High resolution raster representations of fonts comprise many bits, and are device dependent;
for these reasons font rasters are not included in Press files. Instead, fonts are specified by
family name, a numberic code specifying type face (bold, italic, regular, etc.), point size, and
rotation. An extensive description of font issues can be found in [Sprou1l4]. Two
representations exist for fonts: outlines (described by graphic commands including spline
curves) and rasters (or "bit maps"). Along with the description of character shape according to
one of these representations, positional information is needed. A variety of file formats are
presently used for storing this font information. Sometimes several fonts are included in a
single file, called a dictionary. PrePress [Sprou112] is a program which converts among the
various formats, and performs some bookkeeping operations for font dictionaries. Press
format allows up to 16 different fonts per entity (a page subgrouping). When more than 16
fonts appear in a page, they must be grouped into font sets (of up to 16 fonts) in such a way
that each page contains fonts from only one set. A document may contain up to 64 font sets.
Font Naming Conventions

A standard file naming convention allows identification of what font is contained in a file.
The convention is:
{family- name- in- full}{point- size}{[ BIL]}{[ I]}{[ CIE] }.{extension}
Examples: TimesRomanB.SD, TimesRoman10B.AC
The optional BIL stands for Bold or Light;I for Italic;CIE for Condensed or Expanded. Device
independent fonts (outlines) omit {point- size}. The extension indicates the format (see below)
of the font representation. For device- dependent (e.g., bit map) representations, the standard
conventions contain no clue to the orientation, resolution, etc., of the font.
An alternate font naming convention is used to expand the code describing the type face, in
Press files and in some of the formats below. This convention uses a three letter code, selecting
from the orthogonal attributes
(bold/medium/regular, italic/regular, condensed/regular! expanded). In the TimesRoman10B
example, this face code is thus BRR. See [Sprou114] for the precise mapping between this code
and the actual numeric specifications used in Press and in font dictionaries.
Formats

The format of a file is indicated by its extension.
.SF
.SD
.AC

.CU
.AL
.STRIKE
.EP
.EL

Standard formats include:

Outline representations edited with FRED (device- independent) .
Compact outline representations, produced by PrePress from .SF files (deviceindependent) .
Raster representations edited or created 'with PrePress from SD format (devicedependent).
The remaining formalS can be be converted to AC format. and can be produced
from AC format:
"Carnegie- Mellon" format raster representations.
Raster representations -in Alto (CONVERT) format .
Raster representations in Alto (BITBLT) format.
EARS- format portrait font (run- coded raster).
EARS- format landscape font (run- coded raster) .

Example: Helvetica12I.EP is a 12- point Helvetica font for EARS (face code MIR).

5
Resolution

While raster representations can be automatically converted from outline descriptions, this
process is not performed efficiently with present hardware. In addition, some hand tuning of a
scan converted font often improves its appearance. Therefore, each Press printer is expected
to have local raster copies of all necessary fonts, converted to whatever resolution is
appropriate. Although Press format allows users to include personal fonts in outline form,
Spruce software does not implement this feature.
The Orbit printers (Dover, Sequoia,
Pimlico - - see [Ornstein] and discussion below) generally run at 384 dots per inch. Dovers
currently running 350 dots will soon be converted to 384 (see issues and plans, below). The
Orbit hardware supports a maximum of 4096 dots per scan line, and so limits printing length
to 10.6" at 384 dots.
Widths

There is one problem with keeping fonts external to Press files: the width of a character is not
specified locally, and formatting programs need to know character widths for things like text
justification. This information is kept in a file named Fonts.Widths. Any changes to the
width information (for purposes of standardization or aesthetic appeal) will alter the
appearance of Press files which were produced using different widths. This is currently a
major problem, as we attempt to reach compatibility with the printing world. Additional
incompatabilities are the printing world's two kinds of spaces (numeric and regular), different
characters for hyphen and minus, and the use of ligatures (multiple character combinations
like "ae" or "ff") and kerning (sometimes called "optical spacing" - - altering inter- character
spacing for specific pairs of characters).
A list of the standard fonts to be available on printers in PARe beginning June 15 is
contained in an appendix. More may be added, to all or some, as time goes on.
Printing Programs

The Sears program [Riderl] operates the Ears printers as a server, spooling and printing
EARS format files (using the EFTP protocol).
There are two programs that accept Press format files: Press [Sproulll]
[ Swinehartl] .

and Spruce

Press

This program, the older of the two, will accept and render nearly all Press specifications,
including color (results depend on the printer). Press is a stand- alone program, whose intended
application is the production of high- quality, high- resolution graphical images. Press is
available on most of the printers described in the following section, except for the very fast
ones (see Printers, below). Press does not operate as a "spooling" network service program,
and is therefore not the printing program of choice for high- volume text printing.
Spruce
Spruce is intended as a printing service system, primarily for printing office documents. It
accepts a subset of Press files including text characters, rectangles, and most Alto screen
resolution bit maps. It does not handle splines or arbitrary bit patterns, nor does it honor
brightness and color requests (but see the note below). Enterprising users could obtain limited
line- drawing capability by creating and using appropriate "spline fonts". Spruce operates only
on printers controlled by Alto 11/ Orbit hardware (see Printers, below).

6

AIS
Continuous tone images which have been digitized are stored as an Array of Intensity Samples.
AlS format is used to store such images. Included in an AIS file are various data about the
image which are important for accurate reproduction. Software is available which prints AIS
files using a variety of halftoning techniques. Halftoning simulates various gray tones using
only one ink color by varying the amount of ink in an area proportional to the original
intensity. By halftonitig several different color separations, a wide range of hues can be
achieved.
Color Note

Press format allows specification of hue (color) as well as intensity. The. Press program
implements this feature directly on the Pimlico printers (see below). An interim measure has
been used, in Spruce for Pimlico and in Press for the Colorado system (see below), to produce
color images. In these systems, three or four Press pages, one per color (sometimes including
black) are required for each printed page. A full conversion to direct color specification
support is expected for Spruce.

7

Formatting Programs
M axe Programs

The Pspool program [Fialal] runs as a background job on the M axe systems, formatting and
transmitting documents to printers as they appear on the (PRINTER) directory. Files are
placed there either explicitly or in response the attempts of programs to write to the LPT:
device. Files already in EARS or Press format may be sent to an appropriate printing server.
Press format files may, alternatively, be converted to EARS format and sent to the Ears server.
Psj?Ool format may be converted into either EARS or Press format and sent (see the
information on Doegen, below). Pspool will add necessary .EP or .EL files (EARS font
descriptions) to a file on its way to Ears, if that information is not already in the file. It will
use the Doeulist section of the EARS file to decide what to send.
The EPress program is invoked by Pspool to translate Press format files into EARS format for
printing on Ears. This conversion is automatic. The user has the option to save the resulting
EARS file.
The standard way to direct text or pre- formatted files to printing servers is to run the Ears,
Press, List, or Copy commands. These programs do intelligent things about selecting files with
the proper extensions, embedding appropriate header information in EARS files, etc. Headings,
page numbers, margin trnasformations and size reduction are also available through the Ears
command.
The Printer Status command will indicate the names of files spooled on the (PRINTER)
directory and of recently printed files, and the state of the most recently active printing server.
Respool may be used to retransmit a file that was send for printing but did not get printed
correctly for some reason.
The Pub [Tesler] formatting program is a batch processing system that is useful in formatting
large documents, especially if they need indices or cross- reference, or if they are going to be
updated frequently. Pub will produce plain text output (for on-line perusal) or EARS format
output, including a Doculist that Pspool can use to include the necessary fonts. Once the Ears
system is gone, production of Pub- formatted documents will of necessity be a two- stage
process, producing first the EARS format file on M axe, then a Press format file on an Alto
-using PressEd it (below). - Docgen.Prt
Pspool often needs additional information about a user's printing preferences before it can
perform its tasks. When sending Press files, for instance, Pspool must know what server to send
them to. Although it is always possible to specify these options directly, it is useful to be able
to default them. The system provides global defaults for each option. The user may specify
different ones by creating a Maxe file called Doegen.Prt. The system defaults and the format
of Docgen.Prt may be found in [Fiala2].

8
AI to Programs

The Gears program [Riderl] will produce an EARS format file from a text file, transmitting
the result to Ears. It will optionally supply a heading and page numbers on each page, expand
tabs properly, and obey a small number of font change and formatting specifications. In
addition, it uses the Ears protocol to report on the status of the printer.
NGPR is part of the design automation package. It produces EARS format versions of Sit
format files, either leaving them on the local disk or sending them to Ears.

The Empress [Boggs/Maleson/Tiberi] and N PPR programs are analogous to Gears and NGPR,
except they produce Press files. Empress does not provide all the formatting options that Gears
does, but it does include some useful Press file processing functions. It is in addition willing to
ship files that are already in Press format to a Press printer. NPPR uses Empress, via a
command file, to print its output.
The Office Talk- Zero (OZ) system [Newman/Mott] is also capable of producing and directly
sending Press files to suitable printers.
The Bravo editor will produce hardcopy in either EARS or Press format. It can either produce
a local file or transmit the result directly to a printer. In the latter case, Bravo uses the file
Swatee as a scratch file. Recent versions of Bravo and Draw (see below) will accept color
information and produce the appropriate "color separated" Press file.
User.Cm

The [HARDCOPY] section of the User.Cm file on one's Alto disk serves to personalize default
printing options (e.g., preferred printing format, preferred printer, etc.) It is analogous to
Docgen.Prl on Maxc. The following example contains a sample of each kind of entry that I am
aware of:
[HARDCOPY]
PREFERREDFORMA T: Press
EARS: Palo
PRESS: Menlo
COLOR- PRESS: Victoria
PRINTEDBY: "$"
FONT: TIMESROMAN 10 MIR

Press or Ears
Name or legal network address of Alto providing Ears
printing service
Similarly for preferred Press printer
Preferred color printer (Press only)
See explanation below
See explanation below

The FONT entry, used up to this point only by Empress, specifies that TimesRomanl0i (italic)
should be used as a default font instead of Gacha8 (Empress's default choice). The second,
point size argument, and the third, face specification argUlnent are optional. The face argument
contains three letters specifying weight (M, B, or L), slope (R or 1), and expansion (C, R, or E),
respecti vely.
The PRINTEDBY field, if present, specifies the name to be used in the Name field on the
break page. The current disk login name will replace the character $. Empress and Bravo both
chose "$" as a default in the absence of a specification.
As far as we know only Bravo honors the PREFERREDFORMA T entry.
Of course, he [BRAVO] section of User.em also contains font selection specifications.

9
Related Programs
Markup [Newmanl], Draw [Baudelairel], and Sil [Thacker/Sproull] are interactive programs
that produce Press file output for hardcopy. Markup and Draw are illustration programs with
different strengths and emphases. Sil is a part of the hardware design automation package, but
is also useful for producing charts and other simple line drawings.
PressEd it [Newman2] is used to edit and merge Press files (at the page level), and to convert
EARS format files to Press format.
Fred [Baudelaire2] is an interactive spline curve editor specialized for font design. PrePress
[Sprou1l2] is a utility program for converting spline character shapes to bit maps in various
formats and resolutions, as described in the Fonts section. Both are of uSe mainly to
implementors of printing or display software.

10
Printer Types

All the printers described below are Raster Output Scanner (ROS) printers. The complete
printing facility includes a ROS and an Electronic Image Processor ( EIP), consisting of an
Alto and either a little or a lot of specialized imaging and interface hardware. Newer systems
interface EIP to ROS using the "9- Wire standard" [Rider2, Rider3] - - a standard hardware
interface and communications protocol.
Ears. [Riderl] A modified 7000 duplicator engine with Slot (Scanned Laser Output Terminal)
imaging optics. Ears is controlled by a very powerful special purpose EI P, the Research
Character Generator (ReG). The RCG is in turn controlled and supplied with data by an Alto.
The Ears printer was designed and built at PARCo
Slot/3100. modified 3100 copier with Slot imaging optics. Image processing is done entirely
in Alto microcode, and the machine is controlled through a very simple interface. This simple
structure is made possible by the relatively slow operating speed of the 3100 engine. Because it
runs slowly enough, and because the 3100 engine provides excellent solid- area development,
high- quality, high- resolution graphic objects may be rendered on this machine. The Slot/3100
systems were built by XEOS.
Dover. [Ellenby; Sprou1l3] A modified 7000 duplicator with an improved Slot head totally
contained within the original engine. Dovers are engineered to be produced in reasonable
quantities. They contain ROS Adapter (video and control electronics) modules that may be used
in several other printers (see below). The adapters communicate with their controlling Alto lIs
using the 9- Wire Standard. A Dover Alto contains relatively inexpensive EIP hardware, called
Orbit [Ornstein, Sprou1l3]. This device can, with SOlne preprocessing assistance from its Alto,
generate text pages and ruled forms at full Dover speed.
Dover's capabilities are largely determined by the bandwidth of the associated EIP and storage
mediuln. The Orbit hardware reduces the bandwidth required to do text and solid rectangles,
but Alto main memory and T80 disk bandwidth limitations restrict Alto/ Orbit/ Dover systems
to relatively low- resolution graphical output. The Allo/ Orbit hardware can produce highresolution, high- quality graphical output when used with slower engines (e.g., Sequoia,
Pimlico).
Dover and Orbit were developed by team from PARe and EOD/SPG.
Sequoia. A modified 3100 copier equipped with a Slot head. Sequoia uses the Dover ROS
adapter, obeys the 9- wire standard, and is controlled by an Alto II- Orbit. Sequoia was
developed and manufactured at XEOS. Its operating speed and good solid- area development
allow Sequoia to render high- quality graphics.
Pimlico [Swager, Baudelaire/Swinehart] A modified 6500 color copier. The original optics
have not been removed; therefore hybrid composition techniques involving both platen and
raster- scanned inputs are possible. Pimlico uses the Dover ROS adapter, obeys the 9- wire
standard, and is controlled by an Alto 11- Orbit. The entire electronics control package has been
replaced by a Inicroprocessor- based system, using an M6800, that can communicate with the
controlling Alto II via standard adapter commands. This vastly improves the engine control
protocols and capabilities. Pimlico was developed by a team from PARC and EOD/SPG. Its
development was expedited with special funding provided by C. Peter McColough as part of
the Xerox World Conference effort.
Alto/ Orbit/ Pimlico is capable of high quality renditions of graphical objects.
Colorado. A modified 6500 color copier that has been in service at XEOS in Pasadena for
several years. Colorado has been developed by Dale Green (OSL) and his group, and has been
used in a variety of pioneering color copying and printing experiments. This system is a high

11

resolution, very high quality RIS- ROS system, with color correction, tone reporduction (TRC),
and halftoning implemented in hardware. The ROS may also be used, at lower resolutions, as a
color printer for the Alto. The interface to the Alto is the same as is used for the SI0[/3100.
Colorad a uses Press and AIS printing software to print "color separated" files (see the note 011
color rendition above). Its 6500 engine has been augmented with a fourth developer (black) to
print four- color pictures.

TC- 200. A modified TC- 200 telecopier, interfaced to an Alto in a manner similar to the
Slot/ 3100. This system also contains RIS (raster input scanning) capabilities. It was developed
at ADL. A TC- 200 system will soon be available at PARCo
Versatec Plotter. A modified Versatec electrostatic plotter, interfaced to an Alto in a manner
similar to the Slot/ 3100. This system is capable of printing on extremely large pieces of paper,
but at a slower speed than the xerographic printers.
Performance and capability specifications for these printers appear in an appendix.

12
Impending Changes
Orbit Printer Resolution

We are currently operating all the Orbit printers (Dovers, Pimlicos, Sequoias) in Palo Alto at
350 dots/inch. For a variety of technical reasons, we plan to switch to a 384 dots/inch
resolution as part of the June 15 cataclysm. With one important exception, users will not notice
the change.
The exception is that, again for technical reasons, Orbit printers at 384 dots/inch are limited to
a 10.6" high page. Dovers and Sequoias will thus enforce a .4" top margin, which may cause
some information to be "clipped" from the page. Pimlico output will be unaffected.
The Demise of Ears

The Palo/ Ears system, because of its advancing age, is becoming quite difficult to maintain.
For this reason, a second floor tribunal has decided that Palo will be removed from service on
June 15, 1978. The remainder of this section discusses various issues that this decision raises.
Spruce printers are now functionally competitive with the Ears system, although the number
of available. useful fonts is somewhat diminished, particularly landscape fonts (see the
appendix). Pending enabling technology, we are delaying plans to fetch additional font
specifications from less restrictive storage on Juniper or Ivy systems. Some performance
improvements are also planned in anticipation of the increased load.
It was also necessary to decide the fate of EARS format files: those currently in existence, and
those that will continue to be produced by Pub. Most EARS files, including all new Pub
products, contain the directory entries (Doculists) that allow the PressEd it program to produce
equivalent Press files from thein. We hope it will be possible to convert EARS files that do

not contain this directory information to those that do. If not, then a relatively small number
of old EARS files, produced by older verions of Pub, will no longer be printable.
One additional impending change, the modification of some of our character widths, add to the
difficulties of retiring Ears. This is further discussed in the following section.
Character Widths

Press format files do not in general specify the height and widths of their text characters.
Instead, it is assumed that the producer of a Press fi1e (e.g., a formatting program), and its
consumer (usually a printing server) have a common notion of these values. Each Alto based
formatting program uses the file Fonts.Widths, which describes the heights and widths of all
available type fonts in device- independent units. This width file is carefully maintained by
each installation. It is auglnented as new fonts are added.
The printing programs maintain corresponding width information, usually device- dependent,
that agrees with the information in Fonts.Widths. In this way, the accuracy of Press renditions
is guaranteed.
Unfortunately, we have learned that the widths originally assigned to the characters in the font
families TimesRoman and Helvetica were incorrect - - for the most part, the current widths
produce excessive inter- character spacing. For this reason, it will be necessary to institute a
new width standard, using the following scheme:
On June 15, 1978, a new Fonts.Widths file will be promulgated. At the same time, an improved
set of fonts, geared to the new widths; will be installed on all Palo Alto Spruce and Press
systems (many sites already use these new fonts· and widths). Users who obtain the new widths
file should notice no changes. Problems might,. however, be expected in printing previously

13
created Press files (using the old width specifications). The following steps will be taken to
reduce the inconvenience:
Old Press Files: The Press file document directory includes some spare fields. We have
chosen one two- word field to represent a date and time, in Alto Standard format [Taft2].
The assumption is that old Press files contain values in this field that can be rejected as
valid dates (typically 0 or -1). Subsequent to June 15, 1978, any Press file whose date
appears invalid, or whose date precedes June 15 will be printed using the old widths. Files
with dates of June 15 or later will use the new widths. It is not clear how long these old
widths will remain available. The scheme to be used is quite general, and can support
additional future width modifications, but such changes are painful, and are expected to be
quite rare. Press file implementors: consult the information in [Swinehart2] or in the
newly- updated version of [Newman/Sproull] for details required to update your output
modules.
Old EARS Files: As indicated above, it should be possible to add Doculist directories to
directory-less files. (These files contain the EARS fonts directly; PressEdit does not find
them useful.) The old Fonts.Widths will be available, so that PressEdit may be used to
create "old" Press files, complete with invalid or pre- June dates.
New EARS Files ( Pub output): The .EP format files that Pub uses instead of Fonts.Widths
to perform its formatting will be modified to reflect the new widths (note that only the
width information in each font file will remain relevant, since Palo will have been retired.)
Thus, PressEdit will have the proper information, using the new Fonts.Widths, to produce
"new" Press files. These mechanisms are clumsy enough that we expect them to hasten the
transition to newer formatting systems.
Longer- Term Issues

lVfany other modifications and additions have been contemplated for improving printing
service. Most will require extensions to either the printing protocols or to the Press format.
Potential printing protocol extensions would permit the specification of the sending user
(distinct from the creator of the Press file). It would also permit the transmission of nonf(~sident, machine- dependent fonts (Press format supports the transmission of character shapes
as outlines, but not as bit maps). In addition, one could request priority treatment, or could
request that printing be delayed until the user is present, for security reasons. Other extensions
might allow references to fonts and Press files on other file systems (e.g., Ivy) to be spooled,
instead of the files themselves.
These issues are mentioned as possible areas of continued development; implementation should
be considered distant.
Summary

This section has described some impending changes in terms of some problems and their
solutions. The solutions are summarized in the Key Points section on page 1.

14
References

[ Baudelairel]

Draw, by Patrick Baudelaire, found in the Alto User's Handbook,
updates in [Maxc] Draw-News.Ears.

[ Baudelaire2]

Fred, by Patrick Baudelaire,

[Maxc]  Fred.Ears,

22 pp.

[Baudelaire/Israel/Sproull] Array of Intensity Samples - - AIS, by Patrick Baudelaire, Jay
Israel, and Robert Sproull, [Maxc] < AIS> AIS- Manual.Ears, 48 pp.
[Baudelaire/Swinehart] Pimlico Protocol and Software, by Patrick Baudelaire and Dan
Swinehart, [Maxc] < Dover> Pimlico.Press, or [IFS] < Pimlico> Pimlico.Press, 21
pp.
[Boggs/Maleson/Tiberi] Empress, by David Boggs, Joe Maleson, and Rick Tiberi (D.
Swinehart, ed.), [Maxc]  Empress.Tty, 5 pp.
[ Boggs/Taft]

FTP Reference Manual, by David Boggs and Edward Taft, found in
the Alto User's Handbook, or as [Maxc]  Ftp.Tty, 17 pp.

[ Ellenby]

Dover Overview, by John Ellenby, available from the author.

[ Fialal]

Document Distribution, by Edward Fiala,
24 pp.

[Maxc1]  Docudis.Ears

Document Distribution, by Edward Fiala,
8 pp.

[Maxc1]  Docdis.Ears

(probably archived),

[ Fiala2]

(probably archived),

[Lampson]

Bravo, Reference Manual, by Butler Lampson, found in the Alto
User's Handbook.

[ Maleson1]

Pictures, PRESS, and you, by Joe Maleson, archived on
[maxc] < Press> HalftoneMemo.Press and HalftonePlates.Press.

[ Maleson2]

Rotating halftone screens, by Joe Maleson, archived on
[Maxc] < Press> Rotation.Press.

[Newmanl]
[Newman2]

Markup Reference Manual, by William Newman, found in the Alto
User's Handbook, or as [Maxc] < Altodocs>Markup.Ears, 11 pp.
PressEdit Reference Manual, by William Newman,
1 pg.

[Maxc] PressEdit.Tty,

[Newman/Mott]
[ Newman/Sproull]

OfficeTalk Zero Reference Manual, by William Newman and Tim
Mott, I Maxc] Oz-15.Ears, 25 pp.
Press File Format, by William Newman and Robert F. Sproull,
16 pp.

[Maxc]PressFormat.Press,

[ Ornstein]

Qrbit General Description, by Severo Ornstein,
38 pp.

[Maxc] < Dover>OrbitWriteup.Press,

[ Riderl]

Ears, Gears. Sears. and Other Related Items, by R. E. Rider,
13 pp.

[Maxc]  Ge ars.Tty ,

[Rider2]

R()S Interface Conventions, by R. E. Rider,
4 pp.

[Maxc]  Roslnterface.Press,

15
[ Rider3]

RIS/ ROS Interface Conventions, by R. E. Rider,
5 pp.

[Maxc] < Rider> RisRoslnterface.Press,

[ Shoch1]
[ Shoch2]

A File Transfer Protocol Using the BSP -- 2nd Edition, by John
Shoch, [Maxc] (Pup>FtpSpec.Ears, 16 pp.
EFTP: A PUP- based Ether File Transfer Protocol, by John Shoch,
16 pp.

[Maxc] (Pup>EFTPSpec.Ears,

[ SprouIn]

Press Printer Operation, by Robert F. Sproull,
[Maxc] < Gr- Docs> PressOps.Ears.

[ Sprou1l2]

PrePress Manual, by Robert F. Sproull,
17 pp.

[Maxc] PrePress.Ears,

[ Sproull3]
[ Sprou1l4]

Programmer's Guide to Orbit, the ROS Adapter, and the Dover
Printer, by Robert F. Sproull, [Ivy] OrbitGuide.Press, 37 pp.
Font Representations and Formats, by Robert F. Sproull,
21 pp.

[Maxc] (GR-DOCS>FontFormats.Ears,

[ Swager]
[ Swinehartl]

Gand alf (Pimlico) Overview, by Gary Swager, not yet released.
Spruce Reference Manual, by Dan Swinehart,
13 pp.

[Ivy] SpruceManuaI.Press,

[ Swinehart2]

Let's Talk About Printing, by Dan Swinehart,
2 pp.

[Maxc] PrintingUpdate.Press,

[ Swinehart3]

Printing at Palo Alto, by Dan Swinehart (this document),
23 pp.

[Maxc]  Printing.Press,

[ Taftl]

Ears Protocols, by Edward Taft,

[ Taft2]

Alto Time Standard, by Edward Taft,

[ Tesler]

Pub: The Document Compiler, by Larry Tesler, Stanford Artificial
Intelligence Laboratory Operating Note 70, September, 1972.

[ Thacker/Sproull]

sa, Analyze, Gobble, Build Reference Manual, by C.P. Thacker and
R.F. Sproull, [Maxc] SILManuaI,Press, 27 pp. + appendices

[Maxc]  EarsProtocols.Bravo,
[Maxc] AltoTirne.Bravo,

1 pg.
4 pp.

16
Appendix·· Font Naming Conventions, User.em Formats

Font file naming convention:
{family- name- in- full}{point- size}{[ BIL] }{[ I]}{[ CIE] }.{extension}
BIL:
CIE:
Point Size:
Extension:

Bold, Light
Condensed, Expanded
Omitted for device- independent fonts (outlines)
Designates encoding format (see below).

Examples: TimesRomanB.SD, TimesRoman108.AC

Type face encoding convention (in Press files, font specifications):
BIMIR:
IIR:
C1EIR:

Bold, Medium, Light
Italic, Regular
Condensed, Expanded, Regular

2, 0, 4 (see [Sproull4])

1, 0
6, 12, 0

Font formats, identified by file extension:
Spline outlines, represented by text descriptions .
Compact outlines, produced by Pre Press from .SF files (device- independent) .
Raster representations edited or created with PrePress from SO format
(device- dependent).
(device- dependent,
.CU
"Carnegie- Mellon" format raster representations .
convertible to/from
.AL
Raster representations in Alto (CONVERT) format.
.AC format )
.STRIKE Raster representations in Alto (BITBL T) format.
.EP
EARS- format portrait font (run- coded raster) .
EARS· format landscape font (run- coded raster).
.EL
.SF
.SD
.AC

Example:

Heivetica121.EP is a 12- point Helvetica font for EARS

UseLCm, [HARDCOPY]

(face code MIR).

Section (Comprehensive example)

[HARDCOPY]
PREFERREDFORMAT: Press
EARS: Palo
PRESS: Menlo
COLOR- PRESS: Victoria
PRINTEDBY: "$"
FONT: TIMES ROMAN 10 MIR

Press or Ears
Name or legal network address of Alto providing Ears
printing service
Similarly for preferred Press printer
Preferred color printer (Press only)
See explanation below
See explanation below

FONT:
Overrides Empress's default (Gacha8). Uses Face codes as given above.
PRINTEDBY: Overrides Empress, Bravo defaults (Username on Alto disk). The "$" character requests
the Username field.
Others:
See text {see also the [BRAVO] section of User.Cm.}

17
Appendix·· Printer Characteristics and Capabilities, Current Palo Alto Printers
Printer Specifications
Printer

Ears

Paper Speed Orientation
in/sec sec/page
10
Landscape 1

Slot/3100

3.4

Dover

10

Sequoia

4

3.4

4

Resolution
dots/inch

Software

Notes

500x500

High quality

either

384

Sears
Press 6

Landscape

300-400

Spruce

Predominantly text, low res. bit maps

300-400

Spruce 3

Low vol. text, quality

Landscape

Predominantly

text
graphics

graphics

Pimlico

4

18 7

Portrait

300-400

Press 2

High quality

color graphics

Colorado

4

18

7

Portrait

300-700 4

Press

High quality

4-color gr., cop.

IC-200

.55

22 8

Portrait

200

Press

Low cost, RIS capability

Versatec

Portrait

Press

Notes:
1.
2.
3.
4.

Paper moves sideways through machine. Paper moves longways in Portrait mode.
Spruce is also available for this system.
Press may be available soon for this system, as well.
High resolution used in direct copying (RIS/ROS) operation, and in special printing modes, using two printer
dots per dot specified by the image processor.
5. Variable speed, depending on black/white ratio, line by line.
6. The AIS program will also run on all Press printers.
7. About 6 seconds per revolution, three revolutions per full- color page. The first page takes another several
seconds to emerge from the machine.
8. Roll fed machine - - no inter- page spacing.

Summary of Composition/Printing Program Capabilities
Editor/Illustrator Outputs

Press Features

Bravo

Markup

Sil

Draw

x
x

x

x
x

x
x

Spruce

AIS
text
rectangles
graphics font
objects
low res. dots
high res. dots
color

x
x
x

x2

x

x
x

x

1 D=Dover, S=Sequoia. P:::Pimlico;

Printing Software

2

& Printers 1

Press (D)

x
x

x
x
x

x

x

Press (S,P)

Ears

x
x
x
x
x

x
x
x

x
p2

P

"Color-separated" Press files, only, at present

Currently Available Printers
Name

Ether Address Location

Printer Type

Configuration

Server Protocol

Palo

3#3#

Ears

Model 44

EFTP (Ears format)

35-2077

Menlo

3 #164 #

35-2026

Dover

2 Model 31's

EFTP (Press)

Wonder

6 #265 #

35·3040

Dover

Model 31 only

EFTP (Press)

Glover

3 #121 #

35-2069

Dover

2 Model 31's

EFTP (Press)

or stand- alone

Viola,
Victoria

3 #341 #

35-2069

Pimlico

T80

EFTP (Press)

or stand- alone

Kanji

5#52#

34- B1 0

Dover

T80

EFTP (Press)

Daisy

5#6#

33~

Dover

2 Model 31's

EFTP (Press)

Slot-2

3#116#

35- 2015

SIot/3100

T80

stand- alone, by appt. only

249

18
Appendix •• Available Fonts (Palo Alto)
Files Containing Available Spruce Fonts (as of June 15, 1978 .. PARC only)
[Ivy] (Dover)Spruce.Fonts

Available Spruce Fonts (as of June 15, 1978 .. PARC only)
Family

Size (pt.)

Face

TimesRoman

8, 10, 12

MRR, BRR, MIR, BIR

Helvetica

7,8, 10, 12
6
18

MRR, BRR, MIR, BlR
MRR, BRR
MRR, BRR

Gacha

8,10
12
12

MRR, MIR
MRR
MIR

Cream

10, 12

MRR, BRR, MIR, BIR

Math

8
10

MRR
MRR

Api

8,10

MRR

Hippo

8
10

MRR
MRR

Sigma

20

MRR

Sail

8

MRR

Gates

32

MRR

Logo

24

MRR

Keyhole

20

MRR

Dots

256mica

MRR (for Alto bit

Arrows

10

MRR

Landscape Fonts:

TimesRoman

8

MRR, MIR, BRR

TimesRoman

10

MRR, BRR

Helvetica

6

MRR; MIR

Gacha

8

MRR

Sail

6

m~ps)

19
Appendix"" Useful File Directories
System

Directory

Description

[Maxc1]

< Gr- Docs>

Graphics- related documents: Press formats, font formats, PrePress and
Fred documentation, etc.



.EP, .EL, and (obsolete) .AL fonts for use on Altos and Ears. As of
this writing, they correspond to the "old" Fonts.Widths specifications.
Alto users should obtain their .EP and .EL fonts (for use with Bravo)
from this directory.

< AltoFonts> .AL, .STRIKE fonts for use on Altos. As of this writing, they
correspond to the "old" Fonts.Widths specifications. Alto users should
obtain their screen fonts from this directory.
 .SF (mostly archived), .SD, and .AC fonts that are sources for the
< Fonts> directory, and for current Palo Alto Spruce and Press fonts.
< Alto>,
The repository for many of the systems described in this document.
 The current "old" Fonts.Widths also resides on .


Documents and programs for the Spruce system, the Orbit EIP, and
the Dover, including diagnostic programs. Many of these files are
obsolete, having been superceded by files on [Ivy] 

The AIS program, manual, and some sample AIS pictures.



The Press program operations manual, many sample Press files.

< Ears>,
Nearly empty, mostly obsolete directories.


[ Ivy]

< Spruce>

Current Spruce system and operations manuals,. the current OrbitTest
diagnostic program, other systems valuable for Spruce development.

 .SD, .AC, and .AL fonts corresponding to the proposed "new"
Fonts.Widths standards. These have also been scan- covertcd at 384
dotslinch for Spruce and Press systems.


Spruce font directories, for use on Dover systems. Contains both "old"
style fonts and some of those to be used as "new" style fonts.



"new"style Spruce font directories for Piml ico printers.



"new" style Spruce font directories for Sequoia printers.



Copy of

[Maxc]  directory by other programs; in addition to printing the files that
appear there, Pspool manages this directory.

An augmentation to standard Ascii text format, specifying simple margin
adjustments, font changes, and heading requests. The Pspool program interprets this
format, converting to the proper printer specifications.
Pub. A program on Maxc which takes documents containing special formatting
commands, and produces EARS files.
PUP. The P ARC Universal Packet, a format for data packets that can be routed or
broadcasted among any of the hosts in the internetwork. PUP format specifies only
source, destination, error checking information, a top-level command code, and limited
sequencing information. Additional protocols must be implemented by structuring the
data contained in the packets.
PUP-based Protocols. Any of the hierarchy of communications protocols that have
been defined in terms of PUP (e.g., EFTP, FTP, BSP, RTP (Rondesvous/ Termination
Protocol), etc.)
rectangles (Press). Special Press objects whose shapes are specified by two corners; the
rectangle sides are drawn parallel with the paper edges~ Rectangular shapes which are
not parallel to the paper edges are considered regular objects.

ROS,RIS. Raster output(input) scanner. A device which produces a video stream,
either to a printer (ROS) or from a document (RIS).

23
ROS Adapter. A hardware module which communicates among the Orbit, ROS, and
printing engine.

The printing and spooling program for the Ears ROS system.

Sears.

A Xerox 3100 copier with Orbit and ROS adapter.

Sequoia.

A program which runs unattended, accepting input from the internetwork.

se.rver.

SIL. A design program on the Alto, which supports circuit design. The graphic
features included for circuit design are useful for other design functions; SIL is
sometimes used as a general graphic editor.
Slot.

A laser ROS (Scanned Laser Output Terminal).

Slot/3100.

A Xerox 3100 copier with a simple Slot interface.

An Alto/ Slot/ 3100 system, currently located in SSL (appt. only).

Slot-2:

solid-area development. The ability to produce an image with large areas of solid toner
(3100, 6500). Attempts to print solid areas on other copiers causes '~white- out," where
only the edges of the area are printed.
splines (as used in Press).

A kind of curve definition, using cubic equations.

Spruce. Software for printing simple Press files (text, fixed resolution bitmaps) on an
Orbit device. Spruce is a server.
Stand-alone printers.

Printers which are not servers.

A 200 dot per inch RIS/ROS system. Output speed is about 30 seconds per

TC-200.

page.
An Alto/ Sequoia/ Spruce system, located in SDD/Palo Alto.

Turkey:

An Alto/ Pimlico system, located in CSL. Runs Spruce or Press.

Viola:
Versatec.
Wonder:

A matrix printer.
An Alto/ Dover/Spruce system, currently located in Bldg 35, 3d floor.

3100.

A solid- area development Xerox copier.

6500.

A solid- area development color Xerox copier.

7()OO.

A high speed Xerox copier/duplicator.

t

Scan

for {

GYP S Y of May 12, 1978
Quit
i111 substitute } for {} Len.lith

GYPSY

Time

DEVELOPMENT

Find the Folder 1abe 11ed ...
Sy stem Fi 1es
In sf:rt a ne~J Folder 1abe lled ...
Execute {Put}

Execute {Ftp Maxc}

Execute {Chat}

·:,."· .........
Co .'"" I I -fe
t...n·
·f.~ ~.

{1J

Execute {Ftp

Execute {}

Iyy}

hardcopy. tty

6-JUN-78 14:28:16

Page

HARDCOPY SUBSYSTEM
Hardcopy is a program for automatically invoking the Bravo "hardcopy" command from
the Alto executive. It will also call FTP if necessary to retrieve files from a shared file
server such as Maxc or IFS. This subsystem saves keystrokes and your concentration, but
not clock time.
How to use it ...
You can say to the Alto

Ex~cutive:

> Hardcopy file-descriptor file-descriptor
where a file-descriptor has the usual format:
[host]fileName.extension
All fields are optional, except fileName. If ".extension" is omitted, a default is taken
from the user.cm file. If "[host]" is omitted, Hardcopy looks first on the local Alto
disk; if the file is not there, it takes a default remote host from the user.cm file. Once a
"host" or "directory" appears on the command line, it remains in effect along the line
until overriden by another. Version numbers and sub-directories can be used when
contacting servers that support these features.
For multiple copies, attach a switch to a file-descriptor; for example "HardCopy
someFile.bravo/3", for three copies. The copy quantity remains in effect along the
command line until overriden by another.
A temporary file Hardcopy.scratch$ is created and deleted if a file is retrieved from a
server.
You need the proper fonts, and Bravo 6.0 or later.
Name completion and "*" substitution work for local files only.
How to obtain it ...
1. Using FTP, load the file hardcopy.dm. This includes two files: hardcopy. run and
UserCm.slice.
2. UserCm.slice contains two parts: a Bravo H.INIT macro and a specificatlon of default
host and default file extension. Edit the first part into the bravo portion of your
user.cm file. Add the second at the end of user.cm, after replacing the host name and
the extension with your favorite ones {the extension must include the leading dot}.
Don't forget to "Bravo/I".

1

6-JUN-78 14:28:16

softb itbl t. tty

Page

For Xerox Internal Use Only -- May 22, 1978
SoftBitBLT

May 22. 1978

1

Soft BitBLT

This package contains a single
BitBlt instruction in software.

procedure, BitBlt, which
It is not reentrant.

emulates the

BitBlt(bbt}
bbt points to an even word aligned BBT structure as defined in
BitBlt.decl. See the Alto hardware manual for details.
BitBlt does some setup in BCPL and then calls an assembly language
procedure to do the work. It is distributed as three files:
BitBlt.decl
BitBl tB. b r
BitBl tA. b r

Declarations needed to use the package
BCPL setup code
Assembly language inner loop

1

Whole ALTO World Newsletter
Technology and Tools

XEROX

June 30, 1978

SPECIAL ANNOUNCEMENTS
WHOLE ALTO WOULD CHAIRMAN CHANGE - Liz Bond, present chainnan of the Alto group,
suggested at the June 1st meeting that a new chainnan be selected for the Whole Alto World.
Instrumental in forming the group and staffing the coordinator function, she has held the position
since the group's inception. Liz will continue to participate actively as a representative from XEOS.
A committee, consisting of Art Axelrod (WRC), Liz Bond (XEOS), Terry Haney (SPG), Darwin
Newton (GINN), and Dick Sonderegger (SDD), was appointed to nominate a successor.
RENEW YOUR SUBSCRIPTION NOW· As all periodicals must, it is time to validate the current
Newsletter distribution list. Appended to the Newsletter is a fonn to be completed and returned.
Please fill in your name, mailing address, and organization. There are also some optional questions
concerning the Newsletter and how you use the Alto. The answers will be used to shape the
information content of future editions. Return the completed fOlID to the coordinator as indicated
on the form. Only those individuals that return a completed form will cOlltinue to receive the
Newsletter. For all others, the Newsletter is stored as a Press file and may be retrieved from
Doc>.
Operation of the enhanced Gypsy was described by Frank Ludolph. The changes permit Gypsy to
serve as both programming text editor and system executive, leaving more disk space for
programming use.
Jerry Elkind, chairman of the Special Products Allocation Committee, discussed the Committee's
operation. Composed of representatives from Corporate Research, lTG, and lPG, it allocates Xeroxbuilt special products in limited supply, such as the Alto and peripherals, to requestors in a manner
that best serves the Corporation.
Much of the afternoon session was used by organizational and site representatives to exchange
information about current activities with others.
The meeting ended with a presentation by Ron Rider on printers under current development.

TOOLS
MAINTENANCE NOTES
BOARD REPAIR· Items returned to SPG for repair should now be sent to Ron Cude, Ml-38,
instead of Terry Haney as in the past. Items too large to be mailed should be sent to M1 North
Dock, 555 S. Aviation, attn: Ron Cude. Please include all available information about the problem
and symptoms, including hardcopy output if the item is a part of printing hardware. Repair will be
scheduled in conjunction with sPa's other activities.
DISK DRIVE CHECKOUT BY THE USER· Users can now verify correct operation of their
Alto's disk drive with DIEx, .the DIablo disk EXerciser. To use it, ready a scratch disk (any
infor11Ultion 011 the disk will he destroyed), etherboot, and enter diex CR • DIEX will ask you to
disable the writeprotect. by entering 'f-'. In the upper window is a menu of commands and
parameters. The parameters are preset to default va1ues. If the disk you have inserted is a new disk,

2

Whole ALTO World Newsletter
i.e. it hasn't been previously initialized with a file system, bug Init Verify using the left (top) mouse
button. When that operation completes, or if the disk has been previously used, bug Do Test. The
test will now run for some time, alternately writing and reading the entire disk. Any errors detected
will appear in the larger, lower window. If errors are indicated, contact your maintenance personnel.
Trident disk drives can be checked out in a similar manner using TRIEX.

SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available from your
local IVY server under the directories  and . If they are not available, or if
you are in doubt as to the version, they may be retrieved from [MAXC] (same directoIies). Files
stored under other directories. are on [MAXC] unless otherwise indicated, e.g. [XEOS).
MESA 4.0 . The newest MESA, version 4.0, was released on June 1st. The emphasis on this release
is in three areas: implementation of features required for effective use of the new machine
architecture, reduction of overhead in the basic system structures and improved perfonnance of the
Mesa nllltime environment, and extension of the debugger's capabilities (primarily an interpreter for
a subset of the Mesa language). To become a formal MESA user, with all attendant privilages, send
a message to  describing your intended use.
USING GyPSY . Some questions have been posed about GyPSY files as a result of the
enhancements announced in last month's Newsletter. To move BRAVO files to GYPSY, nln DETRAILER  then REFORM  (both- are available on [MAXC]. There is no
documentation.
GYPSY

NEW RELEASE: DIEX . This subsystem by Roger Bates is a Diablo disk diagnostic similar in
nature to TRIEX used on the Trident. Instructions on its use~ are displayed on the screen at start-up.
(Also see MAINTAINER'S NOTES above). DIEX can be booted off of the Gateway.
NEW RELEASE: ETHERRcVR . This package, by David Boggs, is for use by diagnostic programs
that wish to exercise as many tasks as possible in attelnpting to provoke machine failure. It copies
every packet it hears into an internal buffer. The documentations is attached.
NEW RELEASE: FIRST· Bob Dattola, WRC, is releasing FIRST, a document retrieval system, for
experimental use on Altos; It accepts· English language queries (sentences, phrases, or words),

3

Whole ALTO World Newsletter
ignoring the common non-content bearing words and reducing suffix variations (stemming) of the
relnaining words. The result is then used to search against a database of abstracts, computing a
similarity function and ordering the resulting matches. It can be used to construct personal
databases or to search an existing FIRST database of Communications of the ACM article abstracts,
1970 to 1977. For details, see the attached documentation. The software and database is available
from both [XEOS]First and [WRCl as indicated.

ReReleases . Subsystems
BRAVO • Version 7.2 fixes minor bugs and supports the new printing software. Retrieve and execute
 BRAVO.cm.

DRAW· The latest release includes changes for the new printing software. Load DRA W.dm.
EMPRESS . This version incorporates changes required by the printing software. Retrieve
(Alto)EMPRESs.run. The documentation is unchanged.
NET EXEC . The 'Keys' and 'Host' commands have been combined into a single command 'FileStat'.
The change is documneted in the revised documentation NETExEC.tty. It is not
necessary to retrieve the boot file.
PREPRESS . The new version implements the new printing features and also includes a new user
interface, invoked by calling PREPRESS without parameters. Retrieve PRESsEDIT.run. Revised
documentation is available on (AltoDocs)PRESsEDIT.tty.

TECHNOLOGY
This month's paper by Terry Winograd, a member of the Sanford faculty and a consultant to Xerox,
questions our current programming methodology and suggests an alternate approach. As he states in
the abstract,
we need to shift out attention away from the detailed specification of algorithms,
towards the description of the properties of the packages and objects with which we build."
tt ...

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not
to be shown to non-Xerox people. Copies are available on [MAXC]WawNewsM-YY.press or
may be obtained from the editor, Frank Ludolph, XEOS, by messaging  or calling Intelnet 8*9234356.

4

Why Programming Languages Are Obsolete
Terry Winograd
Stanford University

Abstract
As computer technology matures, our growing ability to create large systems is leading to
basic changes in the nature of programming. Current programming language concepts are not
adequate for building and maintaining systems of the complexity called .for by the tasks we
attempt. Just as high-level languages enabled the programmer to escape from the intricacies of
a machine's order code, higher-level programming systems can provide the means to understand
and manipulate complex systems and components. In order to do this, we need to shift our
attention away from the detailed specification of algorithms, towards the description of the
properties of the packages and objects with which we build. This paper analyzes some of the
shortcomings of programming languages as they now exist, and lays out some possible directions
for future research

Introduction
Computer programming today is in a state of crisis (or, more optimistically, a state of creative
ferment). There is a growing recognition that the available programming languages are not adequate
for building computer systems. Of course, as any first year student of computation theory knows,
they are logically sufficient. But they do not deal adequately with the problems we face in our dayto-day work of programming. We get swamped by the complexity of large systems, lost in code
written by others, and mystified by the behavior of our almost debugged programs. When we look
to the integrated multi-processor systems that will soon dominate computing, the situation is even
worse.
This crisis in software production is far greater (in overall magnitude at least) than the situation
of the early 50's that led to the deve10plnent of high-level languages to relieve the burden of
"coding." The problems are harder to solve, and the costs of not solving them are in the hundreds
of millions. There are many ways to improve things a little, and they are being tried. But to
achieve a fundamental jump in our programming capacity, we need to rethink what we are doing
from the beginning.

The problem
I believe that the problem lies in an obsolete fundamental view of programming and
programming languages. A widely accepted view can be paraphrased:
The programmer's job is to design an algorithm (or a computation) for carrying out a desired
task, and to write it down as a complete and precise set of instructions for a computer to follow.
High level programming languages simplify the writing of these instructions by providing basic
building blocks for stating instructions (both control and data structures) that are at a higher
level of the logical structure of the algorithm than those of the basic machine.

2
This view has guided the development of many programming languages and systems. It served
well in the early days of computing, but in today's computational environment, it is misleading and
stultifying. It focusses attention on the wrong issues, and gives the most important aspects of
programming a second-class status. It is obsolete in the same sense that binary arithmetic is
obsolete -- the things it deals with are a necessary part of computing, but should play a subsidiary
rather than central role in our understanding of what is relevant.
As computer technology (for both software and hardware) matures, our growing ability to create
complex systems has led to two basic changes in the nature of programming. Each of them has
been hindered by the traditional idea of programming languages.
1.

The building blocks out of which systems are built are not at the level of programming
language constructs. They are complex "subsystems" or "packages," each of which is an
integrated collection of data structures, programs, and protocols.

By making use of existing modules, a programmer can deal with design at a much higher level,
creating an integrated system with capacities far greater than a program that could be built with the
same effort "from scratch." Components for general tasks (such as melnory management, user
interface, file management and network communication) can be designed once, rather than
reconstructed for each system that needs the capability. Unfortunately, in current programming
practice this is more of an ideal than a reality. The difficulties of using existing packages often make
it easier to replicate their function than to integrate them into a system. The only way such
packages are generally used is by building programs within an "operating system" that provides
facilities within a uniform enviroilment. Only those packages that are needed by the majority of
users find their way into operating systems, and the facilities for using them are complex and ad hoc
relative to Inodern programming languages.
2. The main activity of programming is not in the origination of new independent programs, but
in the integration, modification, and explanation of existing ones.

The second change grows from the first As we are able to build more complex programs, we
develop systems that grow to fit an environment of needs, rather than carrying out a single wellspecified task. A complex system (such as one for airline reservations, text preparation and
formatting, or statistical analysis) evolves over many years, increasingly coming to fit the needs of
those who use it, and adding new capacities as hardware advances make them practical.
As
additional needs and possibilities arise, it should be far easier to modify and combine existing welltested systems than to build new ones. In most cases, the needs for continuity in the use of the
system (including "upward compatibility" for existing data and user programs) make it impractical to
start from scratch. Using current programming techniques, systems often reach a point where the
accretion of changes makes their structure so baroque and opaque that further changes are
impossible, and the performance of the system is irreversibly degraded. The situation is further
complicated by the fact that modifications are often done not by the original builders, but by new
programmers with an incomplete or even wrong understanding of the system.
The difficulties in building and modifying large systems have long been recognized and
lamented. They have led to various schools of "structured programming," and to the emphasis on
restriction and discipline in the design and use of programming languages. There is a large body of
lore shared by practicing programmers, providing ways to recognize the problems and guidelines for
avoiding the most obvious of them. These include bodies of standards and conventions designed to
avoid Inisunderstanding and miscommunication. But ultimately· the solution lies not in greater

3
discipline but in more adequate tools.

Towards a solution
Just as high-level languages enabled the programmer to escape from the intricacies of a machine's
order code, higher-level programming systems can provide the means to understand and manipulate
complex systems and components. In order to do this, we need to shift our attention away from the
detailed specification of algorithms, towards the description of the properties of the packages and
objects with which we build. A new generation of programming tools will be based on the
philosophy that what we say in a programming system should be primarily declarative, not
imperative:
The fundamental use of a programming system is not to provide a set of instructions for
accomplishing a task (or carrying out an algorithm), but is to provide for the expression and
manipulation of descriptions of computational processes and the objects on which they are
carried out.

Current languages provide only scattered specialized mechanisms for description. Declarations
are a ubiquitous form of low-level description, and assertions about the state of a computation have
been proposed as a basis for automatic programming and verification. But if we look at what a
programmer would say about a program to a colleague who wanted to work on it or use it, very
little of the description appears anywhere in the "code." If (either because of idealism or coercion)
the programmer has included comments, they can provide useful, but local, description. If further
(almost always through coercion) the program has been documented, there may be more global
descriptions. In large systems, documentation will include a careful specification of protocols and
conventions not belonging to anyone progranl, but vital to the system as a whole. These various
pieces of description are scattered, and for the most part not usable except as English text to be
read. There is an increasing amount of work on "specification languages" and "structured design"
formalisms, which goes in the right direction, but these still play only a peripheral role in the normal
activity of programming and debugging.
I want to turn the situation on its head The main goal of a programming system should be
to provide a uniform framework for the information that now appears (if at alO in the
declarations, assertions, and documentation. The detailed specification of executable instructions
is a secondary activity, and the language should not be distorted to emphasize it. The system
should provide a set of tools for generating, manipulating. and integrating descriptions. The
activity thaI we think of as "writing a program" is only one part of the overall activity that the
system must support, and emphasis should be given to understanding, rather than creating
programs.

The rest of this paper explores some of the consequences of this view, and makes some
suggestions as to what a higher-level programming system might look like. It is an attempt to lay
out the problems, not to solve them. It will take many years of research before these speculations
can be backed up with concrete evidence.

A motivating example

4
One of the best ways to understand a general view of computing is to look at the examples used
by those who hold it. Knuth's opus, The Art of Computer Programming [50], begins by discussing
the Euclidean algorithm. In a clear and simple way it exemplifies the basic notions of algorithm and
program from his viewpoint. The LISP 1.5 Manual [51] includes the LISP interpreter written in LISP,
illustrating the manipulation of symbolic structures, and the ability to treat the programs themselves
as symbolic data. The view proposed in this paper is best illustrated by an example at a very
different level.
Imagine that you have come to work as a system designer and programmer for a large university.
The task you are given is:
The current situation: The university administration has a computer system for scheduling and
planning room usage. Users at several sites on campus access the system through interactive
graphics terminals that display building jloorplans as well as text and other graphic data There
is a mini-computer running each cluster of terminals, connected to the central campus facility by
a communication network. Each cluster has a device capable of printing out jloorplans and
graphic data like that displayed on the terminals. Large-scale data storage is at the central
campus computer facility.
The system keeps track of the scheduled usage of all rooms, including long-term lab and
office assignments, regular class schedules, and special events. It is able to answer questions
about current scheduled usage and availability. Querying is done from the terminals, through
structured graphic interaction (menus, standardized forms, pointing, etc.) and a limited natural
language interface. The system does not make complex abstract deductions, but can combine
information in the data base to answer questions like "Isthere a conference room for 40 people
with a projection screen available near the education building from 3 to 5 on the 27th?". Users
with appropriate authorization enter new information, including· the scheduling of room use alld
changes to the facilities (including the interactive drawing of new or modified jloorplans). In
addition to the current assignments, the system keeps a history of usage for analysis. Standard
statistical in/ormation and data representations (such as tables, bar charts, graphs, etc.) are
produced on demand for use in long-range planning.
Your assignment: The dean wants the system· to provide more help in making up the quarterly
classroom assignments. She wants to give it a description of the courses scheduled for a future
quarter and have it generate a proposed room assignment for all courses. In deciding on
assignments, the system should consider factors such 4S expected enrollment (using past data and
whatever new information is available on estimated enrollments), the proximity of rooms to the
departments and teachers involved, the preference for keeping the same location over time, and
the nature of any special equipment needed It should print out notices for each teacher,
department, dean, and building supervisor, summarizing the relevant parts of the plan. Any of
these people should be able to use the normal querying system to find out more about the plan,
including the motivations for specific decisions. Properly authorized representatives of the dean's
ofjke should be able to request changes in the plan through an interactive dialog with the
system, in which alternatives can be proposed and compared When a change is made, the
system should readjust whatever is necessary and produce new notifications for the people
affected

5
A system like this is just at the edge of our programming powers today. It would take many
programmer-years of effort to build, and would be successful only if the project were managed
extraordinarily well, even by the standards of the most advanced programming laboratories. But it is
not hard because of the intrinsic difficulty of the tasks the system must carry out. It combines
hardware and software facilities that have been demonstrated in various combinations a number of
times. Even the question-answering and assignment-proposing components are within the bounds of
techniques now considered standard in artificial intelligence.
The problem is in our power to organize systems. The integration of all of the components of
the "initial system" would be a major achievement, calling on our best design tools and
methodologies. The idea that a new programmer could come in to such a system and make changes
widespread enough to handle the "assignment" is enough to make an experienced programmer
shudder. It would be hard enough to add new types of questions (such as explanations for
decisions), new information (such as distances and estimated enrollments), and new output forms
(such as 'schedule summaries for departments). But even more, we are trying to integrate a new kind
of data (projected plans) into a system that was originally built to handle only a single current set of
room assignments and a record of their history. These projected plans must be integrated well
enough for all of the existing facilities (including floorplan drawing, question answering, statistics
gathering, etc.) to operate on them just as they do with the initial data base.
In order for any of this to be feasible, we need a uniform language across all of the different
components and data structures, in which the objects and processes of interest can be described.
This description has to be at a conceptual level that makes it possible to ignore details of
implementation whenever. possible, and to state the interconnections between objects and processes
of widely varying structure.
Three domains of description
A system of this complexity can be viewed in each of three different "domains," subject,
interaction, and implementation. -Each viewpoint is appropriate (and necessary) for understanding
some aspects of the system and inappropriate for others. We will look at the example from each of
these viewpoints in turn, then discuss how they might be embodied in a programming system.
The subject domain. This system, like every practical system, is about some subject. There is a
world of rooms and classes, times and schedules, that exists completely apart from the computer
system that talks about them. The room or the course can't be in the computer -- only a description
of it. One of the primary tasks in programming is to develop a set of descriptions .that are adequate
for talking about the objects being represented. There are descriptions for things we think of as
objects (e.g., buildings, rooms, courses, departments) and also for processes (e.g., the scheduling of
events). These descriptions are relative to the goals of the system as a whole, and embody a basic
view of the probleln. For example, what it takes to represent a room would be fundamentally
different for this system and for a system used by contractors in building construction.
All too often, the development of descriptions in this domain is confused with the specification of
data structures (which are in the domain of implementation). In deciding whether we want a course
to be associated with a single teacher, or to leave open the potential representation of team-teaching,
we are not making a data structure decision. The association of a teacher (or teachers) with a course
may be represented in many different data structures in many different components of the system.
One of the most common problems in integrating systems is that the components are based on
different decisions in. the subject domain, and therefore there is no effective way to translate the data

6
structures. A programming system needs to provide a powerful set of mechanisms for building up
and maintaining "world views" -- coherent sets of description structures in the subject domain that
are independent of any implementation. Each component can then implement part or all of this in
a way that will be consistent with both the structure of that component and the assumptions made in
other components.
A complex system like that described above will need hundreds of different categories of objects.
Some of these (such as classrooms and courses) will be unique to the system. Others (such as times
and dates, sche(~ules, physical layouts) will be shared across a wide range of systems. They will be
related into hierarchies of abstraction. We can think of a seminar, a course, and a special lecture as
examples of a rr,lOre general class of event, all having a time, a place, etc. For some purposes, this is
the right level of generality. For other purposes, we need to distinguish carefully and use special
information associated with each. A major part of building up systems will be the systematic
development of descriptions that provide a uniform medium for describing components and their
interactions.
The domain of interaction. This system, like every functioning system, can be viewed as carrying on
an interaction with its environment. As we will discuss in a moment, the choice of "system" and
"environment" is relative to a specific viewpoint, but for the moment let us consider the system as
viewed by the users. In this domain, the relevant objects are those that take part in the system's
interactions: users, files, questions and answers, forms, maps, statistical summaries and notifications
to departments.: The processes to be described are those like querying the system, describing a new
event to be s2heduled, and proposing a schedule for a new quarter.
I

.

The domain· of interaction is concerned with descriptions that are largely orthogonal to those in
the subject domain. We can talk about a question as having certain characteristics (e.g., looking for
a yes-no answer) independently of whether it is about a room or a lecture. We can talk about the
filling out of a form without reference to its specific contents. It is also (and more importantly)
independent of the domain of implementation. From the traditional viewpoint, this independence is
a bit more difficult to see than the independence of interaction and subject matter. Whereas a
subject domain object (like classroom) clearly cuts across large parts of the system, an interaction
object (like a question or the process of filling out a form) is typically handled by a single
component and .described in terms of its implementation. But for the same reasons we want to keep
subject domain descriptions independent of their implementations, we must do the same with
interaction desGriptions.
This view can be applied recursively to sub-parts and components of the system. In looking at
one part (such ~s the on-site processor and its cluster of terminals) we can view it as an independent
system interactillg with an environment including both the users and the other parts of the overall
system, such as the centralized data store. Even within a single implementation module (e.g., the
question-answerer), we often want to describe what is happening as an interaction between several
conceptual sub-;;ystems (the parser, the. semantic analyzer, etc.). As with the larger system, it is vital
to keep in mind. the distinction between the interaction domain and the implementation domain. In
order for two conceptual
subsystems to be described as interacting, they need not be implemented
I
on physically d;ifferent machines, or even in different pieces of the code. In general, anyone
viewpoint of a component includes a specification of a boundary. Behavior across the boundary is
seen in the domain of interactions, and behavior within the boundary is in the domain of
implementation.' That implementation can in turn be viewed as interaction between subcomponents.

7
It is in the domain of interaction where there is currently the most to be gained from developing
bodies of descriptive structures to be shared by system builders. There are already many pieces that
can be incorporated, including protocols (e.g., network communication protocols, graphics
representation conventions), standardized interaction facilities (e.g., ASKUSER and DLISP in Interlisp
[52, 53], the Smalltalk display programs [31]), front-end query packages (in various artificial
intelligence programs), data-base standards, and so forth. Currently each of these is in a world and
formalism of its own. Given a sufficiently flexible tool for describing and integrating interaction
packages, this level of description will be one of the basic building blocks for all systems.

The domain of implementation. Every computer system operates on a set of physical devices with
hard-wired mechanisms for for storing and manipulating data. It is in this domain that we nonnally
think of programming. The detailed choice of algorithms, data structures, and configuration is
detelmined by properties of the hardware and of the descriptive languages we have available for
specifying its behavior. However, it would be a mistake to equate this domain with our current
notions of programming. The objects in this domain include everything from individual memory
bits and subroutines to subsystems (e.g., the file system, the memory management system, the
operating system), running processes, hardware devices, and code segments. They include those
things we talk about in programs, those we talk about in the debugger, and those found in the
machine and hardware manuals. In this domain, as in the others, a uniform system for description is
needed, which is not primarily a language for specifying a set of instructions.
In addition to all those things that are directly derivable from the code, the manuals, and the
state of the machine, there is also a body of process description. For example, it may be a property
of a specific memory-management package that it periodically undergoes a garbage collection period
of up to 5 seconds during which no new memory allocations can be made. Such "performance"
characteristics may be vital for understanding the interactions of a cOlnponcnt with the rest of the
system, but are not explicit in its code. Other descriptions. bring into focus things that may be
implicit in the code. A file system may delete a file if its creation process is interrupted in certain
ways that would leave it in danger of being inconsistent. The code that does this may be distributed
through various checks and actions, but for the programmer attempting to understand the program it
is necessary to have a coherent overview of what is happening.
Similarly, many of the things we think of as properties of data structures are actually conventions
spread through the code that manipulates them. Much of the work in structured programming has
been to isolate these conventions into access functions that go into a "module" with the data
structures [29, 32, 34]. The object-oriented style of programming encouraged by Smalltalk [31] is
another attempt to provide this kind of modularity. A system for implementation description would
provide for stating these in a more general way along with those things that now appear only in the
comments. As with procedures, data structures can also have implicit properties (e.g. the expected
maximal size of variable length fields) that need to be stated explicitly in order for a person to
understand how they will interact with other components.
The boundary between hardware and software has been blurred in the past few years through
developments such as micro-code, uniform logic arrays, and the extensive use of virtual machine
architecture. A programming system based on description pushes this one step further. The
emphasis is on an overall description of a component rather than the instructions needed to cause
some piece of hardware to run it. A piece of software and a piece of hardware designed to achieve
the same purpose would have descriptions that differed in details (e.g. timing), and in the specific
aspect that described the code (or logic circuits) used to carry out the steps. They might be identical
in the domain of interaction, and even toa large degree in the domain of implementation (for

8
example in the logical description of their data structures}.

A sketch of a higher level programming system
So far, we have been talking in a general way about the different domains of description and the
kinds of things that might be said about a component or system from each of their viewpoints. This
doesn't yet provide a coherent picture of what a program will be. What do we see on the printed
page or on the screen? How is it organized? How do we do anything with it?
Once again, it is important not to let our preconceptions get in the way. Notions such as code,
listing, file, and compilation are based on the idea of a program as a set of instructions. There need
not be any directly corresponding objects in a higher-level system. Instead, it should be based on
something much more like what we now think of as an artificial intelligence system, with its
"knowledge base" of assertions and procedures. There will be a set of interrelated descriptions,
stored in a fOlTIl that makes it possible to retrieve, manipulate and display them. These will include
prototypes for categories of objects and processes (like classroom, and filling out a form), and
instances, which correspond to individual objects and processes in one of the domains (such as the
course CS 365 in Winter 1978, the contents of the third page of next quarter's schedule, and the
process currently running in the data-base server). Instances can be described by more than one
prototype, and prototypes are related into hierarchies with different degrees of abstraction. The
details of all this are still a matter for extensive research. One set of possibilities is being explored in
KRL [2,3], but the basic idea of higher level systems could be implemented using other descriptive
representations, such as semantic networks [4, 6, 10, 11, 12] and other frame based systems [5, 7].
In addition to the basic description system, there will be a wide range of commonly useful
prototypes and instances.. Some of them (e.g., graphics fonnats, dates and tnnes, comlnunication
protocols) will be in the subject and interaction domains. Others (such as the data structures used in
a particular data base) will be in the implementation domain. SOlne (such as descriptions of specific
pieces of hardware and software that are being used) will be specific to the programming system.
Others (such as those for abstract objects like sets and sequences, and for process structures) will be
very general. In approaching a problem, a programmer will make use of this vocabulary of concepts
and descriptive categolies, both for interfacing with existing components and organizing new ones.
A programmer's use of such a system will be highly interactive. Since the understanding of a
component comes from having multiple viewpoints, no single organization of the infolTIlation on a
printed page will be adequate. The programmer needs to be able to dynamically reorganize the
infolTIlation, looking from one view and then another, going from great generality down to specific
detail, and maneuvering around in the space of descliptions to view the interconnections. This will
require an interface that is more sophisticated than the question-answering interfaces now used on
artificial intelligence knowledge bases. It seems likely that pictorial representations, interactive
graphics, and "intelligent summarizing" will play a large role.
Of course, there always remains the task of providing a description of each component that is
detailed enough to allow the system to run it. This will be part of providing a broader description,
and may be done in stages. A very abstract specification of what a component does will be
sufficient for a kind of "high-level debugging" in which its interactions with other components can
be analyzed and described witll0ut carrying out the steps at the the lowest level. There is a whole
range of operations that are now thought of as "automatic programming", which will enable the
programmer to let the system fill in details once the overall behavior of the component has been
specified. Some of this will be based on standardized defaults, others on automated analysis of

9
perfonnance characteristics. It will all be based on the availability of descriptions in the
implementation domain of the various machines and subsystems being used.
As systems become more complex, the level of desirable invisibility will rise. Current high-level
prqgramming languages do not give the user the opportunity to decide just how the hardware
registers of the machine will be used to store variables, since there is much more to be gained by a
unifonn integrated approach to their use by the compiler. Similarly, much of what we now think of
as data structure and algorithm specification will be handled by programs that can take into account
much more complex efficiency considerations than are practical for a human programmer.
In summary, a programmer will use a programming system that contains a base of knowledge
about the system he or she is working on, and of other potential components and concepts of
programming that might be of use. The programmer will modify the descriptions of existing
components, and create high-level descriptions of new ones to be added. These modifications and
additions may be from the viewpoints of all of the different domains, and will be done in
cooperation with the system, which checks for consistency, looks for consequences of new
information, etc. Checking and debugging will be done at a variety of levels as the description
becomes· more detailed. The system will attempt to fill in details that are needed to completely
specify the implementation, so the system as a whole can be run. The debugging process will make
use of sophisticated reasoning processes that can use all of the different domains of description in
analyzing and reporting what is happening.
What needs to be done
To create a system like the one just described, we need further research in three distinct but
interrelated areas: the development of an effective descriptive calculus; the creation of a body of
descriptive concepts for computational processes; and the building of a complex integrated system
which uses them.
A descriptive calculus. The main thrust of these ideas depends on the ability to create and
manipulate descriptions in an effective, understandable way. There are existing fOlmalisms for
description (for example, the predicate calculus) which are clear and well-understood, but lack the
richness which makes natural description effective. They can be used as a universal basis for
description but only in the same sense that a Turing machine can express any computation. They
lack the higher-level structuring which makes it possible to manipulate descriptions at an appropriate
level of conceptual detail.
The requirements for a descriptive language of the kind I propose are quite different from those
used in the mathematical foundations of computation, or for program verification. Work in these
areas (see, for example the collection of papers in [15]) emphasizes the use of descriptive languages
in rigorous proofs of the properties of programs. A higher-level programming system must instead
emphasize the use of descriptive languages for communication. The concentration must be on those
aspects which aid in giving a person a clear overall understanding (at variable levels of detail and
from multiple points of view), rather than on those aspects which increase the mathematical
tractability of the descriptions.
There are artificial intelligence formalisms (such as semantic
networks [4, 6, 10, 11, 12] and KRL [2,3]) with increased dimensions of expressiveness, but are not
yet at a level of precision which would make them sufficiently understandable to be used in a system
of the required complexity. The characteristics which they explore (and which will need to be part
of a fonnalism to be used in a higher-level programming system) include:

10
Prototype hierarchies. The nouns and verbs of a natural language can be organized into
hierarchies (or taxonomies) which capture much of the logical stnlcture of what they describe.
We know that a dog is an animal, and the answers to questions about dogs will often be derived
through general properties of animals. Systems such as semantic networks treat these
deductions specially, rather than dealing with them uniformly as a set of universally quantified
implications. This leads to greater efficiency for the common calculations, and provides a
structure which makes it much easier for a programmer to organize a knowledge base. These
hierarchies contain infonnation which could be thought of as a set of independent facts, but has
additional structure in the same sense that a structured program structures a set of steps and
jumps.
The centrality of defaults. Most logical calculi are optimized for handling generalizations which
are either true or false. They do not provide means for stating generalizations that are not
completely universal, but are "usual" or "nonnal" or "expected". In natural descriptions of any
kind, people draw heavily on the ability to use information of a less formal sort, and to use a
kind of ceteris parabus reasoning in which a standard fact is assumed true unless there is an
explicit reason to believe the contrary. One of the major directions in artificial intelligence
representation research is the attempt to p~ovide this capability in a formally clear system. The
notion of a default value is familiar to every programmer, but its place in a fOlmal calculus
needs to be carefully worked out
The suppression of exceptional details. One of the major reasons for using precise formalizations
is that they make everything explicit. For some purposes this is good, but there are times when
understanding can come only through the suppression of detail. If we are trying to formally
describe a program which has a normally simple input-output behavior (e.g. one that copies data
from one place to another) we want to describe that behavior in a way which highlights that
simplicity. If there are exceptional cases (e.g. when the storage allocator fails to find a sufficient
block), these need to be described, but in a secondary place. The basic description of an object
cannot be cluttered up with all of the details needed for handling the contingencies.
Formalisms used in denotational semantics for programs demonstrates this problelTI well. In
order to deal with a special escape at all, they demand that even the simplest programs be
described as operating on continuations, environments, etc. and this description permeates every
level of what is said.
lYlultiple levels of abstractions and instances. In dealing with programs and processes, we run
into complexities involving the instantiation of general classes. For example, a specific
algorithm (such as Euclid's algorithm) can be thought of as an instance of a general class
(numerical algorithms), or as a class whose instances are programs implementing the algorithm.
Each of those programs is in turn both an instance (of the class of formal objects known as
programs) and a description of a class of process instances, each of which is carrying it out. If
we look at the finer structure of programs, such as the instantiation of variables or pieces of
code within loops, similar phenomena arise. Higher-order and typed logics deal in celtain ways
with the notion of a class (predicate) which is also an instance, but their austerity makes them
inadequate for capturing the rich set of ways in which people interleave levels of abstraction.
Artificial intelligence formalisms have not yet dealt adequately with these issues, which are
currently a topic of active investigation.

11
A basis for describing processes. Given a fOlmalism for descriptions in general, we need a body of
prototypes for describing those things which are common to all of our programs (e.g., processes,
programs, data structures, communication acts). This is a necessary kind of library, just as a library
of standard data-structures and statistical routines is a necessary part of a system for statistical
manipulations. It need not be fixed once and for all, but a good deal of it must be in place before
the system is usable, and it must be held relatively uniform if the system is to be extendable.
In this area, there are many ideas floating around that need to be captured in a more precise form.
The success of higher-level programming systems will depend on having a coherent body of
descriptive categories which can capture all of their variety.

Modularity and structured procedures. There has been a good deal of attention in recent years to
In addition, languages based on data
the higher-level structure of control constructs.
abstractions (such as CLU [32], Alphard [34], and Mesa [29]) provide for larger modules which
encapsulate collections of data structures and procedures. Beginning from a different point of
view, structured system description languages [16, 17] provide a body of conceptual tools for
describing the overall structure of large systems. We need a consistent way of talking about
modularization and interaction between semi-independent modules which can be applied to
system structure at all different levels of detail.
Structured data objects. Current work on programming language constructs often emphasizes
the structure of the sequence of operations, in terms of loops, recursive calls, etc [14]. A related
notion in describing processes is the ability to hide detail by allowing the combination of objects
into a larger "structured object", and to define unitary operations on this higher level object
which invoke collections of operations on the cOlnponents. This has been explored for simple
mathematical objects (e.g. lists in LISP's MAP functions [51], vectors and arrays in APL [20],
sets in SETL [26] and VERS [19]), and seems applicable to more specialized semantic objects (in
all of the three domains) as well. In many cases, much of what is now thought of as control
structure can be implicit in the data structure, leading to notions of "nonprocedural" or
"procedureless" languages [21, 22, 24]. The interaction between control and data structure needs
to be put into a theoretical framework.
Program factoring -- objects and procedures. In viewing a process as a structured sequence of
individual steps, there are different ways to think about what each of those steps is. ~Iost
programming languages lead the programmer to think in terms of operations (either primitive or
programmer-defined) to be carried out on arguments. Some (such as Simula [27], Smalltalk [31]
and Plasma [47]) think of typed objects which receive and interpret messages. Instead of
organizing code around a single procedure (e.g. print or plus) which selects its action according
to data type, they define classes (such as integer, list, etc.) which select what to do on the basis
of the message. Artificial intelligence languages take a more general approach in using pattern
directed invocation [1, 28]. Each step specifies a pattern (or goal) to be achieved. A data base
of pattern-action pairs is accessed to decide what steps to carry out. Each of these viewpoints is
best for some aspects of programming, and we need to understand how to integrate them into a
larger framework.
States and transitions. There are two complementary ways of looking at a computational
process -- as a sequence of operations, or as a sequence of states. This duality has been
exploited in the mathematical theory of computation, but has not really been integrated into
programming languages. Transition nets and Petri nets [38, 40] are state-oriented, rather than
operation-'oriented. Production systems [43] are state-oriented, with each production specifying a

12
partial state description, and an appropri~te transition function (not the name of the new state,
but a set of operations which produce the new state). Languages which provide ways of
specifying actions to be taken on special conditions [37] are really mixing state-transition
description with the normal operation sequence. As with the operation/object distinction above,
the goal is to find a synthesis which allows a process to be described using a mixture of the
conceptual viewpoints, and to be run on the basis of that description.

Interacting processes and communication. The notions above deal primarily with a single process.
The most significant direction in computing over the coming years will be towards multiple
processes, both virtual (e.g. organizing a speech system as a series of separate processes, even if
it runs on a single PDP-IO [46, 49]) and actual (e.g. networks of computers cooperating on a
single task). There are a number of issues which have been dealt with by system designers at
lower levels (like operating systems) which have not found their way into higher level languages.
There is also a wealth of metaphors provided by thinking of a computation as being carried on
by a collection of independent individuals which must communicate by exchanging messages in
a common language. We can draw many analogies from human communication -- What
language do they talk? Which subsystems need to be multi-lingual? vVhat are the discourse rules
for establishing and controlling message flow? Is it possible to learn a second language? How
can two processes make use of shared knowledge to increase the efficiency of communication?
How can one process make use of an internal model of another process, in order to facilitate
communication and cooperation?
A complex system. The kind of higher level programming system described here is itself a massive
and complex system. Its subject matter is not an external one, like room~scheduling, but the
reflective one -- the subject of programming itself. There is a bootstrapping problem. The system
needed to realize these ideas can be built only with a set of tools that help in the construction of
large integrated systems. Perhaps our current systems are good enough to start the bootstrapping,
but that first step will be a big one. It will take a good deal of careful system-organization research
before something of this scale can be effectively constructed.
Conclusion
The title of this paper is consciously provocative. Rather than asking how we might improve
programming languages, I argue that we should look at things from a completely different vantage
point in which there is little. concern with specifying programs as we now see them. It grew out of
work on description systems which emphasize concepts such as multiple viewpoints for description,
default knowledge, and prototypes. These ideas can be applied to make the rich set of programming
concepts represented in the literature more applicable to the real practice of programming. In order
to make significant progress, we need to deal with the problems of "programming in the large".
Once we begin to deal with networks of independent processors, it will become even more important
to deal explicitly with global properties that cannot be understood on the basis of individual program
instructions.
I believe that the the type of higher level programming system described here is a step hi the
right direction. There is no way to demonstrate this with certainty. As stated at the beginning; this
paper is not a presentation of a worked-out solution. All we have at this point is an intuition that a
The paper is
particular way of approaching the problem will lead to new insights and results.
intended to provoke thinking and suggest some new directions. If they tum out to be fruitful
directions, we have years, of hard and exciting work ahead.

13
Acknowledgements

In a paper of this kind, it is impossible to properly credit the sources of the ideas. It grew out of
ongoing interactions with people who hold very similar ideas in different forms, and it is really just
an expression of the current state of my intellectual environment. My joint work with Danny
Bobrow and Brian Smith on the theoretical foundations of KRL has been a primary source of ideas,
and the rest of the Stanford/Xerox KRL research group (David Levy, Mitch Model, Don Norman
and Henry Thompson) have been involved in all stages of our thinking. Stanford computer science
students in the CS365 seminar in 1977 pushed and probed on many of the ideas about procedures,
which in turn came from the authors of the papers we read there (included in the list of references).
The Xerox PARC environment has been a context in which the problems of "programming in the
large" are well understood, and has provided a wealth of ideas and examples, including the work of
Alan Kay and his group on Smalltalk, the implementation of the Mesa programming language, the
development of programming environments by Warren Teitelman and Larry Masinter, Bob Sproull's
understanding of graphics systems and protocols, and Peter Deutsch's views on system organization
and programming environments. In addition, the cybernetic notions of Humberto Maturana as
introduced to me by Fernando Flores have led to subtle but very important shifts of perspective in
the way I look at systems of all kinds. I am also grateful to Allen Perlis, Peter Deutsch and Jim
Homing for extensive and insightful comments on an earlier draft of this paper.
References

Note for the draft version: This reference list is still somewhat rough. It contains all the
references from the Stanford seminar mentioned in the last section, along with others mentioned in
this paper. It may be better to make it more selective, so I have not bothered to clean it up totally,
but will wait for commen1s first. My idea in including it was that it gives a broad picture of the
kinds of issues which need to be taken into account. I am a liule worried that it is so broad as to
be overwhelming. It is also somewhat idiosyncratic, since it consists of papers that I was familiar
with. I welcome suggestions of additional papers or substitutes on all of the topics.
Description Formalisms

[1] Daniel Bobrow and Bertratn Raphael, "New programming languages for AI Research",
Computing Surveys 6:3 (September 1974).'
[2] Daniel Bobrow and Terry Winograd, An Overview of KRL, a Knowledge Representation
Language, Cognitive Science 1:1, January 1977, pp. 3-46.
[3] Daniel Bobrow, Terry Winograd, and the KRL research group, Experience with KRL-O: One
cycle of a Knowledge Representation Language, Fifth International Joint Conference on
Artificial Intelligence, pp. 223-227.
[4] Ron Brachman, What's in a concept: Structural foundations for semantic networks, Int. J.
Man-Machine Studies (1977) 9, pp. 127-152.
[5] Randy Davis, Knowledge about representations as a basis for system construction and
maintenance, in Pattern Directed Inference Systems, Academic Press (in press).

14
[6] Richard Fikes and Gary Hendrix, A network-based knowledge representation and its natural
deduction system, Fifth International Joint Conference on Artificial Intelligence, pp. 235-246.
[7] Ira Goldstein and Bruce Roberts, Nudge, a knowledge-based scheduling program, MIT AIMEMO 405 (February 1977).
[8] Pat Hayes, Some problems and non-problems in representation theory, AISB conference,
1974, pp. 63-79.
[9] Pat Hayes, In Defence of Logic, Fifth International Joint Conference on Artificial Intelligence,
pp. 559-565.
[10] Hector Levesque, A procedural approach to semantic networks, TR-105 Dept, of Computer
Science, U. of Toronto, 1977.
[11] David Rumelhart and Donald Norman, The Active Structural Network (Chapter 2) from
Explorations in Cognition, 1975.
[12] Bill Woods, "What's in a link?", in Bobrow and Collins (eds.) Representation and
Understanding, 1975.
Formalisms for specifying programs

[13] Burstall, R.M. and Goguen, lA., Putting Specifications Together, 5IJCAI, 1977.
[14] Edsger Dijsktra, A Discipline of Programming, Prentice Hall, 1976.
[15] EJ. Neuhold (ed.), Formal Description of Programming Languages, North-Holland, 1978.
[16] Kenneth T. Orr, Structured Systems Development, Yourdon Press, 1978
[17] Douglas Ross, Structured Analysis Design Technique, ????
[18] R.D. Tennent, "The Denotation,!l Semantics of Programming Languages", CACM, August
1976, pp. 437-453.
Structured objects and structured procedures

[19] Jay Earley, High Level Operations in Automatic Programming, SIGPLAN notices 9:4 (1974),
pp. 34-42.
[20] A.D. Falkoff and K.E. Iverson, The design of APL, IBM Journal of Research and
Development, 1973, pp. 324-334.
[21] Clair Goldsmith, The design of a procedureless programming language, SIGPLAN notices
9:4 (1974), pp. 13-24.

15
[22] Hammer, Howe, and Wladawsky, an Interactive Business Definition System SIGPLAN
notices 9:4 (1974), pp. 25-33.
[23] Robert Kowalski, Predicate Calculus as a programming language, IFIP proceedings, 1975.
[24] Burt Leavenworth. and Jean Sammet, An Overview of nonprocedural languages, SIGPLAN
notices 9:4 (1974), pp. 1-12.
[25] John Reynolds, GEDANKEN--A Simple typeless language based on the principles of
completeness and the reference concept, CACM 13:5 (May 1970), pp. 308-319.
[26] Jacob Schwartz, On Programming: an interim report on the SETL project; Installment I:
Generalities, NYU Courant Institute, February 1973.
Program factoring -- modules, objects, and procedures
[27] Birtwistle, Dahl, Myhrhaug and Nygaard, SIMULA BEGIN, 1973.
[28] Randy Davis, Generalized procedure calling and content directed invocation, Proc. ACM
Conference on AI and Programming Languages, August 1977.
[29] Charles M. Geschke, James H. Morris Jr., and Edwin H. Satterthwaite, Early Experience
with Mesa, CACM 20:8 (August 1977), pp. 540-552.
[30] Chuck Geschke and Jim Mitchell, On the problem of uniform references to data structures,
Xerox PARC CSL-75-1, January 1975.
[31] Adele Goldberg and Alan Kay, Smalltalk-72 Instruction Manual, Xerox PARC SSL 76-6,
1976.
[32] Barbara Liskov, Alan Snyder, Russell Atkinson, and Craig Schaffert, Abstraction Mechanisms
in CLU, CACA-f 20:8 (August 1977), pp. 564-576.
[33] Vaughn Pratt, The Competence/Performance dichotomy in programming, 4th ACM
synlposium on the principles of programming languages, 1977, pp. 194-200.
[34] Mary Shaw, William A. Wulf, and Ralph L. London, Abstraction and verification in
Alphard: Defining and specifying iteration and generators, CAClvl 20:8 (August 1977), pp.
553-562.
[35] Guy Steele, LAMBOA, the ultimate imperative, MIT-AI Memo 353, March 1976.
[36] Guy Steele, LAMBDA, the ultimate declarative, MIT-AI :tv1emo 379, November 1976.
States and transitions
[37] John Goodenough, Exception Handling: Issues and a proposed notation, CACM 18:12,
December 1975, pp~ 683~696;

16
[38] Anatot Holt, Introduction to Occurrence Systems, in Jacks (ed.) Associative Information
Techniques, Elsevier 1971. pp. 175-203.
[39] E. Humby, Programs from Decision Tables, McDonald/Elsevier, 1973.
[40] P.E. Lauer and R.H. Campbell, A Description· of path expressions by Petri Nets, Second
ACM symposium on principles of programming languages, 1975, pp. 95-105.
[41] Howard Lee Morgan, Event Sequenced Programming, Cornell Dept. of operations research
Tech report 119 (July 1970).
[42] Chuck Reiger, "The Commonsense algorithm as a Basis for Computer Models of Human
Memory, Inference, Belief and Contextual Language Comprehension", Schank and NashWebber (eds.), Theoretical Issues in Natural Language Processing, 1976. pp. 180-195.
[43] Mike Rychener, Production Systems: a case for simplicity in AI Control Structures, draft of
paper submitted to ACM National Conference, 1977.
[44] Earl Sacerdoti, The non-linear nature of plans, 4IJCAI, pp. 206-214.
[45] Michael Zisman, A Representation for Office Processes, Wharton Department of Decision
Sciences Working paper 76-10-03.
Interacting processes and conununication
[46] Jeff Barnett, Module linkage and communication in large systems, in D.R. Reddy (cd.)
Speech Recognition, pp. 500-520.
[47] Carl Hewitt, Viewing control structures as patterns of passing messages, MIT AI Memo 410
Dec. 1976.
[48] Lampson, Mitchell and Satterthwaite, On the transfer of control between processes,
Proceedings of Programming Symposium, Paris, April 1974 (# 19 in Lecture notes in
Computer Science, Springer Verlag, 1974), pp. 181-203.
[49] Victor Lesser, Parallel processing in speech understanding systems: A Survey of design
problems, in Reddy (ed.) Speech Recognition, 1975, pp. 481-499.

Other references
[50] Donald Knuth, The Art of Computer Programming. Vol 1, Fundamental Algorithms, Addison
/
Wesley, 1968.
[51] M. Levin, et. al., The Lisp 1.5 Programmer's Manual, MIT, 1965.
[52] Warren Teitelman, A display oriented programmer's assistant, Fifth International Joint
Conference on Artificial Intelligence, 1977, pp. 905-915

17
[53] Warren Teitelman, et. al., Interlisp Reference lvlanual, Xerox PARe, 1975.

XEROX
BUSINESS SYSTEMS
Systems Development Division

To

Software Distributers

Date

June 12, 1978

From

Bruce Malasky

Location

EI-Segundo

Subject

Brownie 1.0

Organization

SDD/SD

A Program for Maintaining Consistent Distribution Directories

Filed on: [Ifs-2]memos> Brownie.memo

Overview
This memo describes a program for maintaining public distribution directories on a file
server. As the number of users has increased and the slow speed communication lines have
become more heavily utilized, it has become very important to provide easy access to public
software. To this end lnany local IFS's now have their own versions of important
directories such as , Brownie>Brownie.Image. For
a while, I recommend that you run it with a disk that has the Mesa debugger installed.
Since files being transfered will reside on the local disk (in Brownie.buffer$), it is important
to have a disk with about 2000 free pages.

Operation
Brownie is started in the same manner as any image file. NOTE: Brownie is currently a Mesa 3.0
During initialization, Brownie looks for a
file called Brownie.data on the local disk that describes the operations to be performed.
Appendix A contains a sample data file and an explanation of its format.
program. Be sure to use RunMcsa.run from (OLDMESA).

How it 'Yorks
Brownie works by first enumerating files on both the source and destination hosts. Since
the IFS software does not distinguish between empty and non-existant directories, there is a
requirement for at least one file in the lowest subdirectory specified. In the example on the next
page, if Brownie was asked to update [Hostl]. This requirement may change in
the future. After the enumerations, Brownie then compares the write dates of files with the

satne name to determine, which: files require transferring. Files on the [source host] but not

2
the [destination host] will be tranferred. If there are communication problems, Brownie
automatically reopens timed out connections.
Filemunes are compared without version numbers and with case ignored. However, any
subdirectories not specified in the command line will be used as part of the name for
comparison. When updating [Hostl]foo> from [Host2]foo>, the file
B.mesa will be transferred only if it's newer on Host2. The file a.mesa will be transferred
regardless of its write date because it is not on the Hostl. This will result in one version of
a.mesa in the Foo>Bar> subdirectory and one in the Foo> subdirectory.
[Hostl]
Foo>
Bar>
A.mesa!l
Bas>
B.mesa!4
BaZ>

[Host2]
Foo>
a.mesa!2
Bas>
B.mesa!3
BaZ>
a.bcd!!
b.bcd!2

Planned Enhancements
In the future, Brownie will permit you to add your own module that will be able to fiddle
with the files as they are transferred. This feature was motivated by the desire to alter
command files automatically to use the new host.
The use of the local disk for buffering files will probably be removed at the time Brownie
is converted to Mesa 4.0.
Brownie will optionally rename files on the same host. This will result in an enormous
performance enhancement for rearranging directories on a single host.

Problem Reporting
All problems should be reported to Bruce  (823-1469) or using sndmsg.

3

Appendix A
Below is a sample brownie. data and an explanation of its format:
{brief}
/ / log ins follow
[Ifs-2](secret)
[Iris](guest)
[Maxc] (mumble) ~ [Maxc]30) (bar) +- [Maxc]

All the remaining lines in the data file are command lines specifying what updates to
perform. Each command line is in this format:

<

[Destination]< directory>sF(connect password)SP" sF[ Source] directory) sF(connect password)CR

where Sp is a space and CR is a carriage return. No *'s are permitted in any of the directory·
specifications. Subdirectories for first.dm on WRC IFS
FIRST is a document retrieval system based on the SMART system developed by O. Salton of
Cornell University. It accepts natural, English language queries (sentences phrases or words), and
passes the words through a stemming algorithm that ignores STOP words (very common noncontent bearing words) and reduces suffix variations of the remaining words. The query is then
searched against a data base of abstracts by computing a similarity function between the query and
abstracts. Abstracts containing at least one common stem with the query are returned to the user in
decreasing order of score, as determined by the similarity function. Thus, those documents most
similar to the query (and hopefully most relevant) are output first. For more information on
FIRST, see "FIRST -- Flexible Information Retrieval System for Text," Xerox Internal Report No.
X76-00221 Dec. 1975 by R.T.Dattola.
t

t

t

The file first.dm is a dump file containing all the necessary files for creating and searching a FIRST
data base. It consists of the three programs FirstInit DocLoad and First, the two files STOP. first
and Suffix.first, and a copy of this documentation first.doc.
These programs are still considered to be experimental, so they are not being officially released as
Alto Subsystems. Any problems and/or suggestions should be reported to me on Maxc account
ISA.

Creating a FIRST Data Base
A FIRST data base consists of the following, four files:
DocAbs.first -- Text of abstracts used for printing.
DocMat.first -- Weighted numeric vectors (one for each
abstract) used for searching against query.
BF Atree.first -- A B-tree used for storing all the unique
content bearing stems in the data base.
Auxtree.first -- A B-tree used for storing STOP words and suffixes.

2

These files are automatically initialized by running the program FirstInit. This program prompts
the user for the following information:
Data base name -- One line of text which is displayed
when searching.
Maximum document number -- The largest total number of
documents to ever be stored in the data base.
STOP word file -- The name of a file containing all the
words to be treated as STOP words. The words need not
be in any special order, but they must be separated by
spaces or carriage retunlS. A standard STOP word
list STOP.first is provided in first.dm.
Suffix file -- The name of a file containing all the
English suffixes to be used by the stemming
algorithm. Same format as for STOP word file.
A standard suffix list Suffix. first is provided
in first.dm.
After running FirstInit, documents may be added to the data base by running DocLoad. At this
time, input documents must conform to the following format requirements:
Date, if present, must be the first string of characters in the document
(except for blanks or control characters), and
date must be entered as MM/YR or MM/DD/YR.
If no valid date is found, the date the document is loaded is used.
Next comes text, which may contain bravo paragraph
information (which is ignored). However, documents
must contain less than 4,000 bytes. Additional characters
are ignored and a warning message is output.
Documents must end with the symbol # followed immediately by
CR (not control CR).
The DocLoad program might Swat if data does not conform to the above requirements. In· this
case, the integrity of the four FIRST files cannot be guaranteed. Therefore, the FIRST files should
be backed up before updating. Any messages output to the display during DocLoad are saved in
the file DocLoadLog.first.
The time needed to load documents depends on the length of the document, but a typical 200 word
abstract might require about 1.5 minutes. In the beginning when the B-tree is very small,
documents will load much faster.
Currently, data bases must reside on the operating system disk, running on either a Diablo rIlodel
31 or model 44 disk drive. Only one FIRST data base is allowed per disk. The total space needed
for a FIRST data base is approximately twice as large as the raw input text.

3

Searching a FIRST Data base
The program First is used to search a FIRST data base. All user inputs must be terminated by
escape. FIRST prompts the user for a query and a date or date range. If a single date is entered
(MM/YR), only documents from that date forward will be retrieved. If two dates are entered
(separated by one or more spaces), only documents from within that range of dates (inclusively) will
be retrieved.
The query is then processed by the stemming algorithm exactly as documents were processed when
added to the data base. Any query words not found in the B-tree dictionary are indicated. Neither
these words nor any suffix variations of them occur in any documents, so they do not contibute to
the retrieval of any documents. If the user is satisfied with the query, "y" is typed (followed by
escape) in response to the prompt "OK to search?".
The system then indicates the number of documents which satisfy the date specification and have a
non-zero similarity score with the query. The output window is used to display the document-query
score for all retrieved documents. All scores are between 0 and 1, with a higher score indicating
greater similarity. The user can scroll this window (see next paragraph for discription of scrolling)
to view all the scores in order to determine a cutoff point for displaying documents. After entering
escape to stop scrolling, the user is then prompted for the number of documents to be output.
Documents are output using a scrolling package which allows some control over display of
documents. The left (red) mouse button can be used to scroll the display forward; e.g., holding
down the button scrolls the display forward, and releasing it stops the scrolling. The middle
(yellow) mouse button operates like the yellow "bookmark" button in Bravo. The right (blue)
button has no effect. When the user is finished looking at retrieved documents, escape allows
another query to be entered. However, entering a new query will destroy the output file for the
previous query (see below).
Any documents which the user requested to have printed are output on the file Scratchfile.first,
whether or not they were actually viewed on the screen. Hard copies of this file nlay be obtained
using Bravo or any other program accepting text files. However, this file is deleted the next time
First is executed.
A FIRST data base consisting of abstracts, keywords, and bibliographic information from the
Communications of the ACM (1970-1977) is available for searching using First. In addition to
First.run, the follOWing files must be retrieved from Ivy station WRC:
DocAbs.first -- 1902 pages
 DocMat.first -- 622 pages
 BF Atree.first -- 692 pages
 Auxtree.first -- 32 pages
Total -- 3248 pages
Since some of the files are so large, users outside of Webster should retrieve the files during offpeak hours.

WHOLE ALTO WORLD NEWSLETTER
SUBSCRIPTION RENEWAL FORM
NAME

MAIL STOP

ORGANIZATION_________________________________________________
What do you use the Alto for?

What sections of the Newletter do you usually read?

What sections of the Newsletter do you seldom read?

What additional topicS would you like to have included?

RETURN TO:

Frank Ludolph, PARC

(Internal mail)

or

c/o Xerox Research Center
PaloAlto, Ca. 94304

(U.S. Mail)

or Message:

< Ludolph>

Whole ALTO World Newsletter
Technology and Tools

XEROX

July 31, 1978

SPECIAL ANNOUNCEMENTS
NEW WHOLE ALTO WORLD CHAIRMAN NOMINATED - Jim Iverson of the Webster
Research Center has been nominated to succeed Liz Bond as chairman of the Whole Alto W orId. A
special committee, appointed at the last WAW meeting for this purpose, met in late June to discuss
potential candidates. They selected Jim based on his active participation, energy, and expressed
desire to continue and expand the activities of the Whole Alto WorId. The committee's
recommendation will be presented for ratification at the next W AW meeting in October.

GENERAL NOTES
ALTO NETWORK EXPANDS . Xerox Computer Services in Los Angeles and the Office Systems
Division in Dallas are joining the· Alto network. XCS became an operational member this month.
They are connected through the ASD/EI Segundo Gateway (a map of the current network is
attached to the Newsletter). XCS has two machines at this time and will be doing some MESA
programming in conjunction with SDD.
OSD will be come up this month. They will operate over part of the bandwith of an already
existing line to WRC. Dallas currently has three machines, two of which are used by OSD for
human factors work and one by DSD for design.
SUBSCRIPTION RENEWAL RESPONSE . Thank you all for the strong response. Some good
suggestions were received as to how the Newsletter might be expanded. They will be reviewed
during the next month along with a discussion in the August edition of the more popular requests.
An immediate result is the addition of a new section, MARKET PLACE. Several people indicated
on their subscription renewal that they would like some sort of "want ads" for software and/or
hardware. So beginning with this issue, MARKET PLACE becomes a regular section.

MARKET PLACE
Market Place provides a forum for Alto users to make offerings and· requests for Alto related
hardware and software. To place an "ad", send the text to the coordinator, Frank Ludolph (PARC),
message .

Whole ALTO World Newsletter
TOOLS
HARDWARE
DOVER II AND SPRUCE - The Dovers built by spa have some minor engineering changes that
slightly alters their interface characteristics. Old versions of SPRUCE will not drive Dover lIs
properly (the first page images on the drum but paper does not feed). Newer versions of SPRUCE (7
and 8) will operate properly with both old and new Dovers. Coupled with the recent font and Press
changes, it is recommended that all sites use version 8 of SPRUCE (check the output break page for
the version number).

MAINTENANCE NOTES
BEWARE OF RF SOURCES - No one loves an arc welder. One such machine has disrupted
digital and video activities at the PARC facilities inspite of a couple of moves. Electrical arcing can
produce a large amount of energy throughout the radio frequency spectrum. Alto related symptoms
are disk read/write errors on Diablo and Trident drives. Model 31s shielded within the Alto case
have not experienced problems. However, external drives, as in dual-drive systems, must be
grounded to the Alto chassis in the presence of heavy RF otherwise write operations may return
'not-ready' yet still write garbage. The Trident doesn't fare as well. Its symptoms, randorn checksum
errors on reads, can be reduced but not eliminated by using an earth ground. In neither drive does
the metal case provide adequate sheilding.
To test for excessive RF energy, lay a long (15 foot) wire across the floor and attach it to a scope
input. Interference problems have been encountered starting at about the 1 volt level. Frequency
sensitivity has not been measured.
Other RF sources have been recorded including PUP Ethernet transmissions (.2 volts), the display's
fly-back transformer (a 40 p-sec pulse), and display switching through a multiplexer (1 volt). The
display related pulses have caused disk errors (watch the screen of an Alto running 1'RIEX on a
Trident for error messages).

SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available from your
local IVY server under the directories  and . If they are not available, or if
you are in doubt as to the version, they may be retrieved from [MAXCl (same directories). Files
stored under other directories are on [MAXC] unless otherwise indicated, e.g. [XEOS].
PUP PROTOCOL DOCUMENTATION - In keeping with the spread of Spruce printers and the
demise of Ears; Ed Taft recently converted PUP protocol documents from Pub format files to Bravo
format and regenerated all Press files using the new fonts. Most importantly, the ·documents
themselves were updated. They are available from [MAXC].
IFS or Ivy . Some time ago it was decided to rename the IFS file server software to Ivy. However,
since the name IFS is so pervasive in the documentation and folklore, Ivy never caught on and its
use only caused confusion. Whole Alto World documents will, from now on, use 'IFS' to mean the
system software and 'IVY' to indicate the file server at PARCo
NEW RELEASE: ERL • Tom Moran of PARC and George Robertson of Carnegie-Mellon have
produced a new general programming system on the Alto based on Alto L*. It was designed for

2

Whole ALTO World Newsletter
running small user interface and user performance experiments which require real-time control with
no unpredictable system events (e.g. page-swapping or garbage collection). ERL is a list-structured
language with homogeneous program and data representations with easy-to-use programming
facilities for graphics and interrupts. The ERL system runs entirely within memory (it is interpretive
and moderately fast), and offers facilities for debugging, editing, and filing programs.
Documentation can be retrieved from [MAXC]Menu-News.bravo. Revised documentation is on Menu.bravo.

TECHNOLOGY
It is well known to Alto users that Xerox is interested in developing Office Information Systems.

Important in the success of this effort is a broad awareness of the behavioral effects the installation
of an OIS is likely to entail. The first paper, "Behavioral Implications of Office Information
Systems", describes the different ways OIS can impact client organizations. The second paper,
"Some Considerations for Office Technology", reports on observations made in a working office
from three different perspectives and analyses the potential effects of OIS on the office's operation.

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not
to be shown to non-Xerox people. Copies are available on [MAXC] about changes

For XEROX internal use only

Whole ALTO World Newsletter
Technology and Tools

XEROX

August 31,1978

SPECIAL ANNOUNCEMENTS
WHOLE ALTO 'VORLD MEETING· The next meeting will be held Tuesday, October 17th, from
9 am to 3:30 pm at the Webster Research Center, Webster, New York. Jim Iverson, ISA, and
Darwin Newton, Ginn, are our hosts. This is the first meeting to be held on the east coast, so come
back and have a look around. For those of you unfamiliar with the area, suggested accomodations
are the Depot in Webster, The Sheraton and Marriot at the airport (both have large indoor pools),
and the Americana and Holiday Inn in Rochester.
WAW COORDINATOR MOVES TO NEW LOCATION - Frank Ludolph, the WAW coordinator,
has moved to the Hanover building in Palo Alto. He can now be reached at ·Intelnet 8*923-4652.
Mail should still be addressed to PARCo The move results from Frank's assumption of additional
duties with User Support Services in ASD, a role complementary to that of coordinator.

GENERAL NOTES
WASHINGTON PROBE NEWS ITEMS . Several articles have appeared recently about the ASD
Washington probe. They are in Datamation (Aug. pp. 54-55), Typeworld (Aug. p. 4), and the Wall
Street Journal (Aug. 15 p. 4). (Copywrite laws prohibit their inclusion here.) In general, they
describe the equipment - not· wholly accurate - and comment on the future of such systems. These
are not Xerox cleared releases so you should neither confirm nor expand upon their content.
ALTO DLS/TELENET LINK - The Alto Data Line Scanner has recently been connected to the
Telenet Corporation's digital data network. This connection, which suppliments Intelnet or direct
dialing, enables users with a terminal such as a TI 7xx to couple into the PUP network from the
many places in the world where Telcnet now offers services. (Local Palo Alto users should continue
to use 493-3121 rather than the Telenet Tip in San Carlos.) The most typical use of the service is to
access MAXC to send and receive mail.
ASD is graciously paying the fixed cost for this service (about $700/mo). The connection charges
(about $7/hr) are to be paid by each user organization (based on organization name/password use)
via a transfer agreement with PARCo Detailed usage, i.e. individual/time, of the Intelnet variety is
not available. (Direct dial and Intelnet coast-to':'coast connection costs $20 to $25/hr. and is of lower
quality.)
If your organization would like to use this service, Ted Strollo suggests that you contact the
indicated member of your organization: Jim anderson, XCS; Ron Rider, PD; Carlos Santiago, GSD;
Dick Sonderegger, SDD; Don Stewart, XEOS; or Chuck Thacker, ED. (ASD, PARC, and WRC
are/will be users.)
NEW ALTO NET\VORK ADMINISTRATOR ~ Tim Carroll of RTCC in Webster will soon be
assuming control of the network~ Tim is looking for a person to be the network wizard to handle
both technical and administrative matters. This person will handle the network topology, Gateway
boot file updates, name server directory maintenance, network troubleshooting, new site installation,
and common carrier interfacing; The position is in Webster with heavy PARC travel initially. If you
know of someone suitable~ call11im at 8*222-2100 or message  and . If they are not available, or if
you are in doubt as to the version, they may be retrieved from [MAXC] (same directories). Files
stored under other directories are on [MAXC] unless otherwise indicated, e.g. [XEOS].
NEW RELEASE: DYNLDR - This package is used to customize a program at runtime by
dynamically loading a BCPL .br file. Documentation on its use will be available soon. Retrieve
DYNLDR.br
NEW RELEASE: POppy - Poppy is an on-line documentation system that supports indexing and
automated definition look-Up. It is a MESA 4.0 program so it should not be loaded onto a disk
containing LAUREL l.x. The documentation is self-contained; just start up POppy and bug HELP.
Retrieve and execute [IVy]GetPoppyImageEtc.cm.

New Documentation
BCA/MLDR . Basic Cross-Assembler is a general purpose microcomputer assembler. To date it has
been used to assemble code for several microcomputers: Intel 4040, 8080, 8748 and 8086, Motorola
6800, MOS Technology 6502, Texas Instruments TMSIOO, and Zilog Z-80. It takes about a day's
work to customize BCA for a new machine with an 8 bit instruction and only a few unusual
features. MLDR combines several BCA produced files to produce one standard Micro format binary
file. Retrieve BcA.press.
F ANCyTEMPLATE . This package is an enhanced version to the TEMPLATE package that formats
output to a stream according to a template. The enhacements include hexadecimal output and a
prOVlSlOn for a user-supplied routine to format non-standard data types. See
 F ANCYTEMPLATE.tty.
MICRO - MICRO is a machine-independent microassembler originally developed for Maxcl and
since used for Maxc2, Dorado, and DO as well as for several smaller projects. It does have a specific
target machine; rather it has a general facility for defining fields and memories, a standard stringoriented macro capability, and a parsing algorithm that allows setting fields in memory. The
document is of interest primarily to someone who will define a new assembly language for a
machine. Retrieve (AltoDocs>MIcRo.press.

MESA TOOLS GUIDE . The Tools Environment Guide for Uool Users is now available on
[IRIS]Alpha>DocUlnentation)ToolsUserGuidel.press and ToolsUserGuide2.press.

ReReleases . Subsystems
ANALYSE· In addition to bug fixes one new feature has been added; when using the "titleblock"
facilities, Sit drawings may now be included for use as reference and not be analysed. retrieve
[IVY]ANALYSE.run. Updated documentation is in the SIL Manual.

BUILD - The new version invokes the hardcopy feature in SIL rather than NpPR. Retrieve
[Ivy]BuILD.run. The documentation in the SIL Manual has not been updated.

3

For XEROX internal use only

Whole ALTO World Newsletter
HARDCOPY - In addition to retrieving files from a server and invoking BRAVO to hardcopy them,
HARDCOPY will now also EMPRESS press files. Both the .run file and the User.cm slice have
changed. Load HARDCOPY.dm and install in accordance with the updated documentation
 HARDCOPY. tty.
MICRO • This release fixes all known gliches and improves throughput by 20-25%. Retrieve
MICRO.run. A new manual is on MlcRO.press.
PNEW/PROM - PROM now has the same switches as PNEW. Additional proms have been added to
PNEW. Old command lines still function properly. Retrieve  PROM.run and/or PNEW.run.
Revised documentation for these prom fusing programs is on PromManua1.run.
SIL - SIL has had both a major and bug fix releases since the last Newsletter. New features include
a hardcopy mode (similar in concept to BRAVO'S Look Hardcopy), font faces (bold and italic), and
direct hardcopy output. NGPR and NpPR are now obsolete. Retrieve [IVY]SIL.run (a
[MAXC]
copy
has
been
requested).
The
revised
documentation
is
on
[MAXC]SILManual.press.

RcRcleases • Packages
MESALIB - MESA 3. items are now in  on IRIS and ISIS.  contains
MESA 4. packages. Summary.press contains thumbnail descriptions of the available packages.

TECHNOLOGY
A natural use of OIS is the storage and retrieval of personal information, i.e. information primarily
of interest to the person who puts it in. Richard Sauvain, WRC, has had an interest in and been a
user of such systems for a number of years. His paper, Computer-Based Personal Retrieval Systems,
provides some background information and a topically organized, annotated bibliography on this
subject.

The Whole Alto World Newsletter is a monthly publication for Xerox employees that use the Alto. It is not to be
shown to non-Xerox people.
Copies are available on [MAXC]WawNewsM-YY.press or may be
obtained from the editor, Frank Ludolph, ASD, by messaging  or calling Intelnet 8*923-4652.

4

Computer-based Personal Retrieval Systems
by
Richard W. Sauvain
Xerox Corporation
Webster Research Center
Information Sciences Area

August 24, 1978

Abstract: This is an annotated bibliography on "personal" information storage and
retrieval systems. It catalogs work done to date on computer based retrieval systems
in which the input is selected or indexed by the end user of the information. The
bibliography is preceded by a short commentary defining further the meaning of
"personal", describing the history of the area, and taking a brief look at the state-ofthe-art and currently important research areas.

DRAFT
This is to be issued as internal report X7S-02533; I also plan to be submit it for outside publication.
Critical comment is welcome; I can be reached at IntelNet 8*222*5298, or at account ISA with SndMsgl

2

Introduction

Techniques for organizing one's personal store of written material have long been of
interest to information workers. Almost everyone doing research, record keeping, or
analytical work builds a collection of notes, records, letters, memoranda, papers, and the
like. In time, such collections get sufficiently large that it is hard to retrieve information.
This motivates development of some sort of organization scheme to facilitate retrieval.
Retrieval effectiveness tends to fluctuate, improving with the addition of new techniques,
and worsening as the collection grows.
Computers have been used to facilitate retrieval in personal collections roughly since the
mid-60's, when computer resources began to get cheap enough to make personal
applications feasible. Work accelerated with the spread of time-sharing and minicomputers, and the recent rapid increase in availability of microcomputer-based personal
computers promises to bring a new surge of interest in personal information retrieval.
This paper catalogs work done to date on computer-based personal information retrieval
systems.
These are defined as retrieval systems in which the input is selected,
keystroked, or indexed by the end user of the information, and in which the collection is
organized to match the individual's own approach to the subject matter. Note that this
definition does not cover large general purpose retrieval systems (e.g. commercial
search software or large library systems), unless they are used for a personal
application. A few papers on manual systems and indexing practice are included for
completeness. General purpose retrieval software operating on micro-computers is
covered (since it is likely to be used to develop personal systems).
Some Notes on the Restriction to Personal Systems

The term "personal" connotes (in this paper) that the the end user of the information is
the same person as the one who puts it in. Though generally single user, personal databases are
occasionally shared by a small group of people who share a common conceptual framework.
This
'putting in' activity may be regarded, more concretely, as imposition of some kind of
retrieval-facilitating structure on a specialized body of information -- of moderate size
(generally not more than one or two megabytes).
An important aspect of personal retrieval systems is that the end user generally does
not want to rely upon anyone else's index terms. The motivation for building a personal
database is usually that personal indexing or organization must be performed to make the
stored information truly useful. In other words, a large part of the usefulness of a
personal database is that the information has been evaluated by the collector relative to
a personal conceptual framework. This is in contrast to large, 'public' retrieval systems,
where the diverse nature of the audience makes it necessary to rely on 'general
purpose' indexing.
Personal systems are of interest for at least three reasons. First, most information
gathering - especially in scientific or analytic work - is done in one's own collection.
Libraries and even colleagues are used far less often. Secondly, these systems pose
interesting requirements for accommodation to personal conceptual frameworks, for
customization, and for accessibility - they have to be available very quickly when the
need for the information is at hand. Thirdly, the age of personal hardware is upon us .software to make good use of it is urgently needed.

3
Roots
Computer-assisted personal information retrieval systems have their roots in many
areas: manual systems, simple reference listing programs, retrieval facilities in document
preparation systems, large bibliographic retrieval systems, and the more general area of
'information work'.
Most people approach information organization and retrieval by setting up some sort
of manual system. This might be a filing cabinet - perhaps ordered by author name, or a
subject file of 3x 5 cards, or a more elaborate systems involving edge-notched cards
'with coincidence of holes indicating subject classes. There is a great body of advice
available on how to set up manual filing 'systems, and on how to index their entries (see
for example [Jahoda 1970]). Note: throughout this paper, references formed from the first author's
last name and the year of publication will be used.
provide a brief mnemonic, reference symbol.

The intent is not to ignore co-authors, but rather to

The first substantial use of, computers in the personal database area was to maintain
lists of bibliographic references. [Burton 1969, Heaps 1968, Smith 1969, Wallace 1966,
Yerke 1969, and Yerke 1970] are examples. An 'information worker' would typically
have author, title, location, and some form of subject descriptors keypunched for
references in some specialized area of knowledge. The computer would then be used to
produce listings sorted by author or subject, or in some cases to produce KWOC indices
from the titles.
Some minimal editing or file updating facilities were available.
At about the same time, computers began to be applied to document preparation and
text analysis. Pre-cursors of modern word-processing systems began to deal with the
problems of filing and retrieving documents under preparation. This included the idea of
using the computer to assist in the indexing process. [Bobrow 1969, Carmody 1969,
Nelson 1967, Walker 1967] report early work dealing with retrieval aspects of text
preparation.
Another root is in programs that provide time-sharing access to large bibliographic
databases. In [Kessler 1967], for example, the possibility of individuals wanting to
extract and maintain personal copies of parts of very large general.use databases was
recognized. In addition, these larger systems have had an influence on software for
personal applications.
Lastly, much important work in this field derives from the study of a more general
problem: how to effectively support an individual's information processing work, in th~
broad sense. [Bush 1945] published probably the earliest vision of computer assistance
for information work. His idea of a "memex" machine is heavily cited. [Englebart 1961]
developed some of the psychological and human factors aspects of information handling
work, while [Nelson 1965] did some similar thinking, though oriented more towards
support of creative writing.
Comments on the State of the Art
Judging from the significant number of books and papers published, and from the fact
that sections on 'support for personal files' are beginning to appear in survey articles,
the field of personal retrieval systems is at least in its adolescence. A large number of
people have tried them out, and have found them useful and beneficial. Computer-based
systems have been in use for a reasonable amount of time (since about 1966).

4
Many such systems use unstructured 'flat files' of bibliographic-style records. More
elaborate data structures (indices, linked lists, hierarchies) have been explored and
found useful for some applications, particularly when on-line retrieval is desired.
Query and reporting facilities available in personal systems range from simple 'list the
whole database' commands to more elaborate boolean queries, sorting, and facilities for
fu II text search.
Application of general-purpose database management software to personal collections is
commonplace. To an increasing degree, these systems provide the ability to 'customize'
data structures and the user interface to particular applications.
Cost-effective personal retrieval systems have been developed for large time-shared
computers, and for mini-computers. The micro-computer era is just beginning, with at
least two interesting retrieval software packages available [Gerritsen 1978, Morrill
1978], and a surge of activity in this area predicted. With workable systems costing a
few thousand dollars, the cost-effectiveness of personal retrieval work is improving
dramatically.
Some thoughts on areas for further research

Portable systems. Cheap, portable computer systems with enough mass storage (one or
two megabytes) to do interesting retrieval work are riot far off. Hardware costing under
a thousand dollars will probably be ready with a few years; software to maJt:~~-I----'
ENCODER

'I ./

ClK'

I ....

'.

R
S E

H G

I I
F S

(16 BITS)

E

R
CLK~
150 Mhz

pulse every 16

b it tim es (10M hz).

Figure 2

I

'.

!~
I
I

I
I
I
I
I

~~--,--!...:PA:.!.:R..:.!A..!.:;L;!;:.LE:;;.:L:..:D:::..:;A;:..:T~A~IN~_ _ _---.,.--f.(~

TT

* Is a 1 bit-time

....

r!....

I ...

.... DATA

I'-

I

FF~I/_ _ _ _~C~RC~CO~N~T~R~O~L~_____~I__+~_

-.,11./ SERIAL

.....
7'

I
I
I

R

~~R~

7'

*
PHASE

L....t;<;:-~32:.:0~M:.:..:h.:.::.Z_-t.~t::g::g:.:..~.-J

10 Mhz WORD CLOCK

High Speed Serial to Parallel Converter

I

I
I
I
I
I
I

(

For Xerox internal use only

Whole ALTO World Newsletter
Technology and Tools

XEROX

October 15, 1978

SPECIAL ANNOUNCEMENTS
WHOLE ALTO WORLD MEETING • The Whole Alto World meeting is being jointly hosted by
Jim Iverson of WRC and Darwin Newton of Ginn this Tuesday, October 17th, at the Le
Champignon Restaurant in Webster, New York. Discussion topics include the Alto Network and
Alto Gateways, recent hardware and software developments, and activities at various user sites. A
report on the meeting will appear in the next Newsletter.

GENERAL NOTES
NEW ALTO NETWORK COORDINATOR . As previous Newsletter items have indicated,
WRC/RTCC is assuming Alto Network operational responsibility from PARCo Art Axelrod of
WRC is the new coordinator. Art will coordinate the installation and operation of Gateway systems,
phone lines, etc., and maintain the name lookup data base. Inquiries about setting up new gateways
and requests to add or change machine names should be directed to Art at 8*222-5811 or message
. Many thanks to all those at P ARC that handled the network operational details in
addition to their regular jobs.
USING THE TERM "ETHERNET" . A memo was recently received from Barry Smith of
OGC/Patents concerning the use of the term "Ethernet". The text of the memo follows;
As you may know, we eventually will be using the term "Ethernet" as a trademark and
applying for trademark registration. Accordingly, it now becomes important for us to insure
that term does not becOlne generic, which would prevent us from obtaining federal
registration.
Accordingly, please insure that future Xerox publications use the term "Ethernet" only as a
adjective to modify the genetic system, e.g., and Ethernet multi-access communications
network. The term Ethernet must not be used as a noun, e.g., an Ethernet.

MARKET PLACE
Market Place provides a forum for Alto users to make offerings and requests for Alto related
hardware and software. To place an "ad" or offering, send the text to the coordinator, Frank
Ludolph, at PARC, message , or phone Intelnet 8*923-4652.
BREAKING UP LARGE FILES· Geoff Thompson offers a tool provided to him by Bill Duvall to
break a large file into smaller ones. The specific use in this case was for crash recovery. The
program, Break file, was used to break a large Garbage.$ file into smaller pieces for editing with the
Bravo unfOlmatted' Get The program is on· [IVY]StanIntOl.sil, StanInt02.sil, ...
StanInt05.sil, and StanIntBdMapA.sil.
SOME MICROCODE STUFF· Dave Cronshaw has written some microcode routines for extended
memory versions of the Convert, Block Move, and Block Store instructions, and has written some
BCPL routines to make use of the ASIM package easier for checking out new emulator task
microcode. Formal documentation does not exist; it will be written if interest exists. Contact Dave
at 8*823-7279 or message .

TOOLS
HARDWARE
8TH BUILD . Shipments of the 8th build have begun ahead of schedule. Though spa cannot
commit to an accelerated shipping schedule due to a less than normal inventory of modules, they
wlll attempt to maintain the current lead to the extent possible. On a personal note, thanks to all
the spa people for their efforts and the hassles the early shipments saved us in ASD User Support
Services.
ALTO I POWER UP HAZZARD· Simply powering up an Alto I and setting the disk to RUN can
potentially clobber the disk. A fix is being investigated but in the meanwhile the proper sequence of
actions is: 1) power up with the disk in LOAD, 2) push the boot button, 3) set the disk to RUN.

MAINTENANCE NOTES
ALTO XM PHANTOM PARITY ERRORS· Extended memory Altos are reporting parity errors
in the second, third, and forth memory banks which diagnostics fail to replicate. The reported
errors, in fact, do not exist. DMT sets parity indicators during its normal operation. The Operating
System, when booted, resets these indicators for the first bank (64K) only. The phantom errors,
which occur only with programs that use more than 64K, are a result of uncleared indicators in the
higher memory banks. The next release of the operating system will reset all banks; in the
meanwhile extended memory programs should clear them during initialization.
If you a running an extended memory program which fails to reset the parity indicators, Bill Duvall
offers a small program which will resets them; simply execute it immediately after booting or prior
to running the XM program. Retrieve [IVY]FixX.run.

SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available from your
local IVY server under the directories  and . If they are not available, or if
you are in doubt as to the version, they may be retrieved from [MAXC] (same directories). Files
stored under other directories are on [MAXC] unless otherwise indicated, e.g. [XEOS].

2

For Xerox internal use only

Whole ALTO World Newsletter
NEW RELEASE: CALLUP • This experimental program from Dan Swinehart will lookup the
telephone number of an individual on an on-line directory and, if a "Ross box" is attached to your
machine, place the call. The directOlY is taken from the Xerox Intelnet directory and can be
extended by personal listings if you desire. The program is fully documented on
[MAXC] RecursiveMachines.press

This memo contains a functional description of a novel information-processing
system architectu re, called "Recu rsive Machines", which is proposed as a viable
alternate to von Neumann architecture and is claimed to be well suited to office
information-processing. "Functional description" implies that neither implementation nor use nor evaluation is within the memo's scope; these must be treated in
sequel.

O.

MOTIVATION

This work is motivated by the greatness of the disparity between our contemporary models of office
infomlation-processing and the traditional model of information-processing systems, the von
Neumann computer. Information in an office is represented by a growing, adaptive set of flexible
structures; information in a von Neumann computer is represented by bytes in a rigidly bounded,
linear address space. Office procedures are a growing, adaptive set of loosely interconnected, eventdriven activities; procedures in a von Neumann computer are a rigid, control-driven sequence
drawn from a small set of logical operations. Is there a viable, alternate model of informationprocessing systems which is similar to, rather than disparate from, our models of the office?

1. ARO'UTECTURAL PRINCIPLES

1.1 Basic Assumptions
Our most basic assumption is that it is time to use a richer model of information than a 16-bit
word. Existing storage structures are so simple that they have come to be one of the disadvantages
of traditional architecture, instead of one of the advantages. They do not model real-world data
well, and the cost of overcoming their structural simplicity is greater than the cost of using a richer

2

set of storage structures. This is true without question at the software level; we assert it has recently
become true at the hardware leve1. Recursive Machines handle data cost-effectively by using an
hierarchical, variable-length structure as the most basic element of storage.
Our second basic assumption is that it is time to use a richer model of processing than a sequential
machine. Existing processors are so simple that they have come to be one of the disadvantages of
traditional architecture~ instead of one of the advantages. Having a single~ centra1ized~ sequential,
register manipulator discourages the use of two vast classes of algorithms: descriptive rather than
procedural~ and concurrent rather than sequential. Recursive Machines encourage the use of a wide
class of algorithms by having an unlimited number of generalized sequential machines as basic
processing elements and by controlling them in a decentralized~ concurrent manner.
Our third assumption is that as LSI circuits shrink and speed up~ the limiting resource in an
information-processing system will no longer be main store nor processor cycles but pins. Indeed~
some observers define VLSI to be that level of circuit technology for which traditional architecture
becomes less advantageous than some alternate architecture. Recursive Machines use three tactics
for coping with pin limitations: (1) perform operations serially to minimize widths of
communication paths~ (2) locate data, program, and interpreter together to minimize off-chip
communication, and (3) decentralize systems functions, such as scheduling, storage management, and
inpuU output operations to reduce system-wide communication.
Our fourth assumption is that there will be further miniaturization of components by three orders of
magnitude, making physical boundaries coincide with different interfaces during a machine's
lifetime and making component failures certain.
Recursive Machines cope with increasing
miniaturization by: (1) making any collection of elements functionally identical to a single element
so that chips with 10 and 1,000 elements are functionally identical, (2) using logical, rather than
physical~ addresses, (3) being basically asynchronous, and (4) integrating recovery ITlechanisms.
1.2 Basic Principles
The purpose of a Recursive Machine is that of an information-processing system: to hold
information and to allow that information to be examined and changed. VLSI gives us both the
necessity and the opportunity to create wholly new information-processing systems. Such latitude
requires us to have a set of governing principles which compel all design decisions to fulfill a single
purpose. The following principles are offered as being more harmonious with each other and with
VLSI technology than with traditional principles.

1.2.1 Recursive storage Traditional storage structure is characterizable as a disjoint
collection of media, where a medium is a linear
example, {ROM, registers, cache, main store, 10
kinds}. Recursive storage generalizes the notion of
defined hierarchy of variable-length cells. This is
notion of a collection of 111edia.

vector of fixed-length cells. For
buffers, device storage of various
a storage medium to a recursivelysufficiently general to obviate the

1.2.2 Recursive machine organization

Traditional
machine
organization
involves
specialized component~. Stprage subsystems, processors, input/output controllers each
perform disjoint sets of storage, processing, and 10 functions, respectively. Recursive
machine organization generalizes the notion of a component to an all-purpose element,
capable of storing, processing, and transmitting in formation, both to other elements and
to external devices. Over the range from nand gates to Cray-1, Recursive Machine
elements are medium-small. Recursively, any group of elements is all-purpose.

1.2.3 Recursive system organization Traditional systems are implemented by rigid physical
structures: components sit on conductors etched in printed-circuit boards, boards are
bussed together, racks contain a fixed number of boards. The logical structure mirrors
this rigidity. Recursive machine organization generalizes the notion of a component to
a recursively-structured~ n-connective element. Any number of elements have, as a

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

3

group, structural and logical properties identical to those of a single elelnent.
1.2.4 Recursive machine language Traditional machine language involves a fixed set of
simple operations on simple operands. Recursive machine language generalizes a
machine operation to be either a hard-wired primitive or any recursively-definable
composition of machine operations. This allows arbitrarily complex operations on
arbitrarily complex operands.
1.2.5 Decentralized, concurrent control In traditional systems, an instruction becomes
executable when a centralized, sequential processor fetches it as its next instruction. In
Recursive Machines, an instruction is continuously executable. It may receive and
transmit data at any time. Its execution may produce outputs which are sent to other
instructions, possibly causing them to produce outputs. It is the decentralized flow of
data from one instnlction to another which controls the system's operation, allowing
many instructions to execute concurrently.
The purpose of this memo is to elaborate this statement of principles sufficiently well to allow their
implementation.

2.

RECURSIVE STORAGE

2.1 Information
We define infonnation in terms of a represention for it. Information is represented, in part, by a
delimited string of data characters. Delimited strings directly reflect that property of information
that allows words to have a different number of characters in· them.
unit of storage
charact~r

character

:: = "(" character* fI)"
::= "0"
::= "1"

Example: 2001 = (11111010001) if the most-significant bit is left-most,
= (10001011111) if the least-significant bit is left-most.

To keep things simple, we choose binary digits for data characters. To allow strings to be as long as
possible, Recursive Machines control operations on items by counting matching delimiters, not by
counting characters. This means that in principle there is no limit to string length other than total
storage capacity.
Composite and nested information can be represented by letting an item of storage recursively be a
delilnited set of items of storage.
item of storage
item of storage

:: = "(" item: of storage*
:: = unit of storage

")"

Example: "An item may have either unordered or ordered subitems."

=

Sentence
Subject

Verb

Article Noun

Auxiliary Infinitive

( ( (An) (item) ) ( (may) (have»

Object
Prepositional phrase
(either unordered or ordered subitems) ) )

This definition represents everything as a tree-structure. In principle, there is no limit to the
number of subitems in an item, nor to the depth of nesting. Notice also that non-circular lists,
queues, varying-width stacks, etc., are representable. without using pointers or addresses. This does
not mean, though, that pointers cannot be used to represent cyclical structures.

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

4

An item may have either ordered or unordered subitems; that is, it may be either a set or a
sequence. An unordered item may have subitems which are either identical or distinct; that is, it
may be either a set or a bag.
2.1.1 Implementation
Although this memo is a functional description of Recursive Machinery, some comments on
implementation are necessary to emphasize differences from von Neumann architecture. One
implication of recursively defining an itetn of storage to be an ordered set of items is that it must
always be possible to place another item between any two items. A principle advantage of
delimiters is that they allow RM storage cells to perform such insertions using a tiny amount of
logic. Using delimiters, it is possible to distinguish physical storage which contains items from that
which does not. Let us call storage which does not contain an item "unused space". We can
distinguish it from used space by redefining an item of storage to be a set of items separated by
unused space.
item of storage
space
space

:: = "(n item of storage (space* item of storage)* ")"
:: = "0"
:: = "In

This definition has three advantageous properties. First, it accounts for physical space without
affecting the logical structure of any item. The nth item in a set is always the nth item, no matter
how much unused space surrounds it. Second, it accounts for physical space in terms of the logical
structure of data, making it easy to do physical allocation as a part of logical storage operations.
Third, it requires only two characters to distinguish all structural boundaries. Let" a" stand for
zero or one; then:
" ... a(... " is the boundary between unused space and an item;

"...«..."is the boundary between an item and its inferior;

" ...(a ... " is the left end of a unit;
" ... a) ... " is the right end of a unit;
"...»... " is the boundary between an item and its superior;
" ...)a ... " is the boundary between an item and unused space;
"......
0 ".IS the emp t y um't;
" ...)( ... " is the empty space;

reducing the logical complexity of the primitive operations.
2.1.2 Encoding
Our model of information requires four distinguishable characters, so we can use quatenary digits.
We can shorten this term to "quats", and that gives us four suggestive names for each digit, viz.:
"1"
"0"
"("
")"

high-quat
low-quat
come-quat
go-quat

This memo is written in terms of a four-character alphabet, or, more properly, two two-character
alphabets, one alphabet for data and another for the shape of the data. This does not prohibit
larger alphabets, such as two 256-character alphabets.
The null item is vitally needed as a place-holder in time for our temporal control system, just as
zero is needed a place-holder in space for our positional number system. Let us encode null as "0"
and zero as "(0)".
2.2 A Warning
Before describing addressing and storage operations, let m.e caution the reader against a common
ertor. Because of traditional architecture, we expect storage to be one of several distinct subsystems.

Recursive lvfachines, Wayne T. Wilner. August 2, 1978 10:33 AM

5

This is not true of Recursive Machines. Storage is all, and all is storage. Every Recursive Machine
operation is performed on items by items for items. There is no distinction between storage and
processing operations: one mechanism does both. There is no distinction between storage addresses
and processor addresses: they are in a single address space. There is no distinction between storage
and control: they have a single realization.
On the other hand, it helps to grasp the passive and static aspects of the system before attempting
the active and dynamic aspects. For this reason, we will explain some specific storage operations
before describing how Recursive Machines operate in general. Just remember that items are
conceptually both the storage and processing elements of the system.
2.3 Storage Operations
The basic storage operations include "read" and "write" which change the data inside of items, but
there must also be operations which create and destroy items themselves. We will call two of these
operations "put" and "take". Also, no single orientation for strings is optimal for all common
operations; thus, it should be equally convenient to process a string from either end.
2.3.1 Putting
When an item receives a message saying "put" with an item as a parameter, it creates a new item,
beside itself, with contents equal to that of the second parameter. There are two messages: "putL"
which places the new item on the left; and "putR" which places the new item on the right.
[Implementation note: there need not be any unused space beside the item initially. Two adjacent
items can always be pushed far enough apart to obtain sufficient unused space. As the items are
pushed apart, unused space· elsewhere contracts.]
2.3.2 Taking
When an item receives a message saying "take", it sends itself to the sender. It disappears from its
former location. There are two messages: "takeLR" which transmits the characters from left to
right and "takeRL", from right to left. [Implementation note: if the item is between collateral
items, the quats which it occupies may become unused space. Contrarily, if the item has no lefthand or right-hand neighbor, its quats cannot become unused space because this would violate the
definition of §2.1.1. "Taking" it must create unused space elsewhere.]
2.3.3 Reading
When an item receives a message saying "read", it sends its contents to the sender. There are two
messages: "readLR" which asks for the characters from left to right and "readRL", from right to
left.
2.3.4 Writing
When an item receives a message saying "write" with an item as a parameter, it changes its contents
to be that of the parameter. The new contents may be shorter or longer than the old [creating or
consuming unused space elsewhere]. Also, the new contents may have different structure from the
old.

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

6

We might portray the various operations as follows .

Before:

Message:

•.. )(item)( .••

(item) (putL) (abed)

After:

Message:

... ){abcd)(item)(. ..

(item) (putR) (abed)

After:

... ){item}(abcd)( ..•

Message:

(item) HakelR)

Message:

(item) (takeRL)

Reply:

(item)

Reply:

(meti)

After:

.. .){. ..

After:

... }( ...

Message:

(item) (readlR)

Message:

(item) (readRL)

Reply:

(item)

Reply:

(meti)

After:

Message:

... }(item)( ...

After:

... )(item){ ...

(item) (write) (abed)

After:

••• )(abcd){. ..

2.3.5 Discussion
Since "put" and "take" create and destroy items, they perform stack push, stack pop, enqueue, and
dequeue directly, rather than by manipulating pointers. Notice that it is unnecessary to reserve
space for stacks and queues. A stack of any length is initially just an empty item, "0". In this case,
the item which receives the "put" message is actually the empty contents of the empty item. It is
immaterial whether the empty contents puts the new item before or after itself; the result is "((new
item))". FIFO operation results from sending all "put" messages to whatever item is at one end
and all "takes" to the other end. LIFO operation results from sending all "puts" and "takes" to the
same end. Double-ended queues receive "puts" and "takes" at both ends.
Because the primitive storage operations are governed by delimiters, they transfer not only items,
but vectors, files, etc. Blocks of information can be transferred without resorting to an iterative
progrmTI or microprogram.
Since a primitive storage operation can involve millions of bits, separate incoming and outgoing
lines are needed to allow other operations to take place concurrently. Also, separate lines are
needed to allow faults to be signalled during a transmission.
The smallest item, "0", is still long enough to have its come-quat in one physical Recursive
Machine element and its go-quat in another physical element. Thus, primitive storage operations
require cooperation between elements.
[Implementation note: whether a Recursive Machine element is implemented using RAM, CCD, or
disk storage technology makes no functional difference, only a performance difference. Any
reasonably large system would use several forms of storage technology.]

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

7

2.4 Addressing
Even the simplest operations, such as reading and writing, involve communication between items
which can distinguish themselves from other items. It is distinction which is the purpose of
Recursive Machine addressing, not location.
The location of an item changes frequently.
[Implementation note: like telephone numbers, RM addresses control switches rather than wires.
Also, like mobile phones, items can receive transmissions while moving.]
We can use the recursive composition of information in storage to break addressing into small steps.
Consider the general problem of selecting one item out of all. That item is either the root, or one
of its inferiors, or is contained in one of its inferiors. Addressing can begin by sending the root a
message which selects itself or one of its inferiors. If an inferior is selected, the process may repeat,
using it as the root of a subtree. An address is a sequence of messages, sent to a sequence of items
which sit successively below, beside, or above the previous recipient in the overall tree structure.

B_---'-'-.I_e_____---'IL-D__

( a l l ) f! .A
-______
I

E_ _ _ _ _.......'_F---'

"""-1

I

I

(all) (e)

(all) (e) (3)

(all) (e) (3) (b)

Notice that the address of an item is portrayed as a vector of selectors. In order to distinguish an
item from all other items, a selector is needed for each superior of the desired item.
It is not usually necessary to distinguish items from all other items. Consider cOlnmunication
between two collateral items (that is, the same superior item contains both as immediate inferiors);
they need distinguish themselves only from their superior and any other collateral items.

Distinguishing items based on their position within an overall tree structure or on their content has
important advantages: (1) an item's address is independent of changes in its physical position; (2) it
is independent of changes in its length or in the length of any item; and (3) it is independent of
changes in the allocation of unused space.
Also, there are many changes in the overall structure which leave addresses intact. Examples are:
(a) rearranging sub items which are never addressed absolutely; (b) putting and taking sub items from
an item which is never addressed absolutely; (c) changing the internal structure of subitems which
are always addressed absolutely. Notice that if items are always addressed by sending messages to
their superior, then the items' addresses are unaffected by all changes in items not superior to them.

2.4.1 Addresses
Selection can be based on any computable function. Consider the following kinds of address:

absolute

subitcms are considered to be ordered and numbered (from
either end); selection is made by specifying ordinal position;
e.g., #1770, #2-#10.

posi tion-rela tive

sub item s are addressed by relative, rather than absolute,
position; e.g., "last", "every other".

Recursive .Machine[}~ Wayne T. Wilner, August 2, 1978 10:33 AM

8

self~relative

items are addressed in terms of tree-traversing, beginning at a
given item; e.g., "immediate superior", "next".

content~addressable

items are accessed depending on their contents, not on their
position; e.g., "S*", (400.

computed

the item's address is some function; the name of the function
appears in the "address" but its value is used as the address
(e.g., successor function, "odd & "'first").

In addition, items can retain information about previous accesses, allowing further kinds of address:
context~relative

the requested item is understood to be in a previously
specified subtree; that portion of the absolute address which
identifies the subtree is omitted; this could also be called
"base-relative" .

request~relative

the item is understood to be near the previously addressed
item; only the difference between the addresses of the two
items is needed; this could also be called "incremental".

Consequently, an address is an alternating sequence, in which the odd terms are selectors of these
various kinds and the even terms are codes which indicate what type of selector follows. The first
term names an item unambiguously, such as "root" or "self'. The interpretation of the first three
terms of an address, "item-code-selector" yields another item which interprets the remainder of the
address.
item

code

I

selector

I

code

J

selector

This triple addresses ...
... thls item.
Item

code

selector]

This triple addresses ...
... thls item.
item

[Implementation note: in addition to having efficient forms of address, other storage elaborations
such as caches, virtual addresses, adaptive organization, etc., may still be useful in different
implementations.]
2.4.2 Address

spa~e

There is no guarantee that any· address is valid, except the address of the root. There must be at
least one item in storage in order to perform the operation which creates items.
Unused space has no address associated with it and there is no highest address, so additional
elements can simply be plugged in to enlarge the system. This means that trying to stick one more
item into a system in which every quat is physically in use needn't be fatal if more elements are on
hand. Contrast this with traditional storage systems.
2.4.3

Logical~to~physical

mapping [Implementation note)

A crucial difference between Recursive Machines and traditional machines is that logical addresses

Recursive Machines, Wayne T. Wilner, August 2,1978 10:33 AM

9

are always used and physical addresses are never used. This is possible because:
(i) All storage belongs to a single tree structure, which can be thought of as a long vector
of items.
(ii) Every physical machine element contains a portion of this vector in its physical store,
which can be thought of as a shift register of items.
(iii) One of the ways in which all physical machine elements are connected is in a vector.
This means that all physical storage is connected as one long shift register.
In other words, the logical organization of all information in storage is identical to the physical
organization of the store. There is a total ordering of all items in storage and the same total
ordering of all physical elements. Consequently, if each element keeps track of the absolute
addresses of the first and last quats in its store, then it can tell whether or not any logically
addressed item is within its store. Any absolute address which is presented to an entire RM is
resolved to a single element.
2.4.4 Broad distinctions
An address may distinguish more than one item. This simply means that ensuing messages will be
received by more than one item. Consider retrieval from a large file or document based on content.
The file would spread over many elements. Any specific string could potentially be within any
element which contained any portion of the file; so, all such elements must search simultaneously to
try to fulfill the address request. The larger a file is, the more elements search. Thus Recursive
Machines have the delightful property that content-based accesses take constant time; they are not
proportional to the size of the file being searched. Specifically, they average half the time required
for an element to circulate its entire store. [Implementation note: as an estimate of what this time
is, suppose large files were kept in RM elements which held 2048 quats (4Kb) and circulated at 100
MHz; then, content-based accesses would average 10 microseconds.]
2.5 Space Management [Implementation note1
Recall that there may be unused quats between any two collateral items. This means that a "put"
operation may indeed find space available for the new item. Similarly, a "take" operation may
convert the disappearing item into empty space. Thus, adjacent items don't necessarily move for
"put" and "take" operations. Movement depends on the distribution of unused space.
We know that virtual memory systems operate most efficiently when 15% of their real memory is
unoccupied.
Recursive Machine elements operate most efficiently, too, when some similar
percentage of their physical store is unoccupied. When no local items are transmitting or acting on
messages, RM elements trade items with their neighbors for unused space to obtain efficient
distribution.

3.

RECURSIVE MACHINE LANGUAGE

Control of Recursive Machines involves three concepts. First, the basic agent of control is the
generalized sequential machine, or "Gsm", which can be represented by an item of storage.
Because there is an explicit representation of control as an item, we can say that every Recursive
Machine operation is performed by items on items for items. Second, the set of primitive
operations is reversibly extendible so that a Recursive Machine can become totally bound to a
particular algorithm, and then unbound. This is possible by implementing the basic hardware in a
partly dynamic structure, allowing arbitrary Gsm's to become "hard-wired". Third, among the
primitive operations are methods for one Gsm to control other Gsm's. In particular, sequential
operation is just one of several ways to organize subordinate Gsm's.

Recursive Machines, Wayne T. Wilner, August 2. 1978 10:33 AM

10

3.1 Generalized Sequential Machines
Generalized sequential machines have state, receive inputs, send outputs and change state according
to a transition function [Kain]. Inputs can arrive any number of times before any outputs are sent,
and outputs can be sent any number of times before an input arrives. This makes them more
powerful than the procedures and coroutines of traditional programming languages, which accept
only one set of inputs each time they are called and return at most one output for each set of
inputs. Gsm's are also more powerful than the kinds of nodes usually considered for data-driven
processing [Davis]. For example, Gsm's can describe functions which: (a) have optional inputs, (b)
execute when a threshold number of inputs have arrived, (c) time-out, and (d) operate on several
instances of one input that are separated in time.
Recursive Machines are programmed by describing Gsm's which perfonn a desired computation.
This means that Recursive Machine instructions are not encodings of what a processor is to do
during one cycle; rather, they are continuously executable encodings of what a Gsm does.
Each physical RM element has a number of processors which are available to interpret the Gsm
encodings held in storage: to record inputs sent to them, to transmit outputs sent by them, to
indicate changes of their state.
Execution can take place whenever any input is sent to a Gsm, causing it to change state. Since the
receipt of input is performed by the same mechanism which executes instructions, namely, a
processor, it is guaranteed that an instruction which is made executable by that input can be
executed immediately.
Of course, executable instructions need not execute immediately. Consider an instnlction which is
in the midst of execution and requires an input which has not yet arrived. It can issue a request for
that input to some executable instnlction which is programmed to supply it. Receipt of a request
makes a processor available to the second instruction, causing it to yield output on demand. Data
bases are an example of Gsm's which are naturally driven by the need for output, that is, retrieval.
What we normally think of as a variable can be viewed as a Gsm. It can receive inputs which tell it
to put, take, read, or write. This is the same as object-oriented systems [Kay], in which a variable
can add a number to its own value. compare its value to another. send a bitmap which portrays its
value, and generally perfonn any operation. We use the term "item" rather than "object" simply to
avoid preconceptions associated with objects.
3.2 Control Representation
One way of representing Gsm operations is railroad notation, where the machine is thought of as an
engine at a particular place on the railroad (representing its state) facing a number of switches, one
of which is selected on the basis of the next input and where outputs are produced by traversing a
stretch of track which has an expression written on it.
An example for adding two positive integers is given on the next page. This example follows the
data-driven notion of addition, in which a "node" expects two addends to be sent on separate input
lines and begins to add them when two addends are present as inputs.
By using Gsm's instead of nodes, other notions are equally feasible. One alternate is to assume the
addends are interleaved in time on a single input line. Addition is performed by first absorbing
each odd input, then adding the next input to it, then yielding the sum, and finally returning to the
initial state.

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

11

Basic operations:
receive input I, produce output

°

followed by output P

1 o,P

I:O,P

:>

receive inputJ or K, produce output P if J, 0 if K.
J

u::t

>

(V J:P K:Q)

receive input J, produce output P; receive input K, produce output O.

J p

K

a:>

(A J:P K:Q)

receive any number of inputs J, produce an output P for each.

t

>

J p

(* J:p)

Example: to add two inputs which are delimited positive integers, use a machine
having three inputs and two outputs, one of them feeding back (for the carry).

«.

»0

(0
/\

00
10
10
01
10
01
01
11

000

»1

).

1.)·

l'

11\

,.,.,

010
)00
100
)10
110
)01
001
)11
011

·)0

00
I \

10

'1\

00

10

10

01

10
01

101
0)0

111

1)0
0)1
1)1

I

·00

10

11\

00

10

10

01

10
01

n.t

)·0

)

)·1

1)·

·10
·01
·11

00
I~

).

·)1

I

0·0

..

t

1·0
0·1
1·1

Linear representation of the algorithm:
(A

«·:(0

(*

(V

)}o:)·

(V

000:00 010:10 100:10 110:01 001:10 011 :01
»1:1,).

101:01 111:11

)

(A

{v

)00:00

)10:10

)01 :10

)11 :01

(*

·00:00

·10:10

·01:10

·11 :01

(V

·)0:)·

-)1: 1,)·

)}

(A

(V

0)0:00

1)0:10

0)1 :10

1)1 :01

(*

0·0:00

1·0:10

0·1 :10

1·1 :01

(V

).0:)·

)·1:1,)·

)}

A machine which is controlled by this expression will, if its two inputs are the strings
"(11)" and "(001)", produce the output "(111)"; that is, it will compute 3 + 4 = 7. Two
things are implied: the marking which represent the current state of the machine, and
control over when to receive inputs and send outputs.

'Recursive Machines. Wayne T. Wilner, August 2, 1978 10:33 AM

12

An alternate which builds on this last idea assumes again that there is a single input line. Addends
are preceded by an item which describes addition. This is absorbed first, so the addends can be
thought of as arriving at a general-purpose machine which has temporarily been conditioned to do
only addition. If we think of the input line as the connection from a conventional memory to a
conventional processor, we see how close this is to the familiar notion of how instIuctions execute.
3.3 Extendible Control
Railroad notation can be mechanically converted to And-Or logic. If we imagine building
Recursive Machine elements which contain dynamically programmable logic arrays, then we have
achieved a system in which the set of "hard-wired" functions is alterable. The set of machine
primitives can dynamically include any function. The result is a system from which the machine
language level has been removed: all software renders itself into logic functions which are literally
hard-wired when they execute.
If we take one more step, namely, control an element either by its own PLA or by a comparable bit
pattern taken from storage, then we remove the usual space restriction. This is the same as having a
microprogrammable machine execute microinstructions directly from main storage.
Of course, in And-Or form, functions require considerably more storage than in a machine language
encoding. For many functions, the machine language level is preferable. In fact, additional levels
of encoding are worthwhile. The point is that, no matter how many levels are implemented, if any
function can be moved to an adjacent level mechanically, then any specific application can realize
its most frequent functions at the hard-wired level.

4. DECENTRALIZED, CONCURRENT CONTROL

Generalized sequential luachines may perform not only primitive operations but also control other
Gsm's. There are six basic ways in which one Gsmcan control others:
hierarchical definition

the operations of one Gsm are given in terms of: the
operations of other Gsm's.

logical dependence

...N Gsm's in a pipeline, each performing one of N sequential
sub operations .

logical independence

...N Gsm's in a vector, each performing one of N parallel
subprocesses.

logical separation

...N Gsm's in a vector, each performing one of N parallel
subprocesses; however, the subprocesses are not totally
independent.

repetition in control

...N Gsm's in a vector, each performing one of N parallel
subprocesses; however, the desired result is not a combination
of results from every subprocess but only from one (as in
conditional· or iterative statements).

repetition in data

... N Gsm's in a vector, each using one of N subitems as input
to a given process.

Each of these methods of controlling other Gsm's is representable as a single item. In other words,
these kinds of parallel processes can be written in a linear notation which contains the definition
and state of each process. Let a Gsm be abstractly written as a pair of parentheses, representing its
encoding, and a marker, ©, representing the current state of the Gsm.
(... © ...)

Recursive Machines. Wayne T. Wilner, August 2. 1978 10:33 AM

13

A hierarchical relationship between two Gsm's is written by including the inferior in the superior.

(... © ... (... © ...) ...)
Control over other Gsm's is written by including them all as inferiors.
( ... © ... (... © ...)

( ... © ...)

( ... © ...) ...)

An expression in this notation can progress from one configuration to the next due to the actions of
one Recursive Machine element or many. This means that the number of processors which actually
execute a collection of parallel tasks needn't be decided beforehand. In fact, it can vary from
microsecond to microsecond.
This approach to parallel processing has the advantages that:
many small processing elements or a few middling elements or one large element are all
controlled by exactly the same mechanism, which accOlwnodates increasing
miniaturization;
movement of data is largely between bottom-level Gsm encodings; since these are
contiguous, off-chip communication is minimized, which accommodates low-bandwidth
pins;
off-chip communication
communication;

largely

goes

to

adjacent

chips,

reducing

system-wide

there is essentially no centralized control; at worst, a top-level Gsm may coordinate many
large inferiors, and because of the items' great size, messages would pass across the
entire system, but the higher-level busses in a RM are there specifically for lowfrequency, top-level coordination.
4.1 Communication

Any function which is described in terms of more than one Gsm needs to tell not only how the
individual Gsm's operate but also how they cooperate. Inputs and outputs of one are identified
with inputs and outputs of others.
4.1.1 Hierarchical definition

Subroutines are functions which appear in the description of others, and which, consequently, send
their outputs to whichever item sent them inputs. The addresses of these items are generally known
in advance, but needn't be. Subroutining can be accomplished by augmenting the set of inputs with
the address of the sender, and then sending the outputs to subitems at that address. Subroutines
which appear in the description of only Qne other function can be physically located within the
other's description.
(... © ... ( ... © ...) ...)
4.1.2 Logical dependence

Sequential algorithms are composed of logically dependent functions. In terms of the abstract
notation, logical dependence means that all outputs flow from left to right and that some outputs
flow between inferiors.
(... © ..•

---7 (... © ...) ---7(... © ...) ---7(... © ...) ---7 ...)

4.1.3 Logical independence

A restricted class of parallel algorithms are composed of logically independent functions. In terms
of the abstract notation, logical independence means that all outputs flow from left to right and that

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

14

(. ©
. . T:._(··_·
r

no outputs flow between inferiors.

-©-'-")~=-------i---'
© ...)
~

)(. .

~---------7('"

© ...)

,

...)

4.1.4 Logical separation
A wider class of parallel algorithms are composed of logically dependent functions. In terms of the
abstract notation, this means that most outputs flow from left to right but some do not.

(... © ...

T (..

© ...) --7(... © ...)

r'"

© ...) -------} ...)

4.1.5 Repetition in control
Algorithms which derive their parallelism from their own structure are composed of functions which
are selectively executed. In terms of the abstract notation, there is no characterizing pattern of
cooperation; all possible flows may occur.
4.1.6 Repetition in data
Algorithms which derive their parallelism from the data on which they operate are composed of
multiple copies of the same function, along with two bracketing functions which disperse and collect
the data, respectively. In terms of the abstract notation, repetition in data means that the middle N
functions are identical. An important point is that the number of replications, N, may be governed
either by the structure of the data or by the structure of the activity being modelled or by any other
extrinsic consideration.

(... © ... --7 (... © ...)

(... ®

"')1

.-. (... ®
(... ®

...)

(... ®

...)

...)

.....'

(

...

© ...) --7 ...)

4.2 Data-Driven Versus Control-Driven
Data-driven and control-driven models of computation are not mutually exclusive. Recursive
Machine architecture supports both, allowing the choice between them to depend on the
application.
Some functions are naturally driven by the availability of input data. In their descriptions, inputs
are encoded as empty items. Functions which supply these values have their outputs encoded as
"write" messages addressed to the corresponding inputs.
Other functions are naturally driven by the need for input data. In their descriptions, inputs are
encoded as "read" messages addressed to thecorrespondil1g output.

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

15

5.

RECURSIVE SYSTEM ORGANIZATION

5.1 System Organization
In order to survive several orders of magnitude more miniaturization, to allow systems to be
configured out of a variable number of elements, and to allow configurations to tolerate failed
elements, a system of elements must be isomorphic to a single element. That is, the method of
interconnecting elements and the method of communicating between elements must be isomorphic
at all levels of system construction.
A single element is partly a shift register onto which a logical data organization is mapped.
Therefore, a system of elements must form a shift register. Each element, and recursively, each
system of elements, must have two nearest-neighbor connections, over which quats are moved when
operations force them out of any given element.
A single element has several external connections, over which information is exchanged with other
systems. Therefore, a system of elements must have several external connections. Recall (from
§ 2.4.3 Logical-to-physical mapping) that each element keeps track of the absolute addresses of the
first and last quats in its portion of the overall shift register. Likewise, a system of elements has
identical addressing logic which keeps track of the absolute addresses of the first and last quats in
its portion.
A Recursive Machine system, then, consists of a number of RM elements or, recursively, a number
of RM systems, which are interconnected in a chain and which have their external connections
bussed together. Quats which pass in and out of both ends are monitored and the logical addresses
of the first and last quats in the system are kept up to date. Any message which appears on the
system's bus and addresses a nonlocal item is routed to the next higher bus. Conversely, any
message which appears on the next higher bus and addresses a local item is routed to the system's
bus.
In the diagram on the next page, the outermost border surrounds a single Recursive Machine
element, which is composed, recursively, of four RM's. Each of these is, in turn, composed of four
RM's, and each of these, too, is composed of four RM's. There are 4 3 = 64 elements at the lowest
level shown. The interconnecting busses at this fourth level of system structure are not shown, nor
are the bus coupling elements. Also, the physical diagram shows two busses, while the logical
diagram shows only one.
[Implementation note: notice that any of the levels could correspond to chip packages. Recursive
Machinery can be implemented with one element per chip in 1978, four elements per chip in 1980,
sixteen in '82, 64 in '84, 1024 in '88. In other words, the system in the diagram can be
implemented on one lOO-package board today, and on l/16 th of a chip ten years from now.]
[Implementation note: advantage can be taken of the two-dimensional arrangement of RM elements
to avoid having to store matrices in either row or column order. Instead, a matrix can be stored as
a vector of quadrants, each of which may fall into a rectangular set of elements. Then, operations
on submatrices can proceed in parallel.]

5.1.1 System intercommunication
We have already described one form of communication (in § 2.4 Addressing) as a sequence of items,
alternating between selectors and codes which determine the type of the following selector. All
Recursive Machine communications are a simple generalization: the "type-selector" pair of an
address is a special case; the more general case allows n-ary sequences of items in which the first
item determines how to interpret the remainder. For example, the first item could be an addition
operator, indicating that the next item is an addend, to be arithmetically combined with the
recipient's value. Each element must listen to all messages and interpret all addressing operators to
determine whether or not the remainder of the message must be routed to an item within its store.

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

16

Recursive Machine, physical system organization:
First level

external bus

Second level
I

I

I

Thir4llevel
r--

DO
DO

DO

o

~

0

-

I

I

DO
DO

DO
DO

~

I-

r-- -

'-

DO
DO

DO
DO

I

I

~

roo-

DO

DO
DO

I

I

00

-

~

wire to
left· hand
neig hbor

wire to
right ·hand
neig hbor

I

I

DO
..-DO

0 0

DO

f--

L--

o

DO
DO

0

DO

~

1--

~-

-

DO
OO

DO
DO

I

I

-

-

DO
DO

DO
DO

I

I

I

t-

I

external bus

Logical system organization:
First level
Second level

Fou rth level

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

17

5.1.2 Nearest-neighbor interconnection [Implementation note]
After considering the ultimate uses of information processing systems, the next most important
consideration is the number of pins needed to interconnect system elements. What is the minimum
needed to interconnect nearest-neighbors? Quats can be transferred one bit at a time. As to control
lines, two cases may be considered. In general, elements may not be implemented identically; on
the other hand, neighboring elements may be adjacent on a single chip. In either case, notice that
unused space buffer other operations from the transfer of quats to a neighbor. Hence, we can
implement the function with self-timed logic, using two control lines for "request to send" and "ok
to send".
Elements which have a neighbor in an adjacent system do not require more pins for the system's
addressing logic. Their chain connection simply fans out to it.
Since a single element can be an entire Recursive Machine, the nearest-neighbor connection makes
the shift register circular. This is extremely desirable in multi-element systems, too, as a protection
against failure of the first element. Reliability is increased if all elements are able to hold the root.
5.1.3 System interconnection [Implementation note]
What is the minimum number of pins needed to make external connections? One line is needed
for data. The rest depends on the choice of bus protocol. Let us assume that synchronous
operation is possible. Nearly all RM busses are local to a small area on a single chip. Higher-level
busses interconnect similarly packaged systems. Therefore, a centrally arbitrated bus is admissable,
using three control lines for "bus request", "bus grant", and "data present".
5.1.4 Total interconnection [Implementation note]
Using the figures of the two preceding sections, non-10 elements can be constructed with only 2x 3
+ 2x 4 = 14 pins, plus overhead.
Since this number is surprisingly small, implementors may consider wider connections. Data could
be transferred in quats rather than bits, using an extra data lines per connection; this raises the
count by four, to 18 +. This is still small, so there could be more than· two busses: four busses
require 28 + pins; five, 33 +; six, 38 + . Alternatively, there could be larger data characters than
quats: nine bits per character and two busses require 46 + pins.
5.2 Input/Output Organization
External devices are assigned to items with specific names. Sending "read" messages to the items
assigned to input devices and "write" messages to the items assigned to output devices distinguishes
information which is to be exchanged with the outside world.
Devices are physically connected to controllers which, on the one side, follow the device interface,
and on the other side, follow the Recursive Machine element interface. That is, controllers appear
to other elements to contain items, grab messages addressed to their items, and allow quats to flow
in and out of their sides.
A major difficulty involved in doing 10 is that, while items are normally free to migrate completely
around the system-wide shift register, an 10 item may not migrate out of the controller which is
physically connected to its associated device. A major relief for this difficulty is to implement
Recursive Machine operations so that there is no net migration; the time-average physical position
of any iteln approaches a constant. This is not a problem; the obvious implementations have this
property.

It can happen that a device transmits information which is many times larger than the capacity of
the element to which it is connected ...most of the information will have to emigrate to neighboring
elements. This presents no· problem for the given device, but if a controller has more than one
device attached to it, the others' associated 10 items may be forced out. A simple approach is to

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

18

attach each device to a number of adjacent elements, so that the associated item can migrate
between them. Another relief is to bracket 10 controllers with elemente; that have large stores and
can buffer large transmissions. This reduces displacements into the rest of the system.
[Implementation note: it is undesirable to keep 10 items at one end of the overall shift register. In
general, the shift register is circular, and the ends may migrate. In 1979, when Recursive Machines
have few elements, the end of the shift register is likely to remain in exactly one element; its failure
would be catastrophic. In 1989, when Recursive Machines have tens of thousands of elements,
external connections will necessarily run to elements which are separated by hundreds of others, in
effect, distributing 10 items throughout the system.]
5.3 System Initialization

Systems which consist entirely of volatile storage contain only unused space when they are turned
on. The very minimum action to be taken is to create a root item in exactly one of the elements,
since all RM operations are performed by some item.
Systems which contain nonvolatile storage can include a representation of a Gsm which accepts a
power-on input and boots the system.
5.4 Error Recovery

Recursive Machines are very sensitive to failure in three places: (1) the continuity of the systemwide shift register; (2) delimiter balance, both in storage and during transmission; and (3) bus
couplers, with increasing sensitivity at increasing levels.
The complete failure of an element destroys an arbitrary sequence of quats, since element
boundaries do not necessarily correspond to item boundaries. However, the address information in
elements on both sides of the failure allow the restoration of delimiter balance. Because groups of
elements exchange information on busses, an element which drops off the busses does not affect the
others. The shift register is more sensitive. It is necessary to provide bypasses around each
element, which are activated when an element fails.
Considering delirniter balance during transmission, single bit errors result in syntactic nonsense:
original

erroneous

(
(

0/1

)

0/1

)

(
(
)

0/1
0/1

)

consequence
extra) or ( embedded in data
extra) or ) embedded in data
( embedded in data or failure to terminate
( embedded in data or failure to terminate
( embedded in data or failure to terminate
) embedded in data or extra quats

Except for the termination failures, these syntactic errors can sthnulate retransmission.
[Implementation note: termination failures can be reduced by suffixing one or more go-quats to
each message. If go-quats are lost in transmission, the superfluous ones make up the difference,
allowing the receiver to detect an end to the message. The receiver can then count the received
suffix to determine whether or not go-quats were lost. The advantage of suffixed go-quats is that a
common kind of transient bus failure can be detected quickly with low overhead. Their
disadvantage is that they do not make the probability of termination failure zero, so time-out is still
needed.]
The complete failure of a bus coupler cuts off external access to a portion of the tree. Since the
system-wide shift register does not go through bus couplers, information in the afflicted subtree can
be recovered by forcing it to migrate into elements which can be accessed externally.
[Implementation note: it may be tempting to attach devices to the highest bus coupler, which can
access the whole tree, bur the failure of that coupler would be catastrophic.]

Recursive lvfachines, Wayne T. Wilner, August 2, 1978 10:33 AM

19

5.4.1 (;SEn errors
Since there will be logical errors made when constructing Gsm's, and since arbitrary Gsm's can be
executed at the hardware level, the basic machinery aborts Gsm's which receive unanticipated
inputs, which cycle without end, or which reach a terminal state. A Gsm which is aborted leaves a
representation of its complete state at the time of the error, facilitating diagnosis. It is in principle
easy to alter the representation of an aborted Gsm, either to modify its definition or to modify its
state, to obtain a new encoding which will not fail as the old one did.

5.4.2 Robustness
Recursive Machines are insensitive to certain failures. All elements are anonymous and there is no
way to tell in which element any particular operation is performed, so the failure of one element
does not hamper the execution of programs by the remaining clements.
Transient failures often precede hard failures. Elements which detect transients can flush their
stores, leaving only unused space, and activate the chain bypass, effectively taking themselves out of
the system before any information is lost. Such graceful failure will be vital when there are over
1000 elements per chip, since it may not be practical to replace chips while 900 or 800 elements are
still functioning.
Systems with many elements will not have all of them executing instructions at every instant. When
idle, RM elements can verify that the deli1niter balance within their own stores agrees with their
addressing information, adding a degree of reliability.

6.

RECURSIVE MACHINE ORGANIZATION

In §5 we saw that the principle of Recursive System Organization requires a single RM element to
have an interface which is isomorphic to that of a system of RM elements. One of the hannonies
between the RM principles is that this interface is all that is needed to fulfill the other principles.
The vital parts of a Recursive Machine element are derivable mainly from this interface, namely:
a shift register, over which items may be distributed in space, monitored at each end and at
several interior points by finite state machines, or Fsm's;
external transmission media, over which items may be distributed in time, Inonitored by a
Fsm; one medium is not sufficiently reliable to be adequate in Recursive Machines;
address registers, which track the absolute addresses of:
the first and last quat in the shift register, and
one or more interior quats which are to be manipulated
[although it may be possible to have just one address register];
Fsm's to evaluate a certain encoding of Gsm's, having:
logic to evaluate all possible encodings (a universal Gsm interpreter);
logic to evaluate certain frequently needed Gsm's (primitive machine operations);
programmable logic, to allow arbitrary encodings to become part of the hardware
dynamically;
logic to convert encodings into programmable logic form
(these latter two are required by the principle of Recursive Machine Language);
one or more internal transmission media, connecting the various parts.
The interior Fsm's interpret instructions; the end Fsm's pass quats between adjacent elements; bus
Fsm's select messages intended for items within the element. Although eight Fsm's are shown in
the adjacent diagram, a Recursive Machine element generally has at least one Fsm per port and one
or more interior Fsm's.

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

20

external bus
over which Items are addressed

into
FSM

internal
bus

~

bus
FSM

I

Int.
FSM
addr.
reg.

shift re Ister

addr.
reg.

connection
to left·hand
neighbor

end
FSM

-

f-

end
FSM

connection
to right-hand
neighbor

addr.
reg.

addr.
reg.
Int.
FSM

I

bus
FSM

internal
bus

into
FSM

external bus
over which items are addressed

All Fsm's may operate at once. The bus Fsm's can be performing address comparisons while both
neighbors are passing quats to the end Fsm's, and while each interior Fsm is interpreting a Gsm
encoding. [Itnplementation note: this argues for dividing the shift register into several sections so
that several Fsm's can be accessing different parts of it.]
[Implementation note: in order for a single element to be truly all-purpose, it must support a
standard interface as well, such as RS-232C.]

Recursive Machines, Wayne T. Wilner, August 2, 1978 10:33 AM

21

7.

PROGRAM EXAMPLE

Dijkstra's Dutch National Flag problem is a simple function which involves sorting, naming,
selection, iteration and arrays. Given an array of colored stripes, C [l:N], arrange the stripes so that
all the red ones occupy the lowest positions in the array, the white ones the middle positions, and
the blue ones the highest positions. Each stripe may be examined, only once, by using a function
color (0 which returns the color of the stripe in position i. In the original problem, the only way to
manipulate the array was by means of a function swap (i,j) which interchanged the stripes in
positions i and j.
Given that Recursive Machinery provides an arbitrary number of generalized sequential machines
for the implementation of algorithms, we can consider several mental models of the computation
which are automatically rejected by von Neumann architecture. One image is that of having
nearest-neighbors exchange stripes. For example, any item holding a red stripe which was to the
right of an item not holding a red stripe would trade with its neighbor. If all items were to perform
this operation, all red stripes would be traded until they occupied the left-most items. We, too,
have to reject this model because it violates the restriction that each stripe be examined for color
only once.
Another unusual model can be considered. If it happens that colors can be ordered, and that red
< white 
RIOlO,

L..-----,r-----------------.-~"
1[\
$1 color

R put $1

$1 color

W put $1

$1 color

= "red"
= "white"
= "blue"

W - 0,
B -0

B put $1

Notice:
delimiters make the array bound N superfluous;
if there are no stripes of a given color, the corresponding collector receives and sends no
items;
if there are stripes of a wrong color, the system enters a default error state; another
response could be attained by explicitly acknowledging wrong colors;
if transmission of the inputs is prematurely terminated, the machinery will be hung on
input...it can be cleared by supplying a closing delimiter, which will reveal what inputs
were received;
if transmission of the outputs is prematurely terminated, the machinery will be hung on
output...it can be cleared by acknowledging its remaining outputs.
When this function is programmed for traditional machinery, one must carefully manipulate several
pointers into the array. It is all too easy to make logical errors. Recursive Machinery provides
alternate models of information and processing which are rich enough to eliminate programming
intricacies at this level.

8.

PERSPECTIVE

8.1 Experience
Recursive Machines have benefitted from these lessons of traditional architecture:

o

The expressiveness of our programming languages, and hence our ability to map problems into
algorithms, is limited by the basic capabilities of our hardware. In order to serve human
organizations which are highly concurrent, dynamically restructuring themselves, and
dynamically redefining their activities, hardware must possess these same characteristics.

o
o

Convoluted machines engender convoluted programs.

o

There must be a deep harmony between data structure and progrrun structure. Object-oriented
systems exhibit an alternate harmony to that of von Neumann computers.

o

Managing storage can dominate machine activity if not done right. It has been hard to overlap
allocation and deallocation with normal access. It has been hard to map names which are
convenient at the software level into names which are convenient at the hardware level.

o
o

Applications always run out of address space.

o

Most problems have to be overspecified in order to become programmable, most often having
excessive sequentiality or excessive data ordering.

Given a hardware representation of nUlnbers which is precise to n decimal places, applications
eventually need n + 1.
Microprograms always run out of control store.

Recursive

Machine~~

Wayne T. Wilner, July 31, 1978 12:53 PM

23

o

Tagged architectures always run out of tag space.

o

Descriptor-based machines can avoid 70% of the data movement which takes place in machines
which lack descriptors.

o
o

Byte-oriented computers require 100% more storage, on average, than bit-oriented computers.
Important flexibility .is gained by moving information about the structure of data out of
programs and into data structures.

o

Important simplifications in programs have resulted from bringing input!output into the main
address space, from bringing secondary storage into the main address space, from bringing
process state into the main address space.

o

There is always one instruction which a machine's users would retard in order to speed up their
most frequent subroutine.

o

Contemporary bandwidth requirements are too high for system-wide busses.

o

Protection mechanisms must be allowed for in the hardware primitives.

Note that the principles of von Neumann architecture cause of many of these problems.

8.2 Anticipation
In addition, Recursive Machines accommodate the changes which VLSI brings.

o

Basic machine elements will have limited access to the rest of the system, prohibiting centralized
resources and centralized control.

o

Machine elements must survive three orders of magnitude more miniaturization, necessitating
extreme regularity.
.

o

Logic-poor systems will no longer have a general advantage over logic-rich systems.

Note that von Neumann architecture makes none of these accommodations.
8.3 Objective
The ultimate claim is that an architecture which fulfills these observations is well suited to office
information -processing.

8.3.1 Office information
Recursive Machines model office information well by explicitly representing structure. For
example, filing is modelled directly in terms of a top-level item which represents a room of filing
cabinets, whose sub items represent cabinets, whose sub items represent drawers, whose subitems
represent folders, and so on through sets of documents, documents, pages, lines, words, and
characters. Any operation which the hardware can perform on character strings (such as move,
copy, and delete), it can also perform on any higher-level structure. Furthermore, if each level is
distinguished from others by a descriptive tag, rather than by fixing the interpretation of depth, then
it is possible to create and destroy new levels in the hierarchy without having to rewrite existing
information.
Xerox's IISS model of information as a value with 15 attributes is easily represented by an item
consisting of 16 pairs, where the first of a pair is an encoding of the kind of attribute (Le., value,
name, description, length, format, responsibility, standardization level, security, status, alias,
synonym, algorithms, characteristic indicators, coding/edit rules, coding list, standard header) and
the second is the value of the attribute. Since all the attributes are part of a single superior item,
they can be copied and moved as' a unit. Access to any particular attribute is done by addressing
by content to find the first of a "kind, value" pair and then by addressing self-relatively (namely,
"next") to obtain the value:. of the attribute.
.

Recursive Machines, Wayne T. Wilner, July 31, 1978 12:53 PM

24

8.3.2 Office organization
Recursive Machines model office organizations well, by having a physical hierarchical structure and
by directly supporting logical hierarchical structures, with no predefined limits on the depth of
hierarchy nor on the branching at any node, as well as allowing hierarchies to change dynamically.
An ordered set of items corresponds to an assembly line. An unordered set of identical items
corresponds to a pool. An unordered set of dissimilar items corresponds to a bull-pen.

8.3.3 Office communication
Recursive Machines model office communication well, by having a total order among all
communicators, by allowing any sort of message to be initiated by any communicator, and by
having hierarchical communication lines. In any company with thousands of employees, hundreds
of small groups can talk simultaneously in offices and hallways, while more distant couples are
talking over the phone, while individuals are sending out memos to hundreds of others or
addressing a roomful of colleagues. There is a distinction to be recognized between media (e.g.,
rooms, hallways, telephones) and agents (employees). In a Recursive Machine, all these modes of
communication can take place, and simultaneously. Elelnents and their interconnections are media;
items are agents.

8.3.4 Office procedures
Recursive Machines model office procedures well. The RM element functions as someone in an
office who is available to perform whatever procedures are naturally located at that office. Arriving
inputs are like phone calls, letters, and ordinary conversation, providing new infornlation for which
various procedures may have been waiting. They intelTupt the element and either cause it to
resume working on a particular task or are queued until the task to which they contribute is
resumed for other reasons.

9.

REFERENCES

[Davis] Davis, A. L., "The Architecture and System Method of DDM1: a Recursively Structured
Data Driven Machine", Proc. Fifth Annual Workshop on Computer Architecture, 1978, pp. 210215.
[Kain] Kain, R. Y., Automata Theory: Machines and Languages, McGraw-Hill, 1972.
[Kay] Kay, A., "Microelectronics and the Personal Computer", Scientific American, September
1977, pp. 230-244.

Recursive Machines, Wayne T. Wilner, July 31, 1978 12:53 PM

For Xerox internal use only

Whole ALTO World Newsletter
Technology and Tools

XEROX

June 6, 1979

SPECIAL ANNOUNCEMENTS
WHOLE ALTO WORLD MEETING
The next Whole Alto World meeting is coming up soon. It will be held in the El Segundo area and.
hosted by Ted Davis and PD. Here are the details:
Tuesday, June 19, 1979 - 8:30 AM to 4:00 PM
Airport Hyatt House, The Mikado Room, Sepulveda at Century Blvd. We will have coffee
and pastries in the morning; luncheon arrangements have been made.
Attached to the Newsletter is a map giving further details about the location of the Airport Hyatt
House.

GENERAL NOTES
A CHANGE AT THE HELM
As most of you already know, Frank Ludolph has left WAW for new duties in SDD. Those of us
in WAW would like to thank Frank for the outstanding contributions he made as Coordinator,
particularly during our formative period.
As of June 1, a new WAW Coordinator is on board. He is Ron Cude, now a member of the ASD
Field Support Group. Ron comes to ASD and WAW from the Special Programs ft.!anuJacturing
Group (Alto purveyors to the W AW) where he was Test Manager. Ron will be serving as a
information contact for all Alto users so be sure to contact him when you have Alto-related
questions. Here's where:
Xerox Corporation
701 S. Aviation Blvd.
Attn: Ron Cude, A3-83
El Segundo, Ca. 90245
Intelnet 8*823-2465
Message: 
The function of the Whole Alto WorId Coordinator is to provide Alto users and maintainers with
information, a focal point for communications, and to facilitate the transfer of technology within
Xerox and it's Alto community.

THE NEWSLETTER
The Newsletter Editor would like to invite all Alto users to utilize this space for any item you think
may be of interest to others in the Alto World. Keep others informed of your activities, your
thoughts regarding anything Alto-related, new software, new hardware, etc. All of these and more
are of interest to us all in· the rapidly changing environment we share. One area that can be of
particular usefulness is the MARKET· PLA CE section. Let the Newsletter help you get in touch

For Xerox internal use only

Whole ALTO World Newsletter
with others sharing a common interest be it in hardware, software, graphics work, administration,
games or nn. Be sure to have anyone who would like to receive the Newsletter, but currently is
not, message or call Ron to get on the mailing list. If we get the approval of the majority of the
people at the next W AW meeting, we will be mailing the Newsletter only to those of you who do
not have message accounts. People with message accounts will be sent a message reporting the
publication of a new Newsletter.

MARKET PLACE
Market Place provides a forum for Alto users to make offerings and requests for Alto-related
hardware and software. To place an "ad" or offering, send the text to the Coordinator, Ron Cude,
at EI Segundo. Message , or phone Intelnet 8*823-2465.

TOOLS
HARDWARE

spa is still cranking Alto's out at a rate of eleven per week. In progress now is the tenth build.
Who ever thought it would go this far?
Have you built a special purpose interface for your Alto? Why not let WAW know about it.
There's no use having others "reinvent the wheel" when it isn't necessary. You may be surprised
what good stuff is already available, precluding your having to tie up resources and lTIOney on a
duplicate (or almost so) project.

DOCUMENTATION
New Hardware Manual - The Alto Hardware Manual has been revised to describe the forthcoming
3KControl RAM option for Alto II's and to incorporate a few other minor changes. See
[MAXC]AltoHardware.press.
Alto Sub-Systems Catalog - The catalog is in the process of being updated by Bruce Nelson of CSL and
will be included in next month's Newsletter.

MAINTENANCE NOTES
Hey Maintainers! This section is meant primarily for you. As new Alto changes or additions
happen, this section will tell you all you should know about them (I hope). If any of you come up
with any special trouble-shooting techniques, unique problems or whatever you think might interest
others like you, why not let WAW tell everyone else about them. Working on something for hours
is no fun when a little sharing of inside tips might cut your down time to only minutes.

The following was provided hy Dave Damouth at WR C:
"Recent open heart surgery on my lTIOUSe was a success. I had one of the "bad" ball mice,
which did not roll smoothly, and felt like the ball had flat spots. I removed the mechanical
assembly, and removed a· general accumulation of dust and lint by wiping exposed surfaces
with alcohol. Klaus Stange flushed the ball bearings with light oil, forcing it through them
and removing the excess with air pressure. After reassembly, it worked very smoothly.
This is a quick and easy procedure, providing that the delicate commutator wipers are
treated with respect"

2

For Xerox internal use only

Whole ALTO World

Newslett~r

This is a good procedure as long as extreme care is taken while your Mouse's innards are exposed.
Also, in oiling the bearings, be sure to use ONLY light gun oil or an equivalent. Anything else
may render them virtually useless. As an added note, SPG Manufacturing is now gearing up to
repair Mice. As with other field-returns, there is a maximum four week turn around on them. If
you have a sluggish or inoperable Mouse, plug in a spare and try Dave's procedure or send the
poor critter to SPG, attention: Tom Logan, Ml-38, for an operation.
SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available from your
local File Server under the directories  and . If they are not available, or if you
are in doubt as to the version, they may be retrieved from [MAXC] (same directories). Files stored
under other directories are on [MAXC] unless otherwise indicated, e.g. [ISIS].
ReReleases - Subsystems
SIL • "Expand mode" now expands the font as well as lines. This could be especially helpful when
using the Template font to see when Template characters and lines line up correctly. tE expands
the rectangular area defined by the two preceding marks so that it fills the screen (as nearly as
possible). The magnification factor (from 2 to 9) is shown in the status line. A second tEexits the
Retrieve
mode.
The sense of t X and tshX are reversed when in magnified mode.
 or callinteinet 8.823-2465

TECHNOLOGY AND TOOLS FOR THE FUTURE

July 25, 1979
SPECIAL ANNOUNCEMENTS
WHOLE AL TO WORLD MEETING

Our next meeting will be held Tuesday, October 2, 1979 in Lexington, Massachusets. Darwin
Newton of Ginn & Co. will be hosting. Make plans now to attend. Next month's Newsletter will
have further details. Please message or call Ron Cude if you think you will be attending. We
will explore reserving a block of rooms at the Sheraton Lexington.
ALTO HARDWARE CATALOG

The Alto Hardware Catalog is being updated. I would like to take this opportunity to solicit
inputs from anyone having an item qualifying for inclusion. Devices included in the Catalog
must have at least one prototype considered to work properly and to be reproducible from
existing documentation.

GENERAL NOTES
CHANGE IN NEWSLETTER

Attentive readers may have noticed some changes in the appearance of the Newsletter.
Besides the cosmetics, it is now being created using BravoX.
Any comments on the
appearance or content of the Newsletter are always appreciated.
LAUREL FOR NON-LAUREL USERS

On May 21 the GSD Mail Center in EI Segundo initiated an experimental Laurel Hardcopy
service for non-Laurel Users.
This enables Alto users located virtually anywhere to send unclassified messages via Laurel to
any Xerox employee in EI Segundo by addressing the message to Employee Name Mail
Stop(ESMail). When using the "cc:" line, copy recipients in EI Segundo may be identified by
typing Employee Name Mail Stop. Please note, (ESMail) should not be shown here, otherwise
only (ESMail) will appear on the hardcopy instead of the employee's name and mail stop.

For Xerox internal use only

2

Whole ALTO World Newsletter· July 24, 1979
For example:
To: Gene Diamand M4-04(ESMail>
cc: Rube Brady A 1-50, John Lund A3-44, Wegbreit, ABCt
Each day, EI Segundo Mail personnel periodically query Laurel for new messages, invoke the
requisite "Hardcopy" command, and deliver the hardcopy messages. Names and locations on
distribution lists containing EI Segundo addresses should be visible.
If a message is undeliverable, the Mail Center will notify the sender specified in the "From:"
line, via Laurel, with an explanation.
Due to the initial success of ESMail, by September the Mail Center plans to include the entire
Los Angeles Basin. Messages sent via (ESMail) to other Xerox facilities in the greater Los
Angeles area will be delivered through the Courier Network which services the majority of
Xerox locations in the Basin. Delivery of messages will have a maximum overnight turnaround.
A formal announcement will be forthcoming indicating the names and location codes of the
facilities to be serviced.
Depending on user response and on work being done by ASD and CSL, plans for the future
include:
• additional locations
• on request, confirmation of delivery
• automatic look up of the GSD INTELNET data base to immediately notify senders of
undeliverable messages
• properly encoded classified messages
Please direct any comments to Jerry Torres at (ESMail), EI Segundo Mail Stop A1·50, or
INTELNET 8.823-1169.
A CONVENIENT LAUREL HACK
The following was provided by Hugh Lauer:

I use the following hack as a convenient way to print copies of documents which are
"distributed" via a message:
When an interesting document is announced, GET the file Rem.Cm into the Laurel
message composition window. Add to the end of it the command:
HARDCOPY
(filename) (CR) (it is usually convenient to copy the filename, complete with server
identification, directly from the message announcing the document.) Then PUT the
contents of the message composition window back on Rem.em. Repeat this process
as often as necessary while reading your mail with Laurel. At the end of the session,
QUIT from Laurel and let the accumulated commands do the printing for you. To make
this work, you need on your Laurel disk: Empress.Run, HardCopy.Run, and enough
space to hold a reasonably sized document. One word of warning: Not all messages
contain precisely the right file name e.g. typo's, misspellings, incorrect subdirectories,
etc. A human rummaging around the appropriate directory can usually find the file he
or she wants, this scheme cannot.

MY PRINTED DOCUMENT LOOKS FUNNY
If you have trouble printing Press files retrieved from [XEOS] (or elsewhere), it probably means
you have been another victim of the great font kludge. Applying PressEdit to the file ,in
question will add the time stamp and allow the file to print correctly. The only remaining
question would be whether or not you can pleasingly print the "illuminated initials" some
p'eopleuse. Contributed by Don Winter.

For Xerox internal use only

3

Whole ALTO World Newsletter· July 24,1979
THE EVER EXPANDING WORLD OF ETHER

The latest edition of the Alto Network and Network Map are included this month (see pages 51
& 52). Copies can also be found on [MAXC], or
phone Intelnet 8*823-2465.

AL TO HARDWARE DRAWING LIST

Appended to this month's issue (beginning on page 53) is a numerical listing, prepared by
Carol Williams of SPG, of all Alto hardware drawings currently available and their latest
revision levels. If you need a particular drawing, call Carol, Intelnet 8*823-1654 or message
her via .

TOOLS
HARDWARE

*

ALTO

II MAG TAPE PACKAGE

*

Alto II's can now run 1600 BPI 9- Track Phase Encoded (PE) Magnetic Tapes. An installation
requires· two ASD tape controller boards, cables, and a few backplane modifications. Both
Kennedy (ANSI) and Mohawk style drives can be accomodated, with up to four drives daisychained by one controller set. The initial software has been released, which includes Tape
(integrated with Trident) microcode,low level (buffer I/O) software, a stream package, a utility
for copying unlabeled tapes of varying formats and a diagnostic. Interested parties should
contact Alan Paeth, % Liz Bond, XEOS, MS: 359, Intelnet 8*844·2232.

*

MAINTENANCE NOTES

"G"

REVISION CHANGE FOR ETHERNET MO[)ULE

*

An Engineering Order has been officially released by SPG Engineering. It is applicable to
Ethernet module's built before March 23, 1979 ("F" revision or earlier). The E. O. consists of
changing four resistors to a new value and removing two others. Some Ethernet module's
have exhibited marginal timing problems (particularly when talking to servers) and this change
should cure them. A copy of the E. O. can be found on the last page of the Newsletter.

For Xerox internal use only

4

Whole ALTO World Newsletter· July 24, 1979
SOFTWARE
In general, the subsystems, packages, and documentation indicated here will be available from your local File
Server under the directories  and . If they are not available, or if you are in doubt as to the
version, they may be retrieved from [MAXC] (same directories). Files stored under other directories are on [MAXC]
unless otherwise indicated, e.g. [ISIS].

*

SMALLTALK CALENDAR

*

RE-RELEASES-SUBSYSTEMS

A new version of Smalltalk Calendar is released with the boot files on [MAXC1 ]