1978 UT Austin Decwar And TOPS-10

The UT Austin Decwar coders had to use MACRO-10 assembly to invoke specific TOPS-10 Unimplemented User Operations. UUOs acted as traps or interrupts that suspended user-level execution and called the TOPS-10 monitor. The monitor would then assert exclusive access over the magnetic-core memory high segment, queuing any other player-jobs attempting to write to the lists until the holding job issued an unlocking UUO. In other words, in order to use the shared memory linked lists for attack and radio messages, player-jobs had to call TOPS-10 directly via assembly code. This is the root reason that assembly code became essential for Decwar, and code in pure Fortran was simply no longer feasible. It unlocked the full potential of the DEC-10, and at the same time forever bound the code to TOPS-10. 

There was very little separation between the game and the operating system, and little hope of moving the code to even a sibling environment such as the DEC-20 and its TOPS-20 operating system. Even though TOPS-20 ran on the same 36-bit hardware, it was derived from BBN's TENEX operating system rather than TOPS-10, and it used a completely different system-call architecture known as Jump to SYStem instead of UUOs. While TOPS-20 did include a compatibility emulation library called PA1050 designed to intercept and translate old TOPS-10 UUOs into JSYS calls, this emulator had severe limitations. The PA1050 emulator was completely incapable of translating the direct physical segment locks and atomic inter-job synchronization routines that Decwar used to protect its message queues. Because the emulator relied on virtual memory page-mapping structures rather than static core segment locks, the Decwar binary simply could not run on TOPS-20 without a complete rewrite of its underlying assembly code.

The cancellation of the PDP-10 product line by DEC in 1983, and the demise of DEC itself in 1998, seemed to permanently strand the UT Austin Decwar code on an obsolete architectural island. But in another of its surprising near-death experiences, the UT code has survived and flourished in new forms far tougher and more survivable than before, through the physical and digital preservation efforts led by Obsolescence Guaranteed. The mid 2020s saw a spectacular revitalization of this ecosystem. Rather than treating historical computing as dead artifacts meant only for museums, Obsolescence Guaranteed, an informal group of computer history hobbyists and engineers, has focused on creating computer time capsules. By building affordable, fully functional hardware replicas of the classic DEC lineup, including the PiDP-1, PiDP-8, PiDP-11, and PiDP-10, they allow modern users to directly experience the tactile and interactive realities of the mainframe era.

For Decwar, the PiDP-10 replica is one form of resurrection. The PiDP-10 is a scaled-down, desktop-sized physical reproduction of the original PDP-10 KA10 front panel. It features an active array of 74 functional switches and 124 indicator lamps, driven by modern LEDs, that accurately reflect the machine's internal state. Inside this console beats a dual-hearted system: a modern Raspberry Pi that runs a physical Linux kernel concurrently with a cycle-accurate PDP-10 emulator based on Bob Supnik and Richard Cornwell's SIMH engine. Physical switch toggles on the front panel trigger interrupts on the Raspberry Pi, altering register states in the PDP-10, while memory writes are translated in real-time to illuminate the physical LEDs. 

Another more permanent and accessible resurrection is represented by Docker. The UTEXAS DECWAR 2.3 Source Distribution Tape Reconstruction is a digital time capsule containing both the source code and the TOPS-10 environment. Docker excels at creating reproducible, automated build pipelines. A Docker image encapsulates the underlying SIMH emulator, the TOPS-10 operating system, and the SDT virtual tape into a single, isolated package. This guarantees that anyone can instantly spin up the living environment as it existed on the HRC DEC-10 in 1982, without worrying about local hardware dependencies or host operating system characteristics. In fact, running in the Cloud is no different than running on local hardware. The preservation efforts go far beyond running a single standalone mainframe. The ARPANET Reconstruction Project aims to revive the ancestral Internet using Old Bits wherever possible. For UT Austin this would mean containers for the HRC DEC-10, Painter Hall DEC-20, and ARPANET IMP, with various connections through telnet and FTP links. Docker, especially using Docker Compose, is explicitly designed to orchestrate multi-node, networked applications. Instead of a user manually launching and configuring separate environments for mainframes and IMPs, a containerized setup can automatically spin up each historical machine in its own isolated container and seamlessly manage the networking between them. Placing the SIMH PDP-10 engine, historical tape images, and disk images inside a container shields users from the friction of modern software dependencies. They don't need to compile code or configure environments, but can simply start containers and immediately telnet into an Old Bits environment.

Bob Hysick at work in the HRC DEC-10 offices, quite possibly on Decwar.

Robert Schneider on the left on the evening The Soul Of An Old Machine, 1982. Robert played an important role with the code.

Tommy Loomis to the right on the same evening, also an important coder.

Rick Watson on the right, also important for the code.

[1] As always, thank you to Richard Denney and Clive Dawson for much of this material.

Assembly and Fortran

By the 1980s, PDP-10s were entrenched in universities, computing centers, and time-sharing installations. The economics of the period favored incremental software refreshes rather than disruptive changes in language standards. DEC's choice to maintain a robust Assembly language and Fortran IV toolchain reflected the installed base's dependence on legacy code, local modifications, and mixed Fortran and Assembly programming. Decwar emerged from this institutional ecology. An environment in which students, researchers, and system programmers routinely extended existing subsystems, shared code across accounts, and optimized routines for a time-shared population of users. In this milieu, stability and coding conventions mattered as much as language expressiveness. 

