The Origin of Spacewar!


The Origin of Spacewar

J. M. Graetz

This article is reprinted from the August, 1981 issue of Creative Computing magazine (Volume 7, Number 8).

The following notice was required by Creative Computing magazine's policy for free reprints in newsletters and nonprofit publications:
Copyright © 1981 by Creative Computing, 39 E. Hanover Ave., Morris Plains, NJ 07950.
Sample issue $2.50, 12-issue subscription $20.
(Please note that Creative Computing went out of business in 1985.)

Notes on the Edition:
This copy is based on the copy available at
and the reprint in
The Computer Museum Report, Fall 1983; (ISSN 0736-5438), pp. 6-12,
The Computer Museum, One Iron Way, Malboro, Massachusetts 01752,
as available at
This edition attempts to provide the most complete version of the text possible. While the edition of The Computer Museum Report (TCMR) mostly shows text deletions, it also provides a few vital additions and a more reasonable arrangement of text. Text modifications based on the TCMR and differences between the two text versions are marked up in the page source.

(If active, sections specific to the Creative Computing edition are marked up "CC", while sections specific to The Computer Museum Report are marked up "TCMR".)

The text is derived from the original HTML-page and was corrected by comparing it to the original as preserved in the PDF available at The illustrations are as in the edition at


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 American-International 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. These stories are pretty much all of a piece: after some preliminary foofaraw to get everyone's name right, a bunch of overdeveloped Hardy Boys go trekking off through the universe to punch out the latest gang of galactic goons, blow up a few planets, kill all sorts of nasty life forms, and just have a heck of a good time.

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 through the trackless wastes of the galaxy (he wrote like that) by assorted Fenachrone, Boskonians, and the World Steel Corporation.

Is that enough to turn the mind to margarine? It is not. In breaks between books, we would be off to one of Boston's seedier cinemas to view the latest trash from Toho. In the days before Mazdas and Minoltas, the Japanese (and occasionally the British and Californians) churned out a steady diet of cinematic junk food of which Rodan and Godzilla are only the best known examples. 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 for various Harvard persons. The agent of choice for this work was 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 (along with UNIVAC) as the type specimen of what a computer was: a collection of mysterious hulking gray cabinets approachable only through the intercession of The Operator. In the specially built computer room, The Operator set switches, pushed buttons, and examined panels of flashing lights, while his Assistants attended various whirring, clanking, and chattering devices, rushing to and fro with stacks of cryptically-printed paper, decks of weirdly-punched cards, and reels of recondite brown ribbon, all to the background hum of The Machine. Add a little incense and a few candles, and you could be forgiven for thinking these were the rites of some oracular shrine.

Everything about the 704, from the inscrutable main frame to the glowing tubes (yes, 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 mean that I had joined the ranks of the Real Programmers.

While hardly your average populist Apple, the TX-O 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.

So here was the former 704 Operator's Assistant pushing buttons, flipping switches, and pressing keys to make his own programs work. In some ways it was simpler than the 704; for one thing, there wasn't a battery of clanking mechanical monsters. The TX-O's input and output medium was something called a Flexowriter: an all-in-one 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. Now 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. (The importance of these two devices can't be overemphasized; Ivan Sutherland used the scope and the pen to develop his original "Sketchpad.")

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. Many of them worked for Professors John McCarthy and Marvin Minsky in the Artificial Intelligence Group, an odd bunch (even by MIT standards) who seemed convinced that given enough random-access memory and a really fast cycle time you could model the cognitive parts of the brain and hey presto! a real thinking machine. Others worked for Professor Dennis, who presided over the use and development of the TX-O and more or less benignly kept a semblance of order. The man who kept it all running was a soft-spoken, white-haired gentleman, John McKenzie, the chief engineer.

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 MIDAS Debugger; Robert A Saunders (TX-O staff), who wrote the 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 for only so long. They just did the same dull thing over and over; besides, they were obviously mechanical — at best, overgrown record changers — and thus not mysterious. The main frame, which did all the marvelous work, just sat there. There was nothing to see.

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.

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. Well-chosen 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 Tic-Tac-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 no-shows called the PDP-2 and PDP-3, in case you had been 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.


The PDP-1.


The Hingham Institute Study Group On Space Warfare

Long before the PDP-1 was up and running, Wayne, Slug, and I had formed a sort of ad-hoc committee on what to do with it — it being 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. Why not? Zooming across the galaxy with our Bergenholm Inertialess Drive, the Hingham Institute Study Group on Space Warfare devised its Theory of Computer Toys. A good demonstration program ought to satisfy three criteria:

It should demonstrate, that is, it should show off as many of the computer's resources as possible, and tax those resources to the limit;
Within a consistent framework, it should be interesting, which means every run should be different;
It should involve the onlooker in a pleasurable and active way — in short, it should be a game.

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 fight, maybe?"

"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 the summer of 1961, Steve Russell had returned to the Artificial Intelligence Group (he'd worked there before Littauer); consequently, whatever 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 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 were translated from TXish to PDPese, FLIT becoming the first in a continuing line of DDT on-line debugging programs. Steve Piner wrote a text display and editing program called Expensive Typewriter (For a while, "expensive" was a favorite adjective for naming various PDP-1 routines that imitated the functions of more mundane devices. Among them was Peter Samson's E. Planetarium, as we shall see.), another original whose lineage you can trace, if you like, right down to the latest word processors.

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, Lissajous-like figures, and "fireworks." Minsky's program title was something like "Tri-Pos: 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 head 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 have a sine-cosine routine and gee, I 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 object-in-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 tail-down, each code pointed to one of the five possible adjacent dots 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 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 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 space 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.

Spacewar opening screen

Figure 1. The Starting Position. The ships are in the centers of diagonally opposite quadrants. The vee of stars at top center is the horns of Taurus. You should be able to pick out the stars of Orion at the left (the bright star just above the wedge-ship is Rigel).

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.


Please keep in mind that what follows did not happen in a neat first-one-thing-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).

