Inside Spacewar!
Intermission: Digging up the Minskytron Hyperspace
(Introduction · Warp-Induced Photonic Stress · The Hunt for the Minskytron Hyperspace · Update: Original Hyperspace Source Surfaces)
Due to recent developments, we will break the planned schedule of our software archeological series on the internals of Spacewar!. Since there slipped some detective story theme into Part 2, this might be apposite anyway.
This is the story of digging up the "Minkytron Hyperspace".
The original "Hyperspace Minskytron signature" in Spacewar! (Montage)
Credits: Type 30 CRT by CHM / Mark Richards 2013; Screen-shot (emulation) and montage: Norbert Landsteiner 2014
Ever, since reading J.M. Graetz's seminal article "The Origin of Spacewar" (Creative Computing, 1981) and seeing the original screen-shots, I was eager to see in person, what would have been apparently Spacewar's greatest visual stunt: the "Hyperspace Minskytron signature". This is, how Martin Graetz, the author of the first hyperspace routine in history, described this feature:
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 photonic stress emission (see how easy this is?), I made the disappearing ship leave behind a short Minskytron signature (Figure 4).
The Origin of Spacewar! — Figure 4.
"Warp-induced photonic stress emission." The Hyperspace Minskytron signature.
Credits: J.M. Graetz 1962/1981
(Mind the off-centered central star in the photograph, indicating that the
outer mask was rather a montage and not the bezel of the Type 30 CRT.)
And there's another description by J.M Graetz, given in his paper for the first DECUS conference in 1962 ("Spacewar! Real-Time Capability of the
This is an emergency device. It frequently happens that a ship cannot accelerate fast enough to get out of the way of an approaching torpedo. The player may send the ship into hyperspace then. The ship then will disappear and very shortly will reappear somewhere else on the scope. Since this is a way of getting from one place to another without traveling the distance between, the method used must be hyperspace! Each player has exactly three hyperspace jumps.
Warp-Induced Photonic Stress
At the beginning, it was quite unclear, what version of Spacewar! this would have been. Graetz's description in Creative Computing stressed that the hyperspace was seeing some development, also the article was from 1981 and there was no indication of when the screenshots had actually been taken. It was not until recently, when the DECUS proceedings from 1962 — and, in them, Martin Graetz's DECUS paper — became generally available at bitsavers.org and archive.org, that we would have been able to attribute a date to them. Generally the various original screen-shots of Spacewar! are sharing a common texture that is quite destinctive. While there are various dates to them applied on the web, we can be pretty sure that these were all taken in a single shooting session. And, low and behold, with the DECUS paper at hand, there's a screen-shot of a pretty good quality (since originally processes by analog equipment and scanned in a high resolution), which is showing a sceen, we already know from the article in Creative Computing. Without doubt, these images were taken in 1962!
Another historical screen-shot of Spacewar! and the Minskytron Hyperspace
Credits: CHM / archive.org
Meanwhile, I had written an emulation for the paper tape reader and for the RIM-mode of the PDP-1. (There was a hard wired boot-loading device in the PDP-1 that would, when deployed, start the computer in Read In Memory mode: The computer would be reading from the paper tape in binary mode, assembling three consecutive lines of data to a single instruction, which would either set the program counter to a location or would deposit the next word into the current location, exiting this mode at the first jump instruction to proceed with normal operations. This would be used to load the actual loader to the very end of the 4096 18-bit words memory, which would then read in the program from the rest of the tape.) By this, I was able to inspect some of the versions for which there had no source code been preserved, like the very first version 2b from early April 1962.
Having a closer look at the screen-shots, some of them exhibited a feature distinctive to Spacewar! 2b, namely the shorter exhaust trails of the spaceships. Also, while the article in Creative Computing wasn't that clear, if the "crock explosions" mentioned and depicted in the section "Crocks and Loose Ends" were in the very same version that featured the "warp-induced photonic stress emission", it fell all into place: All the images would be representing the same version, something between version 2b (with no hyperspace at all) and Spacewar! 3.1 (showing the normal exhaust flames and perfect pixel-dust explosions). A last point of uncertainty was provided by the background starfield (Expensive Planetarium) to be seen in these photos: With the brighter stars distinctively bigger in size, this looked much more like the implementation in Spacewar! 3.1, the one using a scale of intensities to represent the magnitudes (apparent brightness) of the stars, with the scope's phosphor bleeding the most at the highest activation levels. But, as we will see, this is also true for the original implementation in Spacewar! 2b, using distinct rates of refresh for the stars of the various magnitudes. (At a technical level, this seconds our assumption made in Part 1, suggesting that one of the reasons for drawing the brightest stars twice in a single frame, would be their enlargement by the phosphor bleeding.)
Illustration (detail) from "Spacewar! Real-Time Capability of the PDP-1" (DECUS Proceedings 1962).
Credits: J.M. Graetz 1962 (screen-shot, multi exposure)
Mind the short exhaust flames to be seen at the upper most incarnation of the "Needle".
The Hunt for the Minskytron Hyperspace
Right from the beginning, the driving motivation for investigating sources and binaries of Spacewar! had been my intention of unearthing the version described in the Creative Computing article. But none of them showed any signs of a "Minskytron signature". One of the binaries available at bisavers.org was "spacewar2B_2apr62.bin" (we shouldn't be too certain regarding the date, since this was probably more likely the date of the tape being punched, rather than the date of the program), but it loaded with a tape error, indicating it was incomplete. But there was also "stars.bin" and — as we know from the organization of the listings — the data for the background starfield would be assembled in a separate step. So, was this only missing the star-map, and was this to be found on the tape "stars.bin"? Low and behold, there was Spacewar! 2b in all its glory. There was also a tape "spaceWar_SA-5.bin" that read in like charm, but this wasn't an advanced version 5, rather, it looked quite the same as 2b. (A later disassembly proofed the two tapes beeing binary identical, with the only difference of "spaceWar_SA-5.bin" including the starfield data.)
In fact, the name "spaceWar_SA-5.bin" proofed to be quite interesting: While investigating various sources for the PDP-1, some of them showed a character combination like "SA 4" (with various numbers) in the comments, indicating the start address of the program. Now, Spacewar! would have been started normally at the default start address 4 (the first few memory registers were used by the sequence break system). Started at 4, the program would jump to a few instructions configuring the input routine for MIT's ingenious control boxes. But at location 5, there was an alternate start point, jumping to a few instructions to configure the program for the use of the test-word stwitches, right at the control console of the PDP-1. Since paper tapes didn't have a filename, the filename of the digital image would have presumingly been derived from a handwritten label, right at the start of the tape. Apparently, someone had written "Spacewar SA 5" on the tape. (Or, since there was a little program to punch a pattern reading "SPACEWAR" onto a tape, it might have been the title-punch and a handwritten "SA 5".) So, we may ask, why would there have been an all-in-one tape with operating instructions for use without the control boxes, when there was only a single PDP-1 at MIT, and this one was equiped with the control boxes? We may conclude that the tape would have been provided to another PDP-1 installation outside of MIT (Who else was there in spring 1962? ITEK? CRL? BBN? Maynard?), suggesting an early spreading of the program, right from the beginning.
One of the few real handicapts of Spacewar! 2b was the lack of an automatic restart. If left running on its own, the ships would blow up in the boxy "crock explosion", when colliding in the center of the screen, and the game would innocently commence with just the starfield to be drawn, requiring a manual restart to be run again. But there were some tapes suggesting to fix this by a patch, named suggestively "spaceWarRstrt.bin" and "spacewAutoRestartPatch.bin". But, when applied, they made no difference to the game. A closer inspection showed, that they patched a location at address (octal) 5544, in the midst of the no man's land of unsused memory (whith the program and its data ending at 3763 and the starfield data starting at 6077). What was this, if not a hoax? Another tape, to be found in a directory with the suggestive name "InsidePDP1_80s_box3" containing assorted paper tape images, was "hyperspace85.bin". Given the rather short filesize, this could be another patch to Spacewar!, but what version would this be? (The filename suggests a rather advanced version, but in retrospect, it's just tape 5 in box 80, a name acquired by some archiving system. Update: Actually, the filename is — believe it or not " referring to the year, as in 1985 [1])
And a patch it was, in deed. Also, it was looking quite like Spacewar-code. Comparing the patched addresses, jumps, and variables used by this patch, no version would be even close in matching. (E.g., some patched address would modify a location right in the definition of the objects table, initialized freshly at each run.) With the disassembly of Spacewar! 2b done, the definition of the object table proofed to be a bit shorter than the one of Spacewar 3.1, while most of the preeceding code was mostely identical, at least in size. What, if this patch wasn't some late, elaborate patch to the hyperspace, but an early patch to the single version that had no hyperspace at all? Let's see: The patched jump was now at the exact location, where there was the final jump out of this setup routine. And this wasn't a sole case, all the patched location would make sense. Let's have a look at the locations accessed by the patch, but outside its realm: Every single one of them was a sensible variable or object entry in Spacewar! 2b! In deed, this was patching the missing hyperspace. By this, the picture arranged. The main part of the patch was located at addresses (octal) 5240..5600 and the instruction at 5544 would be a jump back to a major routine of the main program (ml1). Didn't we know this address? The auto-restart was actually a patch to the patch and would be indeed applied to Spacewar! 2b, but only after the "hyperspace85"-patch would have been applied. By this, Spacewar! 2b became a mature program, with any of the major features right in place.
So, there finally it was, the warp-induced photonic stress emitting Minskytron-inspired Bohr atom like hyperspace, to be experienced half a century after it would have seen for the first time the lights of the Type 30 CRT's gloomy screen!
Here is a shortcut to the patched program running in the emulaton:
▶ Play Spacewar! 2b fully patched incl. the "Minskytron Hyperspace".
BTW: Hyperspace is Left + Right (but won't work each time, see above).
Thanks to some traces in the code, we even get an idea, how Martin Graetz would have coded the very first hyperspace in history: There's an insertion of the macro random, we've already seen in Part 2, in the very form it is defined in the main part of Spacewar! 2b. But the constants used, are not reused by the assembler, rather included inline in the code instead, proving that this had been assembled in a separate run. We might imagine Martin Graetz sitting in his "secret hideaway (then known as the Electronic Systems Lab) working on the ultimate panic button", equipped with the symbol table output of the assembly of Spacewar! 2b and probably at least some of the source code. (The shared addresses of the symbol table would have to be redefined for this again.) As a side effect of this the program was actully frozen until the code for the hyperspace would be integrated into the main program, since any change to the code would inevitably alter the addresses of the variables insterted by the assembler. Even more, with Steve Russell applying a last patch right before MIT's annual Science Open House in May 1962 that introduced a scoring device (probably quite like in Spacewar 3.1 showing scores in binary at the console lights), running the program would have meant to load it from 5 separate tapes (the main program, the hyperspace patch, the auto-restart patch patching the hyperspace patch, the scorer patch, and, to not be forgotten, the starfield-data).
We haven't seen much source code in this irregular part of the series, but the various disassemblies and the reconstructed source code of Spacewar! 2b are linked in the references at the end of this page, to the benefit of the reader.
But we won't close without a few remarks on the thing itself. While the visual effect is "cute", in deed, — Graetz was right on this —, the original hyperspace shows an interesting approach regarding the gameplay: As opposed to the later implementation in version 3.1, this one really conveys the impression of a "not that elegant 'Mark I'" device of some inherent unreliability. While the later version would just do the jump to hyperspace (with some cooling time between consecutive jumps) and ships would break with an increasing probability, this "Mark I" generator would use some time to load, it wasn't ready right from the beginning, and it would take some significant time to reload again — and even then, it would not trigger a jump instantly each time it would have been invoked. This Mark I hyperfield contraption has a distinctive "kludgy" feeling to it. With a total of 3 jumps, but each of them a save ride, with no risk of breaking ships, this might have been an important factor: Without this "kludgy" user experience, players would probably make the jump just for another "cute" bloom of the hyperspace signature, with hyperspace being the ultimate risk to an entertaining gameplay, reducing the game to yet another Minskytron with some spaceships in it. I would guess, this might have also been a reason, why the "Minskytron Hyperspace" was eventually dismissed, in favor for a more user reactive device that introduced the risk of breaking in order to be not over-used by risk-avoiding players.
And here, finally, there's an animated GIF of the warp-induced photonic stress emission of the hyperspace patch in action:
The Spacewar! 2b hyperspace patch in action (screen recording of the emulation).
Click to play the animation.
With most of the the mysteries solved, we may close for today.
Next time, we'll encounter — as scheduled — finally some of Steve Russell's code. — Stay tuned.
Post Scriptum:
In fact, not everything went that smooth as described above. There were a few days, where I was quite sure about the "hyperspace85.bin" applying to Spacewar! 2b, even before doing the disassembly. But when applying the dumped contents of the RIM-tape to Spacewar! 2b, the program failed — it crashed. Reassured by the disassembly, I tried again, reproducing the whole procedure, but to no avail and same results. Why would this @#ยง*! patch not do what it was supposed to, when this was without doubt the missing hyperspace? Turned out, I had been exporting the contents of the RIM-tape in octal, but without the leading zero modern equipment requires for descerning octal numbers from decimal ones. And having stuck in octal code all over, this didn't even appear to me.
— O tempora o numerum formas!
(Here we're dealing with another ambiguity: Is the original mores nominative plural or in accusative plural case? Both tempora and mores are ambivalent in their declinations and o goes with the nominative, accusative, and even with the genitive. I had the feeling that Cicero would have meant it in accusative, expressing his despair.)
Update, 21 Aug 2014: Original Hyperspace Source Surfaces
There's news on this topic, illustrating how much there is still avaiting to be discovered when it comes to computer history:
Recently the original source of the "hyperspace85" patch surfaced, which was donated to the iMusée, the Musée de l'informatique du Quebec, and has been rediscovered thanks to the investigations of Devin Monnens. It's the original source, annoted by J.M. Graetz. Amazingly — believe it or not — the "85" in the filename is actually referring to the year the patch was coded. It is a recoded tape from an original source named "Hyperspace VIci, 2 May 1962".
Here are the heading comments:
(The date printed is actually "3 Oct 1985", but the day of the month was manually corrected to "26". Further, the listing is marked "21 Oct 85" in hand writing in the upper left corner of the first page. I would conclude from this that the date 3 Oct represents the date the source was typed in, while the date 26 Oct would represent the date any typos were fixed and the final, working assembly was done.)
Please mind the original version "VIci", indicating a quite intensive phase of development with at least 6 major versions and this being apparently version i of subversion c. ("ci" may also be read as subversion 101, hinting at an even more intensive phase of development and evaluation.)
I've prepared a transcript of the original source code: "hyperspace85" Macro source.
(The program requires some common macro definitions to be found in the macro fio-dec sytem tape which is not included here.)
The biggest surprise is probably Martin Graetz's entirely independent style of coding that doesn't align with the style generally exhibited by the rest of the Hingham Institute Study Group on Space Warfare. Therefor my previous attempt to reconstruct the source code of this patch was pretty much off course. :-)
It is a bit unclear, what this (the hyperspace patch being a recoded tape from 1985) implies for the authenticity of the auto-restart patch. Since this would have been just a reassembly of a lost object tape from an original source newly typed in, the resulting assembly would have been binary identical to the original patch tape (with all the adresses patched by the auto-restart patch being still the same). Also, there are at least two surviving tapes of the auto-restart patch hinting on these being still original tapes. But it could be as well that these were newly assembled together with the hyperspace patch. (The listings do not show any of the code of the auto-restart patch, but include a hand written sketch of it's logic.)
Vienna, 5 June 2014
www.masswerk.at
In case you would have found any errors or inconsistencies, or would have additional information,
please contact me.
*****
UPDATE (March 2015):
Meanwhile we discovered a hidden patch in a trailing overhead of the tape "spaceWar_SA-5.bin" that provides support for the automatic hardware multiply/divide option to Spacewar! 2b (enabling the game on a newer or upgraded PDP-1, like the one at the CHM).
Compare: Intermission: Yet Another Patch — Spacewar! 2b SA 5 and the Secrets of PDP-1 Loaders.
*****
◀ Previous: Part 2: To Draw a Star
▶ Next: Part 3: Objects!
▲ Back to the index.