A $75 game of Space Travel helped push Unix onto a spare PDP-7
Dennis Ritchie's history follows the paper-tape dependency that disappeared when the small computer learned to support itself.
A game that costs about $75 in CPU time gives the phrase pay-to-play a fairly literal meaning. Space Travel also had a jerky display and required typed commands on the big computer. The entertainment budget was doing more work than the controls.
Dennis Ritchie recounts the move in The Evolution of the Unix Time-sharing System. Ken Thompson found a little-used PDP-7 with a good display processor, and the two rewrote the game for it.
The project needed more than a different launch command. They made floating-point arithmetic, display character definitions and a debugging subsystem. The game was taking a computer along for the ride, one missing capability at a time.
At first, the work still depended on the larger machine. A cross-assembler running under GECOS produced paper tape for the PDP-7. Ritchie describes carrying the tape to the other machine. Imagine a development loop in which the progress indicator is someone walking down a hallway.
Thompson was also exploring a filesystem. Ritchie’s account traces that work alongside the game, so the familiar claim that Unix was invented solely to play Space Travel leaves out a large part of the record. The game supplied practical pressure and a reason to use the smaller machine.
The filesystem acquired processes, command utilities and an assembler. Eventually the PDP-7 could support its own development. Ritchie’s phrase is “no longer needed the GECOS system.” Removing that dependency changed the work from a trip between machines into a loop the smaller computer could complete itself.
The $75 figure belongs to Ritchie’s recollection of CPU-time cost. It should stay attached to that context. It is neither a modern arcade price nor evidence that somebody fed seventy-five dollars into a coin slot every time the ship crashed.
A useful way to read the history is to watch which inconveniences became software. An expensive run encouraged a move. A missing environment encouraged new tools. Carrying a program on paper tape made local development more attractive. Each remedy made the next experiment less awkward.
That pattern remains familiar in a home lab or a small engineering team. A tool can become a platform because people keep removing the external tasks needed to use it. The point at which it can build or repair itself is a particularly meaningful milestone.
There is a limit to the comparison. Most side projects will never grow into a widely used operating system, and persistence alone cannot promise that outcome. Ritchie documents a particular group, particular machines and technical ideas already in motion. A neat origin anecdote cannot replace those circumstances.
The practical question for a current project is smaller: which outside dependency interrupts every experiment? Measuring that interruption can reveal a better next step than adding another feature. Paper tape makes the cost visible. A slow handoff can hide the same cost in a calendar.
Space Travel found cheaper parking.