Line drawing of control box

Figure 2. The original control boxes looked something like this. The
controls are a) right-left rotation, b) acceleration (pulled back) and
hyperspace (pushed forward), and c) torpedo button.

The box is wood with a Bakelite top. The two switches are double-throw; the button is a silent momentary switch. Their functions are as follows:

Rotation control. It is pushed to the left to rotate the ship counterclockwise, to the right to rotate clockwise.
A two-function control. Pulled back it is the rocket accelerator; the rocket continues to blast as long as the switch is thrown. Pushed forward, the switch is the hyperspace control, as described below.
The torpedo button. It had to be silent so that your opponent could not tell when you were trying to fire. (There was a fixed delay between shots "to allow the torp tubes to cool" and fire was not automatic; you had to keep pushing the button to get off a missile.)

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 ones playing skills considerably, making the game even more fun.

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 function — both, 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 aesthetically pleasing form without compromising either the results or operation of 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 sky (down to just above fifth magnitude) between 22½° N and 22½° 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 display 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 introduced. I 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 "anti-point," 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 both ships were affected by something beyond their control, but which a skillful 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 standard opening among experienced players, as it generally produced the most exciting games.

The CBS Opening

Figure 3. The "CBS Opening." The ships turn slightly away from the star and fire a short rocket blast (note the needle-ship's exhaust) to get into a comet-type orbit, then rotate the other way to try shooting torpedoes at the opponent.

The addition of gravity pushed Spacewar! over the edge of flicker-free display. To get back under the limit, Dan Edwards devised an elegant fiddle to speed up the outline display routine.

In Russell's original program, the outline tables were examined and interpreted in every display frame, an essentially redundant operation. Edwards 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 dramatically reduced calculation time, restoring the steady display and making room for the last of the original bells and whistles.


While all this was going on, I was in my secret hideaway (then known as the Electronic Systems Lab) working on the ultimate panic button: hyperspace. The idea was that when everything else failed you could jump into the fourth dimension and disappear. As 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 if 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. "MK I 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 science-fiction. 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).

The Hyperspace Minskytron signature

Figure 4. "Warp-induced photonic stress emission." The Hyperspace Minskytron signature.

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-1: 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).

The Crock Explosion

Figure 5. The Crock Explosion. Nobody's perfect.

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.

using the star's gravity

Figure 6. A common mid-game flourish — and don't talk about G-forces!


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-1s 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 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 Hewlett-Packard.

Jack Dennis is a Professor of Science in the Electrical Engineering Department at MIT.

Marvin Minsky is Donner 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 programmer-analyst for Interactive Data Corporation in Waltham, MA. I am reduced to writing for a living, but tend to act somewhat less superior therefore.

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.


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.


The following sections are not part of the original article.

While you here, don't miss to see the real thing (hml5/JavaScript emulation of a PDP-1 running Spacewar!, various versions, original code): Play Spacewar! online:

Use this short-cut link to play the exact version described in the article:
Play Spacewar! 2b (Spacewar! 2b patched to include the original hyperspace-routine).

A1. Additional Notes and Annotations

The version described in this article is Spacewar! 2b with some patches applied, namely the original "Minskytron hyperspace", identified as the "hyperspace85.bin"-patch and an auto-restart patch (unpatched Spacewar! 2b had to be restarted manually after each game). The scoring facility mentioned in the article was probably added by applying another patch to the game. (This scorer was presumingly much like the score-keeper in Spacewar! 3.1 which would halt the program and display scores in binary using the neons of the accumulator and the I/O register on the control console of the PDP-1.)
The source code of Spacewar! 2b and the patches are available here.
Read more about the story of its rediscovery here.


"MIT's annual Science Open House in May" was actually the annual Parents' Weekend, Saturday 28 – Sunday 29, April 1962. (Compare the announcement in "The Tech" below.


The full citation of the paper on Spacewar! mentioned in the article is:
J. M. Graetz, "Spacewar! Real-Time Capability of the PDP-1", DECUS Proceedings 1962: Papers and Presentations of the Digital Equipment Computer Users Society, (Maynard, Massachusetts, 1962), 37-39


It might be worth noting that, contrary to the "crock explosion" described in the section "Crocks and Loose Ends", the final implementation featured perfect pixel-dust explosions with particles attractively decaying by the Type 30 CRT's dual P7 phosphor. This perfect visual effect was achieved by the change of just a few instructions.

Spacewar 3.1 explosion (emulation)

Two spaceships exploding in the "heavy star" (Spacewar! 3.1, emulation)


Another notable attainment of Spacewar! was Steve Russell's code prototyping object-oriented programming avant la lettre by iterating over task-specific routines (later to be called "methods") linked in an object table. Changing an objects state was simply achieved by linking another handler routine into the table.


The scoring display mentioned in the article ("like a World War II fighter pilot's tally") was probably added in 1963 as a patch to version 4.8 ("scorer patch"). Also, there is a branch of version 4.2 - 4.4 featuring a similar scorer. While these show some differences in visuals and code, these are triggered by quite the same hook.


