Return to List of Reports
Presented here
Last summer, just after we had opened our doors as a public museum, Michael
Spock, Director of Boston's Children's Museum and member of The Computer
Museum Board, called me and asked, "Would you consider moving to Museum
Wharf?"
I retorted, "You've got to be kidding, we just opened in Marlboro." But the seed
had been planted.
During the last year, the most common questions from visitors and members
were: "In the long run, where do you think the Museum should be?" "How long
do you think the Museum will stay in Marlboro?" To be able to respond to these,
we evaluated alternative locations that would be convenient to our public:
people from around the world interested in computers. Proximity to the airport,
convention hotels and local universities were critical factors. The stumbling
block was money. Unless a special opportunity arose, relocating would cost tens
of millions of dollars and take years of planning.
In January Mike called again and asked if the Museum would consider moving
to the top two floors of Museum Wharf. I knew we should take him seriously,
but I questioned the suitability of the Wharf space. Having just installed a
9,000 pound section of ILLIAC IV, I asked, "What's the loading capacity of the
floor?"
He replied, "One hundred pounds per square foot."
"That's double our present loading capacity," I said. "But, how can we get a 12 x
8 x 4 foot machine to the top floors?"
"No problem," said Spock, "You can drive a fire engine into one end of the
elevator and out the other onto the floor."
The location fit the criteria. The site has a canal-front park with a view of
downtown Boston. It is minutes from the airport, a short walk from South
Station and the "redline" subway that stops near MIT and Harvard, and is
convenient to convention hotels. Also, BOSCOM, a permanent international
computer marketcenter opening in late 1984 on Commonwealth Pier, is within
walking distance.
Exhibit coordinator Jamie Parker and I made an appointment to see the space.
The Museum of Transportation had recently moved out leaving a bare shell
equipped to hold another museum. The sprinkler system, heating system and
public facilities were all up to code. And the structure itself, built as a wool
warehouse, had large generic spaces into which exhibits could be set. The
Computer Museum could occupy 60,000 square feet, six times more space than
it has in Marlboro. While The Computer Museum's goals indicate an eventual
need for several hundred thousand square feet, Museum Wharf provides the
appropriate next step.
But we did not let ourselves get excited. The Museum didn't have any funds to
purchase the property and Mike Spock and the Board of The Children's Museum
needed to have a rapid decision. I talked about the issue with Ken Olsen,
Chairman of our Board. He in turn took the issue to
the officers of Digital Equipment Corporation. The consensus was that if the
building provided good value for the Museum, and if enough support would be
forthcoming, then it was appropriate to make the move. Digital had been happy
to provide an incubator for the Museum, and would be proud to have it move to
proper museum quarters at the right time.
Two studies were undertaken to test whether we should purchase one half
interest in Museum Wharf. Digital's real estate department determined the
value to be received was very high. For a down payment of $1,200,000 and half
interest in a $1,600,000 Industrial Revenue Bond (at 8.5% interest to 1999), The
Computer Museum will own half of a 155,000 square-foot building equipped as a
museum. This is a third of the cost that most museums have to pay for similar
space in similar locations. Simultaneously Robert J. Corcoran Associates
undertook a feasibility study to determine whether $5 million could be raised for
this project. After more than sixty interviews with industry leaders, they gave
the project an unequivocal green light. The Board of Directors of The Computer
Museum then agreed to undertake the necessary fundraising to enable this
move.
Since then, the staffs of the two museums have met together and started to
work on appropriate ways to share and cooperate as the owners of Museum
Wharf.
The ground floor of the Wharf will be developed for public spaces. Both museums
will have separate lobbies and separate museum shops, accessible to the public
without entering the museums. MacDonalds has a long term lease on the bay
on one end of the building, and in the summertime "The Milk Bottle" is open as
a refreshment stand.
The Children's Museum occupies floors two through four and is accessible by
several interior stairways. Unlike many children's museums, it is both collection
based and hands-on. The Americana, Native American, and Japanese collections
provide the basis for exhibits, study and teacher resource material. The
centerpiece of the Japanese collection is a recreated 16th century silk
merchant's house from Kyoto. Visitors take off their shoes, sit on tamamis and
listen to an interpreter tell about life in the house. The collections and study
areas are housed in special climate-controlled areas beyond the house. The
curatorial staff of The Children's Museum will help us understand how best to
use the Wharf building for exhibits and the interrelation of study, collections
and exhibitions-an important concept for The Computer Museum to develop.
This move will bring the Museum to a new threshold in developing exhibits. The
members, many who act as "curators," have helped us acquire and interpret the
exhibits, resulting in a technical presentation. After an exhibit is up, they
comment and criticize, and we make changes. Many visitors at Museum Wharf
will be laymen, so our exhibits must be more accurate from the start and must
be layered from a general to a technical level. Because member input has been
so valuable, the exhibits will open for members only as a field test. If all goes
well, next May you will be invited to Museum Wharf to review the first
exhibition. And with all that has happened in this past year, I'm betting on it.
Gwen Bell
Creating Archives for the History of Information Processing
Symposium
The Computer Museum sponsored
two-day symposium in May on archiving issues in information processing history.
In only 35 years, the Information Revolution has produced more historical records on itself
in more forms than those available about any previous scientific era.
Symposium attendees included archivists and others from The MITRE Corporation,
Lawrence Livermore Laboratories, Travellers Insurance Company, the MIT Library and
Museum, Elecitherian Mills Museum, Clark University, the Charles Babbage Institute, the
Annals of the History of Computing, and the National Museum of Science and
Technology, Canada.
"Criteria and taxonomies must be established for collections," said Helen Slotkin, archivist
at MIT, "The first step is the general taxonomy of the field, such as that provided in Bell
and Newell's Computer Structures and adopted by The Computer Museum. The second step
is the decision of whether or not to save any particular document." ,
Slotkin emphasized that a ' record" is a record" independent of the field, and contemporary
standard archival criteria for preservation may be used. But contemporary standards are
different from those passed down from librarians in the days when everything could be
saved, shelved and cataloged.
Gordon Bell and Jean Sammet, both authors of historical "trees," argued about the
placement of limbs and branches and agreed that getting the tree planted was the
significant point. A forest with a limited number of species for various major collecting
areas would then give the overall picture.
The importance of different collections was also discussed. Arthur Norberg, director of the
Charles Babbage Institute, described its focus on the early papers of the individuals who
formed the industry, and hence the evolution of the information processing industry.
Computer Museum archivists
explained its collecting policy -
the Museum starts with hardware and
then collects the accompanying documentation. It was recognized that each institution would
provide archives in keeping with its primary role. For example, universities
and company archives would be expected to be primary sources for the
papers on people and activities primarily associated with them.
Computer historian Paul Ceruzzi made the case that although we need to see documents of
all kinds, the artifacts themselves are also valuable. A movie or a set of prints just does
not provide the same understanding as the object itself, or even a few pieces of the object;
and whenever those have survived they ought to be saved.
The symposium opened with a showing of videotapes and films of information processing,
followed by a discussion. The films were grouped into three kinds:
Video archives create separate archival issues. Videotapes are easy to make and getting
less expensive every day, yet they are time consuming to edit, expensive to preserve, and
require special equipment to watch.
Martin Campbell-Kelly, a collector of vintage films who uses films in his classes at the
University of Warwick, led off the discussion. He suggested that all films and video should
be rated. This set the group into discussion.
Jean Sammet: "Outside from the caveat of cost (and I realize that is a big one), I think
everything created on film ought to be kept. I want to see expression on people's faces. I
suspect that everyone has watched a rocket launch and gotten a thrill from it. It's only a
piece of machinery going up in the air.
And so what? Fifty or a hundred years from now school children will watch them and think
they are hysterical."
Helen Slotkin: "There were 1,024 rocket launches that were filmed. The national archivist
has asked, do we have to keep all of them? There were 150 failures and everyone agrees to
keep them."
Richard Solomon: "What would we give for a film of Babbage and Ada Lovelace just chatting,
not even saying anything of historical interest?"
Gwen Bell: "We not only have to be concerned with what we save but also what we create."
Helen Slotkin: "An archivist is passive. Only gathers things. In creating records, you are
saying there are holes and we will fill them. It is conscious and after-the-fact."
Gordon Bell: "Guidelines are needed for making films, because the Museum commissioned
two films of decommissioning of machines; one is great and the other is awful."
Ithiel de Sola Pool: "The important thing is the groups of people and their relationships and
how this comes across on videotape. Factual information can be better transferred in other
ways."
Helen Slotkin: "Unless you know who the user will be, you can't make the decision about
what to save. If you decide to film a conference, it could be used five different ways, and in
each case it would be done differently."
Gordon Bell: "Let's only deal with the producer/storey problem, not the consumer problem.
Nice to have the Los Alamos tapes and the Museum lecture tapes-in the first case the
people were in a group and defending their turf and in the second they were on their own-
the star. We need a set of rules of how to cut at the source."
Barbara Costello (Lawrence Livermore Laboratories): "Accuracy in videotapes is relatively
difficult; not the same control as books; especially on the made tapes."
Gwen Bell: "At present, for the produced tapes, there is no reviewing system as there is for
an article or book. They don't have the same kind of close scrutiny."
J. M. Graetz
I. BEFORE SPACEWAR!
The Lensman, The Skylark, and the Hingham Institute
It's Kimball Kinnison's fault. And Dick Seaton's. Without the
Gray Lensman and the Skylark of Space there would be
nothing to write about. So most of the blame falls on E. E.
Smith, but the Toho Film Studios and the American Research
and Development Corp. have something to answer for as well.
If Doc Smith had been content designing doughnuts, if
AmericanInternational Pictures had stuck to beach blanket
flicks, if (most of all) General Doriot hadn't waved money in
front of Ken Olsen in 1957, the world might yet be free of
Spacewar!
It all came together in 1961 at the Hingham Institute, a barely
habitable tenement on Hingham Street in Cambridge, MA.
Three Institute Fellows were involved: Wayne Wiitanen,
mathematician, early music buff, and mountain climber; J.
Martin Graetz (which is me), man of no fixed talent
who tended to act superior because he
was already a Published Author; and Stephen R. (Slug)
Russell, specialist in steam trains, trivia, and artificial
intelligence. We were all about 25 (the more or less to be the
same).
At the time, we were crashing and banging our way through
the "Skylark" and "Lensman" novels of Edward E. Smith, PhD,
a cereal chemist who wrote with the grace and refinement of a
pneumatic drill.
In a pinch, which is where they usually were, our heroes
could be counted on to come up with a complete scientific
theory, invent the technology to implement it, build the tools
to implement the technology, and produce the (usually)
weapons to blow away the baddies, all while being chased in
their spaceship hither and thither throughout the trackless
wastes of the galaxy (he wrote like that) by assorted
Fenachrone, Boskonians, and the World Steel Corporation.
In breaks between books, we would be off to one of Boston's
seedier cinemas to view the latest trash from
???. These movies depended for their
effects on high quality modelwork, oceans of rays, beams,
explosions and general brouhaha, and the determined
avoidance of plot, character, or
significance. They were the movie equivalent of The Skylark
of Space.
If that's the case, we asked ourselves, why doesn't anyone
make Skylark movies? Hearing no reply (our innocence of
current film technology, economics, and copyright laws was
enormous), we often passed the time in the Hingham Street
common room in deep wishful thought, inventing special
effects and sequences for a grand series of space epics that
would never see a sound stage. Nonetheless, these books,
movies, and bull-sessions established the mind-set that
eventually led to Spacewar!
When Computers Were Gods
In early 1961 Wayne, Slug, and I, by no coincidence, were all
working at Harvard University's Littauer Statistical Laboratory.
A large part of our jobs was to run statistics computations on
an IBM 704.
To a generation whose concept of a computer is founded on
the Z80 chip, it may be hard to visualize a 704 or to
comprehend the place it held in the public imagination. It was
a collection of mysterious hulking gray cabinets approachable
only through the intercession of The Operator.
Everything about the 704, from the inscrutable main frame to
the glowing tubes in the glass-walled core memory case,
proclaimed that this was a Very Complicated System operated
only by Specially Trained Personnel, among whom
programmers and other ordinary mortals were not numbered.
In short, a computer was something that you simply did not
sit down and fool around with.
A Stone's Throw From Olympus
In the summer of 1961 I went to work for Professor Jack B.
Dennis, who was then the proprietor of the TX-O, a machine
that to me was only slightly less legendary than its ancestor,
Whirlwind. The TX-O was transistorized, and while solid-state
computers were beginning to appear on the market, the "Tixo"
was the original. Even in 1961 it was acknowledged to be a
historically important research facility; many of the programs
developed on the TX-O, such as Jack Dennis's MACRO
Assembler and Thomas Stockham's FLIT debugging program,
were the first of their kind. So the chance to work on this
computer was in many ways a rite of passage; it meant
that I had joined the ranks of the Real Programmers.
While hardly your average populist Apple, the TX-CS was
definitely a step away from the Computer-As-Apollo. Instead
of being sealed into its own special chapel, it sat at one end
of a typical large, messy MIT research space: With its racks of
exposed circuitry, power supplies and meters, and its long,
low L-shaped console, the TX-O looked for all the world like
the control room of a suburban pumping station. And the
thing of it was, you were expected to run it yourself.
The TX-O's input and output medium was a Flexowriter: an all-
inone keyboard, printer, paper-tape reader and punch, that
worked like a mule and had a personality to match. There was
also a "high-speed" paper tape reader, a Grand Prix whiz that
could read programs into memory almost as fast as the
cassette-tape reader on a TRS-80.
And the TX-O had a scope. Console-mounted, programmable
CRTs were not unheard of at that time but they were generally
slow, inflexible, and awkward to program. The TX-O scope, on
the other hand, was easy to use; you could generate a useful
display with fewer than a dozen instructions. And if that
weren't enough, there was a magic wand: the light pen.
That was the TX-O: the world's first on-line computer, and the
training ground for the designers and programmers of later
generations of hands-on machines. The first computer bums-
hackers-were the products of this training; without it, and
them, there would have been no Spacewar!
Tixo's People
The users of the TX-O were a melange of students, staff
researchers and professors with not much in common other
than their need for large amounts of largely unstructured
computer time. The feel of the place, however, was
established by the hackers-mostly students, but including a
professor or two-whose lives seemed to be organized in 18-bit
strings.
Out of this cloud of computer bums emerged the group that
brought Spacewar! to the silver (well, light gray) screen: Dan
Edwards (AI Group), LISP specialist; Alan Kotok (TX-O staff),
who wrote the MIDAS Debugger; Robert A. Saunders (TX-O
staff), who wrote MIDAS, the successor to MACRO; Peter
Samson (AI Group), who made the Tixo
and PDP-1 play Bach, and Steve Russell
and I.
"You Mean That's All It Does?"
When computers were still marvels,
people would flock to watch them at work
whenever the opportunity arose. They
were usually disappointed. Whirring tapes
and clattering card readers can hold one's
interest only so long. They just did the
same dull thing over and over.
On the other hand, something is always
happening on a TV screen, which is why
people stare at them for hours. On MIT's
annual Open House day, for example,
people came to stare for hours at
Whirlwind's CRT screen. What did they
stare at? Bouncing Ball.
Bouncing Ball may be the very first
computer-CRT demonstration program. It
didn't do much: a dot appeared at the top
of the screen, fell to the bottom and
bounced (with a "thok" from the console
speaker). It bounced off the sides and
floor of the displayed box, gradually losing
momentum until it hit the floor and rolled
off the screen through a hole in the
bottom line. And that's all. Pong was not
even an idea in 1960. (Note: Well, maybe
not Pong, but something very much like it.
Watch these pages. -DHA)
The TX-O's counterpart to Bouncing Ball
was the Mouse in the Maze, written by
Douglas T Ross and John E. Ward.
Essentially, it was a short cartoon; a
stylized mouse searched through a
rectangular maze until it found a piece of
cheese which it then ate, leaving a few
crumbs. You constructed the maze and
placed the cheese (or cheeses-you could
have more than one) with the light pen. A
variation replaced the cheese with a
martini; after drinking the first one the
mouse would stagger to the next.
Besides the Mouse, the TX-O also had
HAX, which displayed changing patterns
according to the settings of two console
switch registers. Wellchosen settings
could produce interesting shapes or
arrangements of dots, sometimes
accompanied by amusing sounds from the
console speaker. The console speaker is a
phenomenon whose day seems to have
passed. (More than just a plaything, for
the experienced operator the speaker was
a valuable guide to the condition of a
running program.)
Finally, there was the inevitable Tic-Tac-Toe,
with the user playing the computer.
The TX-O version used the Flexowriter
rather than the scope. (The game is so
simple to analyze that there
was even a version for the off-line Flexo. )
These four programs pointed the way.
Bouncing Ball was a pure demonstration:
you pushed the button, and it did all the
rest. The mouse was more fun, because
you could make it different every time.
HAX was a real toy; you could play with it
while it was running and make it change
on the fly. And TicTac-Toe was an actual
game, however simpleminded. The
ingredients were there; we just needed an
idea.
The World's First Toy Computer
For all its homeliness, the TX-O was still
very much a god. It took up lots of space,
it had to be carefully tended, it took
special procedures to start it up and shut
it down, and it cost a lot of money to
build.
All this changed in the fall of 1961, when
the first production-model PDP-1 was
installed in the "Kluge Room" next door to
the TX-O. It had been anticipated for
months; an early brochure announcing the
machine (as well as a couple of noshows
called the PDP-2 and PDP-3, in case you
were wondering about that) had been
circulating in the area for a while. It was
clear that the PDP-1 had TX-O genes; the
hackers would be right at home.
The -1 would be faster than the Tixo, more
compact and available. It was the first
computer that did not require one to have
an E.E. degree and the patience of Buddha
to start it up in the morning; you could
turn it on anytime by flipping one switch,
and when you were finished, you could
turn it off. We had never seen anything
like that before.
II. SPACEWAR! BEGUN
The Hingham Institute Study Group
On Space Warfare
Long before the PDP-1 was up and
running, Wayne, Slug and I had formed an
ad-hoc committee on what to do with the
Type 30 Precision CRT Display which was
scheduled to be
installed a couple of months after the
computer itself. It was clear from the start
that while the Ball and Mouse and HAX
were clever and amusing, they really
weren't very good as demonstration
programs. Zooming across the galaxy with
our Bergenholm Intertialess Drive, the
Hingham Institute Study Group on Space
Warfare devised its Theory of Computer
Toys. A good demonstration program ought
to satisfy three criteria:
"SPACEWAR!" shouted Slug and I, as the
last force screen flared into the violet and
went down.
The basic rules developed quickly There
would be at least two spaceships, each
controlled by a set of console switches
("Gee, it would be neat to have a joystick
or something like that . . ."). The ships
would have a supply of rocket fuel and
some sort of weapon; a ray or a beam,
possibly a missile. For really hopeless
situations, a panic button would be nice .
. . hmmm . . . aha! Hyperspace! (What
else, after all, is there?) And that, pretty
much, was that.
The Hackers Meet SPACEWAR!
By the end of summer, 1961, Steve
Russell had returned to the Artificial
Intelligence Group (he'd worked there
before Littauer); consequently, what ever
ideas the Study Group came up with were
soon circulating among the hackers.
Spacewar! was an appealing, simple
concept, and the hackers
were the appealingly simple people to
bring it to life. First, however, there was
the small matter of software.
The PDP-1 was a no-frills machine at the
beginning; except for a few diagnostic and
utility routines, there was no program
library. In a way this suited the hackers
just fine; here was a chance both to
improve on TX-O software and to write
new stuff that couldn't have been done
before. First, and fairly quickly, MACRO and FLIT and
translated from TXish to PDPese, FLIT
becoming the first in a continuing line of
DDT on-line debugging programs, Steve
Piner PDP-1 wrote a text display and
editing program called Expensive
Typewriter.
With the software taken care of we could
write real programs, which is to say toys.
Bouncing Ball was successfully converted
to PDP-1 use, but HAX for some reason,
was not. But no one really missed it,
because we had a brand-new toy invented
by Professor Marvin Minsky. The program
displayed three dots which proceeded to
"interact," weaving various patterns on
the scope face. As with HAX, the
initializing constants were set in the
console switches. Among the patterns
were geometric displays, Lissajouslike
figures, and "fireworks." Minsky's program
title was something like "TriPos: Three-
Position Display" but from the beginning
we never called it anything but The
Minskytron. ("tron" was the In suffix of
the early 1960s.)
First Steps
By the end of 1961, all the elements were
in place, a brand new, available computer,
a cloud of hackers, tolerant when not
actively implicated employers, and an exciting idea. Slug Russell
was getting the heat from everyone to "do
something" about Spacewar! (I was in a
different department at MIT by this time
and Wayne, alas, was one of those
unlucky Army Reservists called to active
duty during the Berlin Wall panic in
October. He never got to participate in
developing his own idea.)
Russell, never one to "do something"
when there was an alternative, begged off
for one reason or another. One of the
excuses for not doing it, Slug remembers,
was "Oh, we don't know how to write a
sine-cosine routine . . ." Then Alan Kotok
came back from a trip all the way to
Maynard (DEC headquarters) with paper
tapes saying "All right, Russell, here's a
sine-cosine routine; now what's your
excuse?" "Well," says Slug, "I looked
around and I didn't find an excuse, so I
had to settle down and do some figuring."
With the heavy mathematics in hand,
Slug produced the first objectin-motion
program in January 1962. This was
nothing more than a dot which could
accelerate and change direction under
switch control. Even without a hardware
multiply-divide capability (on the early
PDP-1s, anything stiffer than integer
addition and subtraction had to be done
by subroutine) the computer was clearly
not being pushed.
From dot to rocket ship was a surprisingly
easy step. "I realized" Slug says, "that I
didn't have to worry about the speed of
the sine-cosine routine, because there
were only two angles involved in each
frame-one for each ship. Then the idea of
rotating the grid came out." The ship outlines were
represented as a series of direction codes
starting from the nose of the ship; when
the ship was vertical and taildown, each
code digit pointed to one of the five
possible adjacent dots that could be
displayed next. To display the ship at an
angle, Russell calculated the appropriate
sine and cosine and added them to the
original direction code constants, in
effect rotating the entire grid. With this
method, the ship's angle had to be
calculated only once in each display
frame. The outline codes were kept in a
table so that different shapes could be
tried out at will, but this meant that the
table had to be searched every frame to
generate the outline. As the game
developed, this arrangement proved to be
a sticking point which, as we shall see,
was neatly solved by Dan Edwards.
By February, the first game was operating.
It was a barebones model; just the two
ships, a supply of fuel, and a store of
"torpedoes"-points of light fired from the
nose of the ship. Once launched, a
torpedo was a ballistic missile, zooming
along until it either hit something (more
precisely, until it got within a minimum
distance of a ship or another torpedo) or
its "time fuse" caused it to self-destruct.
The classic needle and wedge ship
outlines and the opposite-quadrant
starting positions were established at
this stage, as shown in Figure 1.
Acceleration was realistic; it took time to
get off the mark, and to slow down you
had to reverse the ship and blast in the
other direction; the rocket exhaust was a
flickering "fiery tail."
Rotation, on the other hand, was
by something we called "gyros"-a sort of
flywheel effect invented to avoid
consideration of messy things like
moments of inertia. I guess they were
really rotational Bergenholms.
It was apparent almost immediately that
the featureless background was a liability:
It was hard to gauge relative motion; you
couldn't tell if the ships were drifting
apart or together when they were moving
slowly. What we needed, obviously, were
some stars. Russell wrote in a random
display of dots and the quality of play
improved. The only thing left, we thought,
was hyperspace, and that was on the way:
In fact, we'd just begun.
III. SPACEWAR! COMPLETE
Please keep in mind that what follows did
not happen in a neat first-onething-and-
then-the-next progression, but rather all
at once in a period of about six weeks.
When hackers are aroused, anything that
can happen will.
The Control Boxes
Spacewar! worked perfectly well from the
test word switches on the console, except
that the CRT was off to one side, so one
player had a visual advantage. More to the
point, with two excitable space warriors,
jammed into a space meant for one
reasonably calm operator, damage to the
equipment was a constant threat. At the
very least, a jittery player could miss the
torpedo switch and hit the start lever,
obliterating the universe in one big anti-
bang. A separate control device was obviously
necessary, but joysticks (our original idea)
were not readily available in 1962. So Alan
Kotok and Robert A. Saunders, who just
happened to be members of the Tech
Model Railroad Club, trundled off to the
TMRC room, scrabbled around the layout
for a while to find odd bits of wood, wire,
Bakelite, and switchboard hardware, and
when the hammering and sawing and
soldering had ceased, there on the CRT
table were the first Spacewar! control
boxes (Figure 2. These boxes have long
since disappeared, but the sketch is a
reasonably accurate reconstruction).
The box is wood with a Bakelite top. The
two switches are doublethrow; the button
is a silent momentary switch. Their
functions are as follows:
The Stars of the Heavens
One of the forces driving the dedicated
hacker is the quest for elegance. It is not
sufficient to write programs that work.
They must also be "elegant," either in
code or in functionboth, if possible. An
elegant program does its job as fast as
possible, or is as compact as possible, or
is as clever as possible in taking
advantage of the particular features of the
machine in which it runs, and (finally)
produces its results in an esthetically
pleasing form without compromising
either the results or operation of the
other programs associated with it. "Peter
Samson," recalls Russell, "was offended
by my random stars." In other words,
while a background of miscellaneous
points of light might be all very well
for some run-down jerkwater space fleet,
it just wouldn't do for the Galactic Patrol.
So Peter Samson sat down and wrote
"Expensive Planetarium."
Using data from The American Ephemeris
and Nautical Almanac, Samson encoded
the entire night
(down to just above fifth magnitude
between 221/a degrees N and 22'/z
degrees S, thus including most of the
familiar constellations. The display can
remain fixed or move gradually from right
to left, ultimately displaying the entire
cylinder of stars. The elegance does not
stop there. By firing each displayed point
the appropriate number of times, Samson
was able to produce a display that showed
the stars at something close to their
actual relative brightness. An attractive
demonstration program in its own right,
E.P was "duly admired and inhaled into Spacewar!"
The Heavy Star
Up to this point, Spacewar! was heavily
biased towards motor skills and fast
reflexes, with strategy counting for very
little. Games tended to become nothing
more than wild shootouts, which was
exciting but ultimately unrewarding. Some
sort of equalizer was called for.
Russell: "Dan Edwards was offended by
the plain spaceships, and felt that gravity
should be introduce, pleaded innocence of
numerical analysis and other things"-in other words,
here's the whitewash brush and there's a
section of fence-"so Dan put in the gravity
calculations."
The star blazed forth from the center of
the screen, its flashing rays a clear
warning that it was not to be trifled with.
Its gravity well encompassed all space; no
matter where you were, if you did not
move you would be drawn into the sun
and destroyed. (As a gesture of good will
towards less skillful or beginning players,
a switch option turned annihilation into a
sort of hyperspatial translation to the
"antipoint," i.e., the four corners of the
screen.)
The star did two things. It introduced a
player-independent element that the game
needed; when speeds were high and space
was filled with missiles, it was often
sheer luck that kept one from crashing
into the star. It also brought the other
elements of the game into focus by
demanding strategy. In the presence of
gravity b ships were affected by something
yond their control, but which a skillfully
player could use to advantage.
The first result of this new attention to
strategy was the opening move
in Figure 3, which was quickly dubbed
the "CBS opening" because of its eye like
shape. It took a while to learn this
maneuver but it soon became the Stan
dard opening among experienced players,
as it generally produced the
most exciting games.
The addition of gravity pushed Spacewarl
over the edge of flicker-free display. To get
back under the lim it, Dan Edwards
devised an elegant fiddle to speed up the
outline display routine.
In Russell's original program, the outline
tables were examined and in terpreted in
every display frame, an essentially
redundant operation. Ed wards replaced
this procedure with an outline "compiler,"
which examined the tables at the start of
a game and compiled a short program to
generate the outline for each ship. This
dramati cally reduced calculation time,
restor ing the steady display and making
room for the last of the original bell: and
whistles.
Hyperspace
While all this was going on, I was in my
secret hideaway (then known a: the
Electronic Systems Lab) working on the
ultimate panic button; hyper space. The
idea was that when every thing else failed
you could jump into h e fourth dimension
and disappear, this would introduce an element of
something very like magic into an
otherwise rational universe, the use of
hyperspace had to be hedged in some way.
Our ultimate goal was a feature that,
while useful, was not entirely reliable. The
machinery, we said, would be "the Mark
One Hyperfield Generators . . . hadn't
done a thorough job of testing . . . rushed
them to the fleet"' and so on. They'd be
good for one or two shots, but would
deteriorate rapidly after that. They might
not work at all ("It's not my fault,
Chewie!") or i1 they did, your chances of
coming back out intact were rather less
than even. Slug: "It was something you
could use, but not something you wanted
to use.
The original hyperspace was not that
elegant. "MKI unreliability' boiled down to
this: you had exactly three jumps. In each
jump your ship's co-ordinates were
scrambled so that you never knew where
you would reappear-it could be in the
middle of the sun. You were gone for a
discernible period of time, which gave your
opponent a bit of a breather, but you came
back with your original velocity and
direction intact. To jump, you pushed the
blast lever forward.
Hyperspace had one cute feature (well, I
thought it was cute). Do you remember
the Minskytron? One of its displays looked
very much like a classical Bohr atom,
which in those days was an overworked
metaphor for anything to do with space
and sciencefiction. Reasoning that a ship
entering hyperspace would cause a local
distortion of space-time resulting in a
warp-induced photonicstress emission
(see how easy this is?), I made the
disappearing ship leave behind a short
Minskytron signature (Figure 4).
Crocks and Loose Ends
In retrospect, it is remarkable that the
original Spacewar! managed to include so
many features, given the limitations of our
PDP-l: 4K words (about 9K bytes) of
memory, an instruction cycle time of five
microseconds, and a subroutine multiply-
divide. It's hardly surprising, then, that we
had to let a few unsatisfactory (all right,
inelegant) bits go by.
The most irritating of these (and the first
to be improved in later versions) was the
appropriately-named Crock Explosion.
Something dramatic obviously had to
happen when a ship was destroyed, but we
were dealing with a plain dot-matrix
screen. The original control program
produced a random-dot burst confined
within a small square whose outlines
were all too discernible (Figure 5).
This explosion was intended merely as a
place-holder until something more
plausible could be worked out, but after all
the other features had been "inhaled,"
there wasn't room or time for a fancier
calculation.
Similarly, the torpedoes were not quite
consistent with the Spacewar! universe
after the heavy star was in place. The
gravity calculations for two ships was as
much as the program could handle; there
was no time to include half a dozen
missiles as well. So the torpedoes were
unaffected by the star, with the odd result
that you could shoot right through it and
hit something on the other side (If you
weren't careful getting round the Star, it
could be you.). We made the usual
excuses . . . mumblemumble photon
bombs mumblemumble . . . but no one
really cared.
The heavy star itself was not entirely
Newtonian. The common tactic of plunging
down the gravity well to gain momentum
by whipping around the sun (Figure 6) gave
you somewhat more energy than you were
really entitled to. As this just made the
game more interesting, nothing was immediately
done to correct it.
IV. AFTER SPACEWAR
The game was essentially complete by the
end of April, 1962. The only further
immediate work was to make Spacewar!
presentable for MIT's annual Science
Open House in May. A scoring facility was
added so that finite matches could be
played, making it easier to limit the time
any one person spent at the controls. To
provide for the crowds that we (accurately)
anticipated, a large screen laboratory CRT
was attached to the computer to function
as a slave display. Perched on top of a
high cabinet, it allowed a roomful of
people to watch in relative comfort. Also in
May, the first meeting of DECUS (Digital
Equipment Computer Users' Society) was
held in Bedford, MA. At that meeting I
delivered the first paper on the subject,
pretentiously titled " Spacewar! Real-Time
Capability of the PDP-1."
Over the summer of 1962, the original
Spacewar hackers began to drift away.
Alan Kotok and I went to work for Digital.
Steve Russell followed John McCarthy to
Stanford University. Peter Samson and
Bob Saunders stayed in Cambridge for a
while, but eventually they, too, went west.
Dan Edwards remained with the AI group
for a few years, then moved to Project
MAC, Jack Dennis and the PDP-1 also
wound up at Project MAC, which evolved
into MIT's Laboratory for Computer
Science. Others took up the maintenance
and development of Spacewar! Program
tapes were already showing up
all over the country, not only on PDP-ls
but on just about any research computer
that had a programmable CRT
A Mystery Just For Good Measure
Slug tells me that there is a Lost
Version of Spacewar! There would be, of
course. He says the game is pretty much
like the original, but the scoring is much
more impressive. After each game of a
match, cumulative scores are displayed
as rows of ships, like a World War II
fighter pilot's tally. Slug says he saw this
version for a short time on the PDP-1,
but never found out who produced it or
what became of it.
Twenty Years Later
The original Spacewar PDP-1 was retired
in 1975 and put in storage at DEC's
Northboro warehouse, where it serves as
a parts source for the similar machine
now on working display at Digital's
Computer Museum in Marlboro, MA. At
this writing, DEC engineer Stan Schultz
and I are trying to put the original
Spacewar! back into operating condition.
So far, all attempts at finding the
original control boxes have been futile;
we will probably build replicas (the
plastic Atari joysticks we have now got
no class).
Dan Edwards still works for the U.S.
Government, developing computer
security systems. Alan Kotok is still a
consulting engineer with DEC. Peter
Samson is now director of marketing for
Systems Concepts, Inc., in San
Francisco. Bob Saunders had gone to
Silicon Valley, where he is an engineer-
programmer for HewlettPackard.
Jack Dennis is a Professor of Computer
Science at MIT, in the Laboratory
thereof.
Marvin Minsky is Dormer Professor of
Science in the Electrical Engineering
Department at MIT.
John McKenzie, the chief engineer, is
retired, but over the past year or so has
been helping to restore the TX-O and
PDP-1 to life at the Computer Museum.
And what of the Hingham Institute?
Wayne Wiitanen has recently become a
Senior Research Scientist at the General
Motors Research Laboratory, where he is
happily designing eyes for robots. Slug,
after various adventures, is now a
programmeranalyst for Interactive Data
Corporation in Waltham, MA. I am
reduced to writing for a living, but tend
to act somewhat less superior therefor.
Spacewar! itself has bred a race of
noisy, garishly-colored monsters that
lurk in dark caverns and infest pizza
parlors, eating quarters and offering
degenerate pleasures. I think I know a
few former hackers who aren't the
slightest bit surprised.
Acknowledgements
I was able to reach all of the original
Spacewar! perpetrators, hackers and
Hingham Institute Fellows alike. Not to
mention Professors Dennis and Minsky,
and John McKenzie. In addition, I am
grateful to Marcia Baker, Professor F J.
Corbato, and Professor R.M. Fano, all of
MIT, for help with dates and places, and
other facts. The help was theirs; any
mistakes are mine.
Reprinted with permission from Creative Computing,
39 E. Hanover Avenue, Morris Plains, NJ 07950K
Ted Bonn, April 17, 1983
While I was at the Moore School of Engineering at The University of Pennsylvania, I took a
course with John Mauchly. Then, after I received my Masters degree, Eckert made me an
offer. In early September 1947, I climbed to the second floor over a haberdashery in
downtown Philadelphia and started to work in the offices and labs of the Eckert-Mauchly
Computer Corporation.
Since available acetate base tape
materials and magnetic laquer coatings were not good enough, I was assigned to develop
plated thin film metal magnetic recording tape for the Universo I. We chose 1/2" wide
phosphor bronze tape as the substrate. I knew nothing about plating or magnetic alloys. My
starting point was the fact that someone in the Brush Development Company had learned
how to electroplate nickel iron permalloy and someone at the Bureau of Standards had
learned how to deposit permalloy chemically without current. Since plating was a chemical
process I obviously needed a lab with a fume hood, water
drains and so forth. One powder room became my lab and the other was left for its intended
purpose. The window would be opened to clear out fumes. I would get water out of the sink
and the toilet was an ideal drain. Of course, I had to be sure to flush a couple of times when
I dumped in acids so that they would not eat the pipes. Being an electrical engineer I would
frequently miscalculate the amount of ammonium salts needed and the room would fill with
fumes. Then I would throw up the window and stick my head out. But occasionally the door
would be opened and the wind would be blowing in the wrong direction,
then all Eckert-Mauchly would fill with ammonia fumes.
The chemistry went faster than the electronics. We could deposit a film before we could
measure its magnetic properties. We made a piece about three feet long, soldered the ends
together to make a loop and mounted it on a loop tester. We tried to record on it. John
Mauchly was excited and right at my shoulder. No output. I checked the electronics, and the
head, and the write current. Still nothing. Then John remarked that there appeared to be a
signal at the joint where the two ends of the tape were soldered. I had seen it
too, but it didn't look like a recording signal and I ignored it.
John correctly interpreted it as
a signal caused by improved magnetic properties due to the heat of soldering. His astute
observations started me on a series of experiments on heat treating tape. It was not the
final answer, but it was a key answer along the way.
I built a pilot production line and Reed Stovall built and debugged the actual production
equipment. The same thin electroplated magnetic film was used by Univac on the LARC
drum and on the Fastrand, and many other recording drums and discs throughout the
industry. Plated tape was used exclusively with the Univac systems until about 1956 or 1957
when mylar base and epoxy resins became available.
You could see the holes in cards, but we had difficulty convincing some people that there
was actually information recorded on the tape, since there is no visible difference between
recorded and unrecorded tape. So we made the recording visible. Fine magnetic particles
were suspended in a solvent and applied to the tape. The particles were attracted to the
magnetic poles and when the solvent evaporated you could clearly see the recorded
information. The tracks and the interblock gap stood out. You could pick the pattern up with
scotch tape and apply the tape to paper and carry it around to demonstrate.
The design of the tape handler, called "Universo," set the standard for the industry. It
featured 100 inch per second tape speed; 120 bits per inch recording density; eight tracks on
halfinch wide tape for a data rate of 12,000 characters per second; a start/stop time of 10
milliseconds, this meant the 720 digit block could be recorded in 5.6 inches and the
interblock gap was only 2.4 inches long. Thus the Eckert-Mauchly team established magnetic
tape as the high speed input/ output medium for computers and designed and successfully
produced a complete line of magnetic tape based peripherals.
This narrative explanation given by Ted Bonn at a Sunday Bits and Bites talk corrects
misinformation printed in the Summer Report (Page 16) describing the UNIVAC tape.
Captain Grace Hopper
on the
Harvard Mark I
April 14th, Captain Grace Hopper
spoke on her experiences with Commander Howard Aiken
and the Harvard Mark 1. The text of this lecture
will be incorporated into her contribution to a book on the same sub-
ject that is being edited by Professor
I. Bernard Cohen.
Speaking to a rapt audience of more than 500 people, Captain
Hopper told of her introduction to the machine: "Aiken waved his
hand at Mark I, all 51 feet of her, and he said, 'That's a computing
engine.' Not a computer. Not a calculator. And there's a difference in
the concept that was in his mind as well. Computers are what we
have nowadays, black boxes, one unit, one thing. Calculators were
those wonderful things you sat on your desk and then you ground
out the answer, you moved the register, ground some more. I think
when he said computing engine, he was referring to its different
parts that took on different functions. That's a concept we've lost
that we'll need to bring back again, because we'll be building
systems of computers with different functions. He was right when
he called Mark I a computing engine; it had many parts that worked
simultaneously together with each other and performed functions."
"Howard Aiken was a tough taskmaster. I was sitting at my desk one
day and he came up beside me, and I got on my feet real fast. He
said, 'You're going to write a book.' I said, 'I can't write a book.' He
said, 'You're in the Navy now 'And so I wrote a book. I have it here
with me so that I can answer any questions. This is the Mark I
manual, the entire bible for Mark I. You could take this and build
Mark I again, if anyone felt like it."
Return to List of Reports
The Director's Letter
Director
The Origin of Spacewar
Picture of SpaceWar! on PDP-1 CRT
With the Fenachrone hot on our ion track,
Wayne said, "Look, you need
action and you need some kind of skill
level. It should be a game where you have
to control things moving around on the
scope, like, oh, spaceships. Something
like an explorer game, or a race or contest
. . . a flight, maybe?"
With the control boxes players
could sit comfortably apart, each with
a clear view of the screen. That, plus
the carefully designed layout of the
controls, improved one's playing skills
considerably; making the game even
more fun.
Developing Univac's Plated Thin Film Metal Recording Tape