Decwar was written not for isolated personal machines but for multi-user communities sharing a common computational space. Its reliance on predictable compiler output and stable low-level encodings enabled a shared, real-time game environment on a platform never intended primarily for interactive entertainment. More broadly, Fortran IV demonstrates how language stability can enable specific creative forms. The persistence of its semantics allowed a hybrid program, part high-level logic and part low-level Assembly code, to function reliably over many years within its birth ecosystem.

This case study demonstrates a foundational principle of legacy system migration. Historical fidelity of the toolchain is not a matter of preference but a core engineering requirement, overriding any perceived convenience of more recent tooling. The process of migrating vintage software such as Decwar presents unique challenges that transcend simple code porting. Success hinges on a precise understanding of the intricate dependencies between an application and its original development environment. In fact, it is fair to say that it would be very difficult to migrate Decwar’s Fortran IV. It’s too intertwined with the environment in which it was created. It can be recreated and reproduced in other environments and languages, but it can not easily be migrated piece by piece.

Decwar's longevity therefore depends on specific historical layers of the PDP-10 software ecosystem. It is not merely a Fortran IV program. It is an artifact of specific compiler and assembler versions, all deeply rooted in PDP-10 hardware and TOPS-10 operating system installations circa 1980. In the study of digital history, it is tempting to view computing hardware and software as neutral tools, passive instruments waiting to be wielded by human creators. There is a more nuanced premise, however. That these systems are active environments, technological ecosystems that both enable and profoundly constrain the creative works born within them. The mainframe systems of the sixties, with their unique architectures, toolchains, and cultural norms, constitute a world unto themselves.

An Environment Evolved On Mainframes

Decwar evolved from an earlier two-player game called simply War, written in Fortran on the UT Austin Computation Center CDC 6600 Mainframe. In fact, the CDC 6600 is often classed as the first successful Supercomputer, designed by Seymour Cray and released in 1964\. When the UT Austin Computation Center PDP-10 became available, the War code was adapted and evolved by moving roughly half the code from Fortran into MACRO-10 assembly code. Combined with the Mainframe-class PDP-10 hardware, this made eighteen simultaneous players possible. All of these contexts are apparent in the Decwar build process.

The complex build process was not an end in itself; it was the means to create a specific software architecture designed to function optimally within the PDP-10's environment. The final structure of Decwar is a direct reflection of the solutions its developers devised to utilize the platform's capabilities. The game's design is, in essence, an embodiment of its own creation story.

A core feature of this architecture is its hybrid-language structure. The use of both high-level Fortran (DECWAR.FOR, SETUP.FOR) for game logic and low-level MACRO assembler (WARMAC.MAC, MSG.MAC) for data and text management was a deliberate choice. Fortran provided the necessary computational power, but it lacked the fine-grained control over memory layout and text handling that the developers required. By offloading text and critical data definitions to the assembler and then programmatically including them back via TECO and auto-generated Fortran code, they achieved the best of both worlds.

This approach was central to the game's sophisticated memory management strategy. On a typical PDP-10 system of the era, memory was a severely limited resource, placing immense pressure on developers. Memory was made of magnetic cores, an individual small torus or donut of magnetic material for each bit. Core memory has been invented for the Whirlwind and SAGE computers in the mid fifties and was still dominant through the sixties. It was necessarily expensive and a limited resource, small donuts of magnetic material simply do not scale up well. The architecture reflects a relentless focus on conservation, where techniques for saving every possible byte were not merely clever but absolutely necessary for the game to function.

• Segmented Memory. The game's memory was explicitly divided into a high segment and a low segment. This division was not left to chance; it was enforced by dummy routines (HIGH.FOR, LOW.FOR) and orchestrated by the custom linker (L.MIC), ensuring that data and code were placed in precise locations.
• One-Time Initialization Code. The game utilized initialization routines (SETUP.FOR, SETMSG.MAC) that ran only once, when the game started. Discussion in the commentary files makes clear that this code was "deleted from core" or "thrown away" after its purpose was served. This tactic was applied with multiple layers of sophistication; for instance, the generated file SETEXT.FOR "will be loaded into the Low-segment during SETUP, and thrown away after entering the game proper," revealing a multi-stage process of memory reclamation even within the setup phase.

This carefully engineered structure, a direct product of its toolchain, is the very object that modern-day efforts now seek to preserve and understand.

Following the generation of necessary source files, the compilation and linking phase begins. This is the assembly line of the build process, where disparate source components are transformed into a single, cohesive executable image. This stage is marked by careful management of the program's memory layout, a critical concern in the resource-constrained environments of the era.

The process consists of two main stages:

• Compilation: In this stage, the primary source files are compiled into relocatable object files (.REL files). This includes the main Fortran source (DECWAR.FOR), the MACRO assembly source (WARMAC.MAC), and the various generated source components. Key output files from this stage, as documented in DECWAR.IMP, include DECWAR.REL, WARMAC.REL, HIGH.REL, and LOW.REL. These object files contain machine code but are not yet a runnable program, as their final memory addresses have not been resolved.
• Linking: The responsibility for assembling the final executable falls to L.MIC, identified in the documentation as a "sophisticated linker." This tool takes the collection of .REL object files and binds them together, resolving symbolic references and creating the final Decwar.EXE file.

The role of L.MIC extends beyond simple linking. It is explicitly responsible for orchestrating the memory layout of the final program. Its key function is to load the .REL files in the proper sequence and, critically, to force specific common blocks into the correct high or low memory segments. This is achieved using what the developers' own notes call "dummy routines", HIGH.FOR and LOW.FOR, which serve as anchors for the linker to place the HISEG and LOWSEG common blocks into their designated memory regions. The tool's sophistication is further evidenced by a note in the source documentation: "Note you can DO L/H for help on building the Decwar core image," indicating a built-in help system for developers.