The background-display and the the starfield (Expensive Planetarium) are marked in the code as of 3/13/62.
Spacewar! 3.1 and most versions of Spacewar! 4 displayed the stars in 4 levels of brightnesses (CRT intensities) and refreshed them only every second display cycle (with the long sustain of the Type 30 CRT Display's P7 phosphor providing the lasting glow required for a visually stable image).
The original starfield implementation in Spacewar! 2b (as well as a branch of 4.2 - 4.4) used only a single display intensity, but modulated brightnesses by how often the individual stars would be refreshed (with the Type 30 CRT's P7 phosphor again providing the sustain required for the fading effect), as described in the article.


The Minskytron (Marvin Minsky's "Tri-Pos: Three-Position Display") can be seen here running in an in-browser emulation: The Minskytron and Other Early Graphics Demos at the PDP-1.


There are two images of the "Hyperspace Minskytron signature" in the TCMR-version of the article that are exclusive to this edition (the first shows a different crop and orientation, the second one is totally exclusive):

Spacewar: Minskytron Hyperspace image in TCMR, Fall 83 (1)
Spacewar: Minskytron Hyperspace image in TCMR, Fall 83 (2)

Moreover, there is the following image in the TCMR-edition, showing Alan Kotok, Steve Russell, and J. M. Graetz at the PDP-1 (image credits are probably: J.M. Graetz):

Alan Kotok, Steve Russell, and J.M. Graetz at the PDP-1 (Spacewar!)

Gleefully playing Spacewar! at a spring Bits and Bites talk are (left to right) Alan Kotok, Steve Russell and Shag Graetz. Spacewar!, the first video game and one of the Museum's software artifacts, was designed for a PDP1 by Graetz, Russel and Wayne Wiitanen in 1961.

The photo was probably taken at the 20th anniversary reunion at the Boston Computer Museum in 1981.
(Please mind the Atari™ joystick in Steve Russell's hands.)
Note: The original caption in The Computer Museum Report spells: Wittenan.


The passage, "J. Martin Graetz (which is me), man of no fixed talent who tended to act superior because he was already a Published Author", seems to refer to the SF novelette "Building 9" by J. Martin Graetz (in: The Original Science Fiction Stories, July 1959, Volume 10, No. 3; pp. 99–112).
Here is a summary by

In the 1950s the Massachusetts Institute of Technology has secret laboratories and classes dealing with magic. These are kept hidden from the majority of the Institute as well as from the public. This is finally discovered and brought into the open by members of the M.I.T. Science Fiction Society under some bizarre circumstances. The author was class of 1958 at M.I.T. in course V (chemistry). [The college is never referred to as the Massachusetts Institute of Technology but the characters are named after MITSFS members of the time and the geography and numbering of the buildings are that of M.I.T. as of that time. Currently, there is a Building 9, but it is in the wrong place.]

Sadly, as of writing this, the text is not available for public download.
However, if this reminds a bit of Harry Potter, compare the MIT-Hack of November 2005 on Building 9(¾).

(N.L. 2013-2016)

A1-B. PDP-1 Plays At Spacewar! – The Official Birth Announcement

In April 1962 the following tongue-in-cheek style text was published in the very first issue of “Decuscope – Information for Digital Equipment Computer Users”:

Decuscope – Information for Digital Equipment Computer Users
Vol. 1 No. 1, April 1962, pp 2 and 4
PDF-copy at:


          by D.J. Edwards, MIT
                J.M. Graetz, MIT

If, when walking down the halls of MIT, you should happen to hear cries of "No! No! Turn! Fire! ARRRGGGHHH!!," do not be alarmed. Another western is not being filmed — MIT students and others are merely participating in a new sport, SPACEWAR!

Planned and programmed by Stephen R. Russell under the auspices of the Hingham Institute Study Group on Space Warfare, SPACEWAR is an exciting game for two players, many kibitzers, and a PDP-1.

The game starts with each player in control of a spaceship (displayed on PDP's scope face) equipped with propulsion rockets, rotation gyros, and space torpedoes. The use of switches to control apparent motion of displayed objects amply demonstrates the real-time capabilities of the PDP-1.

Also displayed on the scope is a central sun which excerts a gravitational influence on the spaceships. The entire battle is conducted against a slowly moving background of stars of the equatorial sky. The object of the game is to destroy the opponent's ship with torpedos. The computer follows the targets and participants have an opportunity to develop tactics which would be employed in any future warfare in space.

Your editor visited the MIT Campus in Room 26265 and can verify an excellent performance. She learned that the best "Aces" had only a 50% chance of survival. Enthusiasm nevertheless ran high and the battle continued while young Mr. Russell trued to explain his program.

"The most important feature of the program," he said, "is that one can simulate a reasonably complicated physical system and actually see what is going on."

Mr. Russell also said that symbolic and binary tapes were available. Please contact Mr. Russell for additional information.

A1-C. Spacewar! at the MIT Parents' Weekend, Sat. 28 / Sun. 29 April, 1962

The April 25, 1962 issue of MIT's magazine "The Tech" announced the public showing of Spacewar! at MIT's Parents' Weekend the following weekend on Sat. 28 / Sun. 29 April, 1962 by the following article.
The Tech
Vol. 82, Issue 11, April 25, 1962, p.11
PDF-copy at:

Change Course!           Fire Torpedoes!

Space Battles Fought With Computer

By Jeff Levinger

Spiraling near the sun for added acceleration, the thin silver ship swiveled slowly, firing its space torpedoes steadily, creating a spiral wave of death ahead of it. As it swept past the sun, a hail of answering rockets flashed by, barely missing, and the sudden explosion of another ship lit the space behind. The scope flickered, and the two ships appeared again at diagonally opposed points with the sun as a center. The controls for each changed hands, and the game began anew.

The game is Space War, played on the display screen of the PDP-1 computer in 26-260, with the aid of a program written mainly by Steve Russell of the Harvard Computation Center. Two former MIT students presently working for the Electronic Systems Laboratory, Shag Graetz and Pete Samson, also worked on the program and supplementary software. Each person controls his ship with an acceleration button and a rotation switch, acceleration and orientation being constant while the proper control is on.

The central sun (there is an entire background of stars, accurate to fifth magnitude on the equatorial plane) is the only one with gravity .... and if you fall in, you reappear at the corner from which you are accelerating. Losing (exploding) is a large luminescent square where your ship was, which appears if your ship is hit by a torpedo or the other ship.

The original game was to orbit around the sun without falling in, and then to destroy the other ship with a limited number of torpedoes and a long reload time between shots. One danger (since reprogrammed) which destroyed many a hopeful skipper was due to the fact that torpedoes ignored the sun: and running into your own torpedo as you orbit is a rather humiliating defeat.

It is possible to go beyond the pace pictured, in which case you wind up coming out of a new corner to begin again. This is known as the curvature of space. Torpedo number, duration, and reload speed (no machine-gunning) are variable, easily adjusted for beginners or experts.

For Parents' Weekend the PDP-1 will run this game for parents and their Techmen between 12 p.m. and 6 p.m., with a special version designed for this purpose. As an example of the whimsical uses of computers this is some-thing parents shouldn't miss. As a simplistic preview of future war games, it might well be classified were this report to fall into the wrong hands.

A2. Steve Russell on the Origins of Spacewar!

Several years later, on May 15th, 2006, Steve Russell gave the following account of the origins of Spacewar! on the occasion of the Computer History Museum's (CHM) The Mouse that Roared: PDP 1 Celebration Event:

Marvin Minsky had written a little program that puts some dots on the display and ran them around, but it didn't do very much and you puttled on the switches looking for different starting values to get an interesting pattern, but most of them didn't work very well. So, it didn't have, what we call now good play value.

And I thought, it would be possible to do a much better demonstration of what you could do with a display. At the time the space race was very much in the news and I realized that people didn't know how space ship maneuvered really. You know, they thought sort of in terms of airplanes or something. So I started talking up doing a space simulator of some kind. And eventually we figured out that we could have a couple of spaceships and arm them with torpedoes, which could shoot down other torpedoes and spaceships, so they made a very sort of universal weapon – and simple.

I kept talking this up and eventually Alan [Kotok] went out on an expedition to Maynard and came back with the sine and cosine routines and sort of plopped them down in front of me and said: "All right, Russell, here are the sine and cosine routines; now, what's your excuse?" So I actually had to sit down and do some thinking. And I wrote up a program that [audio glitch] two spaceships, but it didn't have any gravity and it didn't have any stars. And we played that for a while; it was kind of interesting.

And then Peter [Samson] wrote Expensive Planetarium — another one of those expansive programs: A planetarium in two pages, plus the star charts, two pages of code. So that got incorporated in. And then Dan Edwards took the outline interpreter that I had written, and took the same outline description, but compiled custom code, which displayed the spaceship outlines exactly as fast as the display could display them. And that gave him enough time to calculate two extra square roots to calculate the influence of gravity on the spaceships. And this gave us a problem, because the torpedoes … — there wasn't plan to calculate the influence of gravity on the torpedoes. So, we introduced another piece of technology, which was the photon bombs, and they weren't affected by gravity.

And then it turned out that especially beginning players had a lot of problems with getting trapped in clouds of torpedoes and blowing up, so we decided that we would rush from the development labs to hyperspace. So, if you said rotate left and rotate right at the same time, your spaceship disappeared, which got you out of the storm of torpedoes, and then re-appeared somewhere else randomly with random velocity. But it turned out that made it too easy to escape, so we realized that the laboratories hadn't really finished the development of the hyper-field generators: They were unreliable. In fact, the probability of blowing up, when you came out of hyperspace, was about one eight. And in fact nobody ever survived more then seven trips to hyperspace!

That got done in the spring of '62, and that's essentially what you can see downstairs [at the CHM's exhibition]. And for about two years it was the world's most popular computer game — because it was the only one.

Transscript of, (1:11:17 – 1:15:40)

In August 2008 Al Kossow recorded an oral history interview with Steve Russell, who provided further insight regarding the internals of Spacewar! on that occasion:

Al Kossow, Excerpt of an oral history of Steve Russell
August 2008
CHM Reference Number X4970.2008
CHM Catalog Number 102746453
© 2008 Computer History Museum (CHM)

CHM catalog entry:
(Other copies in HTML my be found at and at!topic/alt.folklore.computers/7tjg74Oux2Y.)
Anyway, the PDP-1 arrived, and Marvin Minsky wrote the tripos demonstration, generally called the Minskytron, and there was the famous weekend where the mob of undergraduates transcribed the macro assembler from TX-O to the PDP-1, because they didn't like FRAP. And then fairly quickly thereafter, they wrote DDT and connected up the macro symbols to DDT. So that was all sort of in place by the middle of the fall of 1961. And the combination of the Minskytron and having DDT with interactive debugging with symbols was very tempting. I don't remember the exact order of things, but I'm pretty sure I started talking up a better demonstration program than the Minskytron, and eventually, Alan Kotok went up to Maynard and collected the sine and cosine routines from DECUS, presented them to me, and said, "Okay, here are the sine and cosine routines; now what's your excuse?" And I discovered I had run out of excuses; I had to actually think. And so I started work and figured out the basic trick of Spacewar! display which is that you only need to calculate a unit vector pointing in the direction of the spaceship. And you can express everything else the spaceship does, and the outline of the spaceship in terms of that unit vector, suitably scaled. So it's basically a lot of addition in the usual program upkeep.
Do you want to just give an overview, then, of how Spacewar! actually works?
It's one big loop, and the loop is on the displayable objects. And I called them displayable objects, although I didn't know about object orientation or object-oriented programming at the time.
So you have the sun—
Colliding objects, not displayable objects. The colliding object is a space ship, there are two of those. And that has a lot of extra data with it. It shares the position and velocity tables with all of the torpedoes and explosions that are running around. So there's just one big loop through the colliding objects, and it looks at all the higher-numbered colliding objects to see if there's a collision, using an octagon because you don't need to calculate the square root of anything, you can do that by work on X difference, Y difference, and X+Y difference—
So the bounding box for the collision detection is an octagon?
Yes. So it goes through, it sees if this object is colliding with any higher-numbered object. If it is, it replaces the calculation routines. That's another thing that every colliding object has, is a calculation routine. It replaces the calculation routine with the explosion calculation routine. And then things take care of themselves. Then, after it's decided whether it's an explosion or not, it goes off to the calculation routine. And the calculation routine updates the position, since all colliding objects have velocity; and if it's a spaceship, it worries about reading the controls and updating the other things about the spaceship in deciding whether to launch a torpedo or not. And if a torpedo needs to be launched, it searches up the colliding object table for an empty slot, indicated by having no calculation routine. It searches up the table for an empty slot, puts a torpedo calculation routine there, and the spaceship position plus the suitable increments, so it won't run into its torpedo, and of the velocity of the spaceship plus an increment for the torpedo, and it goes on. When that the main loop gets done, you go off and do some star display and display the sun, and calculate — and part of the spaceship calculation is to calculate the effect of gravity on the spaceship. Originally, there wasn't any gravity, and I had an interpreter, which interpreted the outline description, and Dan Edwards, sometime in late 1961 or early 1962, looked at that code and decided if he could write a special purpose compiler which would compile precisely the right code, and proceeded to. And there's one compiled outline for each spaceship; each spaceship actually does half of the spaceship outline and then you twiddle the vectors and do the other half. That keeps the display running just as fast as it can. That gives time to calculate the effect of gravity on the two spaceships, but not on the torpedoes. So we decided that they were photon torpedoes not affected by gravity.
So when the explosion routine starts, it continues calculating motion, so the explosion moves?
Yes. If you see two spaceships collide, if you watch closely, you will see that there are two explosions that continue off in the direction that the two spaceships were going. There is another number in the table for all colliding objects, which is the size. And this is, roughly speaking, proportional to the amount of computing it takes to compute that object. And at the end of the loop, as you go through the main loop, you accumulate the sizes also; and so at the end of the loop, there's fritter away time loop that attempts to keep the frame rate approximately constant. It doesn't do a wonderful job; it's visually adequate, but God help you when you try to take a movie of it.
One of the complaints with all modern kids trying to play it now is that it's TOO SLOW.
Kids who are used to something like Asteroids seem to think that. But when we do the demos, we get a number of people who seem to be still quite addicted to it with the old, slow version. Now, that was always a complaint; the reason that all the parameters got accumulated in the first page of the listing, which says you can put that first page of the listing of the console, and anyone who wanted to try a different set of parameters could. But the ones that were compiled in or assembled in were the ones that I thought were good. Now it turns out I'm not a representative arcade game player, and so my version of the parameters is slower and gives more opportunity for marksmanship than the arcade version.
Right, that's the whole thing with gravity and doing the, what's that called, where you whip around the sun? Does it have a name, where you whip around the sun and you shoot?
The closest name is the "CBS maneuver" is what happens when two lazy experts fight each other, which is they both turn at right angles to the sun, and fire for 3.5 or 4 seconds, so they're now in stable orbits, and they know it. And then they turn at each other and start trying to place torpedoes where they think the other one is going to be. And so the trails turn into an eye around the sun, and CBS used that as a logo, so it got called the "CBS maneuver". You can— one of the spaceships can go the other way around the sun, so that both ships meet on the same side of the sun. But that seems usually to have less chance of winning. Not much less, but somewhat less.
It's better that you stay on opposite sides, then?
And then at some point, you added hyperspace?
Yes, and we realized that that was going— I don't remember whether we actually had it. I may have had it for a little while with no limit, but it became very clear that someone who didn't understand could use hyperspace to escape their proper justice forever, and so we added the unreliability of hyperfield generators very quickly. One thing that Asteroids and the arcade versions, the later arcade versions of Spacewar! added, which actually was a big help, especially with their high acceleration rates, was "training mode" where space was actually viscous. So if you got your ship accelerated so that it was going across the screen so fast you couldn't understand what was going on, if you took your hands off, the situation would gradually become understandable. I don't think I would have been persuaded to do that in the original Spacewar! because it was unrealistic. But it definitely made it easier to learn.
So are there any other favorite anecdotes about Spacewar!, or just the spread of Spacewar!?
Well, the "imitation is the sincerest form of flattery"— many people saw Spacewar! as, some people ask for copies of the source, and of course we gave them out because we very briefly considered trying to sell Spacewar!. We realized the only possible customer was Digital Equipment, and we also, on a little reflection, that they were too cheap to do it. So we gave it out to anyone who wanted it, and some people got the listing and thought about it, and by reading it— a lot of people simply saw the game and had a computer that wasn't the PDP-1 but did have a display, and implemented Spacewar! their own way. I suspect most of them figured out the "basic trick", but I'm not sure.
What "basic trick" were you thinking of?
That you could do everything based on the spaceship unit vector. How are you fixed for the source code for different implementations of Spacewar!?
We have a few. I don't know if we have the PDP-10 version. We have the 12 version, and I think we have a PDP-7 version.
I think Bob Saunders wrote the PDP-7 version. I think one 6 version simply ran on the PDP-1 simulator. I think there must have been others, but I don't know. Something for some history grad student to pursue. When we were running a demo for the Yelp event, there was one woman who had done Spacewar! in turtle graphics as a high school programming project, which she wasn't too happy with. She seemed to like the demo of the original Spacewar!.
So turtle graphics running on a micro or something like that?
I didn't quiz her. I didn't have the opportunity to quiz her further.
So she thought this version was better?
No, she just thought it was nice to see the original.
So she was in her mid-20s?
20s or early 30s; probably 20s. The DEC field service story where the DEC production people got into the practice of loading Spacewar! the last thing before PDP-1 shipped, and field service would then unpack it, make sure that nothing horrible had happened, tryed turning on power, and starting Spacewar!. And if it worked, they would call the customer over and say, "See, it works." If it didn't work, then they'd worry about it. In the restoration project, we had a little reflection and we decided that probably if Spacewar! works, just about everything works, as far as machine instructions go. It doesn't guarantee all the I/O gear works, but it does multiply and divides, and just about every instruction. So a lot of people implemented Spacewar! just from knowing that it existed and having seen it maybe once.

And a little later on the control boxes:

Those were the three-way lever switches?
The version that I remember quite clearly, and nobody else does, so I think they must have died very early— there was a 1930s design, 4-pushbutton block that was used for buzzing buzzers in an office; so you'd have a receptionist who had maybe one or two or three lines on a phone and when one of them rang, she'd pick it up, find out who it was and then buzz the buzzer to get that person to pick up the phone. Those were nice because you could hold them in one hand and play them like a flute. But they died very quickly; they were designed for being pushed a few times a day, and it turned out that there was a fatigue problem when they were pushed hundreds of times a day. And so they died fairly early. Then somebody, it may have been Bob Saunders, made up the second version, which is the one that's Shag sketched and everyone remembers, which is a wood box with a slanted masonite top, and a left-right-off switch, and up-off-down switch, and a pushbutton. And that was used for rotate left, rotate right for the horizontal one, accelerate or fire torpedo for the up down one and hyperspace for the pushbutton.
And were quiet enough that you couldn't tell what the other guy was pushing?
Yes. They were switchboard type switches, so they didn't click; also the first ones didn't click. And one of the problems with clicking switches, which is what people tend to start with, is you could tell when your opponent is out of torpedoes or rockets because you hear the switch clicking and nothing is happening on the screen.
So most of the play, then, was done with the lever switches?

A3. Additional Images

The following photos showing the Computer History Museum's fully restored DEC PDP-1 are not part of the original article:

Spacewar! on the Computer History Museum's PDP-1

Spacewar! running on the Computer History Museum's PDP-1 & Type 30 Visual CRT Display.
Photo by Joi Ito (creative commons)

Restored DEC PDP-1 at the Computer History Museum's

The fully restored DEC PDP-1 at the Computer History Museum, Mountain View, CA. This particular machine is a PDP-1C, serial number 55 (the last PDP-1 to be produced), and was originally shipped to Inforonics in March 1966.
Photo by Tom Bennett (creative commons)

Steve Russell operating the Computer History Museum's PDP-1 (2007)

Steve Russell operating the Computer History Museum's PDP-1 (2007).
Photo by Joi Ito (creative commons)

The 'Miskytron' port to the PDP-1, at the Computer History Museum

Marvin Minsky's "Three Position Display" (Minskytron) on the Computer History Museum's PDP-1.
Photo by Joi Ito (creative commons)


Probably the most fully featured PDP-1 installation ever, at the Lawrence Livermore Laboratory, 1964 ca.
(Note the chair at the right that came as an accessory with various versions of the PDP.)
Courtesy of Lawrence Livermore National Laboratory, via the Computer History Museum (accession 102618910).

Dan Edwards and Peter Samson playing Spacewar!

Dan Edwards (left) and Peter Samson playing Spacewar! on the PDP-1 Type 30 display. 1962 ca.
Mind the original control boxes.
Photo: DEC, via the Computer History Museum (accession 102631264).

Screenshot of Spacewar! (1963 ca.)

A black and white screenshot of Spacewar!, 1963 ca.
Photo courtesy of the Computer History Museum (catalog number 102618914).

Screenshot of scores in Spacewar! 4.8 (emulation,

The scorer patch for Spacewar! 4.8: The "Wedge" is leading the "Needle" by 16:8.
After each game of a match, cumulative scores are displayed as rows of ships,
like a World War II fighter pilot's tally.

Screeshot taken from an emulation running Spacewar! 4.8, (2014).

The display of CHM's restored PDP-1 running Spacewar!

The display of Computer History Museum's restored PDP-1 running Spacewar!
Photo: © Mark Richards, Computer History Museum (web site, 2013).

Steve Russell at the CHM's PDP-1

Steve Russell and the Computer History Museum's PDP-1 (2006).
Photo by Alex Handy (creative commons), crop by Arnold Reinhold (Wikimedia Commons)

Test character dump of the CHM's PDP-1 on the Type 30 display

Test character dump of the CHM's PDP-1 on the Type 30 display,
created by the Computer History Museum PDP-1 restoration team.
(Aspect slightly adjusted.)
Photo courtesy of the Computer History Museum (catalog number 102663948).

Note: This and the next image served as a reference for the implementation of the
character glyphs used by the Spacewar!-emulation to be found on this web-site.

Test character dump of the CHM's PDP-1 on the Type 30 display

Another photograph of the test character dump of the CHM's PDP-1 on the Type 30 display,
created by the Computer History Museum PDP-1 restoration team.

Note: The PDP-1 didn't provide any character generation of its own. The CHM's PDP-1 is equiped with the "Digital Symbol Generator Type 33" featuring programable glyphs. The glyphs displayed differ somewhat from those produced by a (surprisingly compact) software font generator published by BBN. According to DEC promotional material, the Type 33 plots symbols on a 35 dot matrix (5 dots wide and 7 dots high) in four sizes. A total of 220 characters (based on a 16 point font size) could be displayed flicker free.

Photo courtesy of the Computer History Museum (catalog number 102663947).

A4. Notes on the Equipment


It is quite common to belittle early computers, regarding their specs, when looking back in time. But the PDP-1 (Programmed Data Processor-1) was a serious machine, in fact it was an amazing machine at a then surprisingly low price (USD 120,000). Only half a decade after the first two experimental research computers (MIT's TX-0 and Vienna Technical University's more humble "Mailüfterl") were prototyping the feasibility of the combination of transistorized circuitry and core-memory — which was mind-boggling fast and reliable as compared to previous means of internal storage —, the PDP-1 offered both in a compact, ready for market package that could be turned on by the flip of a single switch.

The PDP-1 was a single-address, single-instruction stored program machine operating on 18-bit 1's-complement binary numbers. (While the machine had been initially advertised as beeing "available in word lengths of 18, 24, 30, and 36 bits", only 18-bit type machines were actually build. Cf. Datamation, Nov/Dec issue 1959, p 26.) The CPU was clocked at a cycle time of 5 microseconds (good enough for 100,000 additions per second including memory access) and featured two user-accessible registers, an accumulator included in the arithmetic unit and an IO register which doubled as an accumulator extension, forming a combined 36-bit register. The standard Type 12 core-memory module had a storage capacity of 4,096 18-bit words. With the optional Memory Extension Control Type 15 a total of 16 Type 12 memory modules could be added for a maximum storage capacity of 65,536 18-bit words. (The memory would then be accessed either by bank switching or by the use of a 16-bit extended addressing mode.) Moreover, the machine featured polyphonic sound, provided by 4 independent synthesizers, and an ample provision of external ports and switches, ready for real-time interaction. A sequence break system allowed for up to 16 automatic interrupt channels for asynchronous communications with peripheral devices and the optional High Speed Channel Control Type 19 would even provide direct memory access to these devices. For visual communication the Type 30 CRT provided high-resolution graphics at a technical resolution of 1024 by 1024 addressable locations in 8 intensities and 4 different setups for the origin of the screen coordinates. And last, but not least, the optional light pen Type 32 allowed direct user interaction with the program on the scope.

Let's put this in relation by comparing these specs of the "first toy computer" to those of the most successful toy computer of all times, the 1980s Commodore 64 (C64):

The C64's 6510 microprocessor ran at a clock speed of 1 MHz which would be 5 times the speed of the PDP-1. Considering that a single instruction would use in average about 4 of the 6510's cycles and that a single instruction of the PDP-1 would only use 1 or 2 cycles (including memory access), the PDP-1 was in fact running at about a bit more than half the speed of a 1980s C64 computer. Even more, the wider words of the PDP-1 allowed to accomplish in a single instruction, what would take multiple steps in 6510-code, so that the DEC machine would even out-perform the C64 on some tasks (e.g., adding 16-bit numbers, not to speak of 18-bit numbers, or high-precision multiplications and divisions).

Memory might be considered limited in the basic setup using a single Type 12 memory module of 4096 locations. But these locations were 18-bit words, also allowing for a much more compact binary representation of the code by combining operation instructions and addresses in a single word. Moreover, this was all usable memory, there were no ROM-images or mirrored devices, like in the C64. Taking this into account, we would have to subtract the address space required by the ROM images, the mirrored video, sound, and interface chips, the zero-page used by the system, and the space required to maintain a bit-map for the display from the total memory of the C64 in order to compare these. Doing so, we would end up with a usable address space of 26,816 8-bit words or 214,528 bits of the C64 compared to the 73,728 bits of the PDP-1 in its basic setup (but the C64 being blown away by the PDP-1 in this category by 1,179,648 bits or 5.5 times the memory with full memory extension). So, the C64 wins this category by a bit less than 3 times in the basic setup. But considering that the usable memory of the PDP-1 was 3 times as big as the usable memory of the C64's predecessor, the VIC-20 (featuring 3,583 usable bytes or 28,664 bits), these are quite sure more than humble specs. Moreover, the op-codes of the C64's 6510 took up twice as much bits in memory than in the PDP-1, shrinking this gap even more, to appox. twice the actual space available to a program. Considering again the wider word-width of the PDP-1 and the much more general approach to indirect addressing, the C64 would require multiple steps and multiple instructions for the same tasks, so that, in theory, we could end up with a lack of memory, when attempting to port a program fitting perfectly into the standard memory of the PDP-1 to C64-code.

Taking into account the much higher video resolution (1024 x 1024 at 8 intensities compared to 320 x 200 in a single intensity, or merely 160 x 200 at 4 colors, of the C64-graphics) and the 4 compared to 3 polyphonic voices, the PDP-1 winning both the graphics and sound categories with some distance, the PDP-1 might still have been a machine of the dreams for a computer kid of the 1980s microprocessor age. And the PDP-1 would be winning in all categories, when compared to a late 1970s Apple II. — For sure, this was an amazing machine, even 20 years later.

The PDP-1 Displays

Since the actual appearance and properties of the display may be of some importance to the design of Spacewar!, here are some informations on DEC's displays for the PDP-1:

The PDP-1's default display device was the "Type 30" display, originally named "Visual CRT Display". It featured 1024 x 1024 randomly addressable plotting positions in a 9 3/8 inch by 9 3/8 inch square on a round tube protected by a characteristic hexagonal housing. (A DEC-memo states on the display's resolution: "To the unaided eye, approximately 512 points are resolvable on each axis."[2]) Optionally there was also a ultra-high resolution "Type 31" display, originally named "Precision CRT Display", featuring a resolution of 4096 x 4096 points on a 5 inch cathode ray tube (raster size 3 x 3 inches, 1365 dpi) to be used for photographic recordings. From around 1963, the Type 30 was referred to as the "Precision CRT Display" (probably to emphasize the display's accuracy of 3% of the raster-size at a dot-size of 0.015 inch) while the Type 31 now became known as the "Ultra Precision CRT Display".
The Type 30 display featured a special "P7" phosphor with dual characteristics: A bright blue short sustain and a dim, yellowish-green long persistence. (Technically, P7 phosphor or (Zn,Cd)S:Cu is a dual-color, dual-persistence compound phosphor emitting at wave-lengths 558 and 440 nm, typically used – since the 1940s – in scopes for mechanical scan-radar ["plan position indicator" or PPI], which was also this tube's original purpose of use.) The bright blue short persistence featured an activation time of less than 5 μs and a fast decay of less than 50 μs, suitable to provide exact positionial impulses for a light pen attached to the display, while the yellowish-green long persitance provided for the iconic trails left by objects moving over the screen.

The displays were point plotting devices, allowing arbitrary display locations to be activated by addressing their coordinates (with the coordinates' origin at the screen's center). As opposed to other random-scan devices, like the more commonly known vector displays, point plotting displays would not remember any display locations, resulting in an "animated" display, which left the task of refreshing display information entirely to the CPU — and thus to the program. Also, there was no circuitry for drawing lines or for other interpolations, rather providing a highly volatile canvas for the software to paint on. (As eventually a variety of variations of the Type 30 became available, some of these – according to DEC's advertising – included also hardware for line and curve generation.) The Type 30 display featured in theory 8 levels of intensities (or gray scales), but only 7 of them were actually visible to the human eye.
Spacewar! uses 4 of these intensities and modulates the screen-intensities even further by refreshing the background starfield only every second cycle. (The refresh-rate was fast enough to provide a flicker free experience to the human eye, while being unstable at the same time, which might show as flicker in film and video recordings.) Another trick used by Spacewar! to modulate the visual brightness of its graphics was the use of dotted lines for the spaceships' exhaust blasts (versions 4.x of the game used this trick also for the "Sun" or "heavy star").

Technically, intensities were encoded as modifiers in bits 9–11 (from the left in MSBF order, the PDP-1 was a 18-bit machine) of the "dpy" instruction (a sub-type of the "iot" instruction). Shifted by 6 bit-positions to the right, these would give display intensities in the order 3, 2, 1, 0, 7, 6, 5, 4, where 0 would be the default intensity, 3 the brightest, 7 only barely visible, while a value of 4 would be visible to a photomultiplier only.
Converted from 3-bit 1's complement (compare DEC, F-15(30E), 2-5-12/63, p. 3-12) these values translate to the intensity levels +3, +2, +1, 0, -0, -1, -2, -3.
(Memo "PDP-35"[1] documents 1 as the normal value, wheras later editions[2] more correctly describe 0 as the default intensity.)

There is a bit of confusion regarding a brightness/intensity value of 4: While the original PDP-1 handbooks make it quite clear that a value of 4 would address the Type 31 CRT high-resolution display only, forming a "dpp" instruction (0720407) of its own, later instruction lists of the early 1970s are not so clear. Moreover, the CHM version of Spacewar! (4.1f) outputs most stars of the background starfield (Expensive Planetarium) with an intensity of 4 — which should not be visible anyway. Apparently the CHM is running the Type 30 CRT with non-standard settings, but according to the handbooks, this shouldn't be displayed at all. It could be, that the special case of an intensity of 4 only applies, if there is a Type 31 display actually attached to the PDP-1, thus activating the "dpp" instruction.

The PDP-1's "dpy" instruction also featured a variable origin of the screen's coordinate system, to be indicated by control bits in postions 7 and 8 (MSBF) of the instruction, where a value of 0 would put the origin at the center, a value of 1 would put it at the center of the bottom edge, a value of 2 would put it at the middle of the left edge, and a value of 3 would put it in the lower left corner. Spacewar! uses a centered origin for all display instructions.
(Putting everything together, the "dpy" instruction had the octal format: 072cb07 — or 073cb07 with the "wait for completion" bit 5 on —, where "c" is the group of control bits and "b" the brightness/intensity, while the 0 and 7 in the least significant positions would select the CRT display for output.)

The Type 30 CRT could even be utilized for data conversion when combined with a photomultiplier in front of the screen. The PDP-1 would send low intensity pulses to the display, which would be then recognized by the photomultiplier device and fed back into the PDP-1, by this digitizing data on film or other visual material.

Later DEC introduced some additional display equipment like the Type 343 "Remote Display", an auxiliary but independently operating display unit containing only the analog portion of the display to mirror the information of the master display, and the Type 340 "Precision Incremental CRT" unit, featuring control circuits of its own and thus providing sequential storage of control and data by a single information channel. Also, there was a Type 372 camera mount for the Fairchild/Dumont Type 450A camera to facilitate repetitive photography.

A notable accessory was the Light Pen Type 32, providing on-screen interactivity to the PDP-1's users, which was eventually replaced by the Light Pen Type 370. Light pens were both directly attached to the front of the display (with a cable outlet at the botton right corner of the display's bezel) or would be attached separately (see the image below).
For use with the light pen the display would generate an additional short impulse on the light pen's select signal that could be detected by the light pen's fiber optics and photomultiplier system and would be send back as a positional information to a dedicated register of the CPU. (To provided the necessary precision, the rise time of the blue phosphor layer and the processing time through the light pen combined were less than 5 μs.)

As for auxilliary equipment and circuitry, the Type 31 and the later Type 340 came with their own cabinet of electronics, while the Type 30 was attached to an unspecific table (which housed the electronics underneath its top) by a turn- and tiltable mount.

It might be notable that a memo by DEC states, "The cathode ray tube has a P7 phospher[sic], allowing either a blue or yellow filter to be used to select the short or long persistence for photography purposes." [2].
In other words, by isolating any of the two colors of the P7 phosphor by means of a photographic filter, the display provided purposefully both an exclusive view of the current screen information and a view of time-sliced past informations blending in an ever fading continuum. So the PDP-1's displays were actually 3D-displays, providing X, Y, and delta t (time) informations, with time-slices visualized by the gradually diminishing gloom of the P7 phosphor.
(Over history, we lost a dimension in computer displays.)

N.L., 2013-2014

[1] "PDP-35 / PDP-1 Instruction List"; DEC, Aug 1968; p. 29
[2] "PDP-35-2 / PDP-1 Instruction Manual / Part 3 -- iot Operated I/O Devices"; DEC, Sep 1971; p. 5

Sketchpad-like interactive drawing program running on a DEC PDP-1's Type 30 display

A Sketchpad-like interactive drawing program running on a PDP-1's Type 30 display.
Photo: DEC, via the Computer History Museum (catalog number 102652246).

DEC Precision CRT Display Type 30

The "Precision CRT Display Type 30" (formerly the "Visual CRT Display Type 30") at work.
Source: DEC promotional material ("Precision CRT Display / Type 30"; F-13 (30) 5/1964; p. 1 / cover).

DEC Precision Incremental CRT Display Type 340

The "Precision Incremental CRT Display Type 340" providing sequential storage of control and data in core memory.
Source: DEC promotional material ("Precision CRT Display / Type 30"; F-13 (30) 5/1964; p. 5).

DEC Ultra Precision CRT Display Type 31

The "Ultra Precision CRT Display Type 31" to be used for photographic recordings.
(Resolution: 4096 x 4096 plotting positions, raster size 3 x 3 inches square on a 5 inch CRT; 1365 dpi.)
Source: DEC, "PDP-1 Handbook"; F-15D 1963; p. 37.