The DEC Ecosystem and Deciphering the Source Distribution Tape

To understand an artifact like Decwar, one must first understand the environment in which it was forged. The DEC computing ecosystem of the sixties and seventies was a landscape defined by a specific set of tools and programming languages. The Decwar build system is deeply embedded in the DEC ecosystem of the era, utilizing a suite of proprietary assemblers, linkers, and non-standard language extensions. These were not merely implements; they were the fundamental building blocks and conceptual frameworks available to developers, shaping how problems were perceived and solved.

The primary high-level language used for Decwar was Fortran IV. However, Fortran IV was far from standardized in the sense associated with modern high-level languages. To enable its modular, auto-generated code structure, the project required an INCLUDE statement, but an examination of Fortran IV documentation from the sixties reveals the absence of INCLUDE. Fortran IV was rooted in and strongly associated with the punch card era of computing, when a program and its source code meant a physical deck of punch cards. Even the concept of an INCLUDE statement does not make sense when working with punch cards. One needed to simply physically include the necessary punch cards in the deck being fed into the punch card reader.

The INCLUDE statement used by Decwar was a DEC-specific extension that allowed the compiler to pull in the contents of another file during compilation. DEC famously extended Fortran IV to provide more powerful features, a prime example being the INCLUDE statement. This practice was part of the larger Fortran Wars of the time, where hardware manufacturers like DEC offered proprietary extensions that, while empowering their own developers, created platform-specific incompatibilities that fragmented the programming landscape. While essential for the DECWAR build process, this type of proprietary language extension created incompatibilities with other Fortran compilers and was a key issue in the Fortran Wars.

Even a cursory examination of the DECWAR.TAP file manifest reveals a crucial architectural insight. The original distribution contained only a single primary Fortran source file, DECWAR.FOR. Recognizing that the original design was monolithic simplifies the understanding of the build architecture. This monolithic design underscores the importance of the automated tooling; without a reliable way to generate and INCLUDE consistent common blocks and parameters, maintaining such a codebase would have been error-prone. This file architecture provides the foundation for understanding the dynamic processes that brought them together to build the final executable.

Reconstructing the Primordial Environment

The preservation of a software artifact like Decwar has cultural and historical value for what its creation reveals about a specific technological moment. Project SDT, through its source tape reconstruction effort, is engaged in a form of digital archaeology. This work moves beyond simply archiving a playable artifact; it is a deep investigation into resurrecting the entire ecosystem in which the game was born. An ecosystem centered on the UT Computation Center (UTCC).

The Decwar build system is a powerful and remarkably complete example of how a platform's unique characteristics profoundly influence software design. The PDP-10's memory architecture, the capabilities of its available tools, and its surrounding cultural heritage were not passive backdrops; they were active forces that shaped the game's final form. Every architectural choice, from the hybrid-language model to the segmented memory, can be traced back to a challenge that had to be overcome or a tool that could be cleverly exploited.

In this artifact, we can see a clear line of influence from the early "hacker" ethos of tool-building and system mastery, represented by the deep and inventive use of TECO, to the disciplined, large-scale software engineering required to build a persistent, multi-user game. The process reveals a UTCC development culture that was at once creative and highly pragmatic.

The project's explicit goal is to precisely match the contents of the original Source Distribution Tape. The file DECWAR.TAP serves as the authoritative blueprint, the foundational document that dictates every source file, tool, and intermediate object required for a faithful reconstruction. It is an exacting process, guided by the principle of historical accuracy.

Ultimately, studying historical build processes like that of Decwar uncovers the hidden labor, the contextual pressures, and the sheer ingenuity embedded within software artifacts. The legacy of Decwar is therefore twofold: a landmark game, and the enduring lesson that a platform's architecture is not merely a foundation, but an active, cultural force that dictates the very shape of ingenuity.

The Decwar build process represents a remarkably well-documented and sophisticated example of software development practices from its era. Its key characteristics—a reliance on a central manifest in DECWAR.TAP, the innovative use of TECO macros for automated code generation, and sophisticated control over memory segmentation during the linking stage—demonstrate a mature and disciplined approach to software engineering. This system was designed not just to produce an executable, but to be a maintainable and distributable development environment in its own right.

The historical significance of this process lies in its completeness. It provides a clear window into how complex software was constructed before the advent of modern integrated development environments and standardized build tools. The TECO-based workflow, in particular, is a direct link to the foundational principles of text-based automation that defined early software development.

The significance of this effort lies in its experiential value. By resurrecting the entire build environment, Project SDT allows technical historians to move beyond theoretical analysis. This reconstruction allows us to witness the culture in action: the discipline reflected in the meticulous DECWAR.TAP manifest, the pragmatism of discarding initialization code to save precious bytes, and the self-reliant ingenuity of a team that built its own tools to bend the platform to its will. With DECWAR.TAP as the blueprint, Project SDT is meticulously rebuilding the historic structure brick by digital brick.

This work of digital archaeology led directly to a modern preservation breakthrough. The practical outcome is a fully functional, simulated development environment within a concrete functional artifact. The collected files are written to a SIMH tape image, which is then used to perform a "fresh Decwar build on every SIMH PDP-10 start." This means that each time the simulation runs, it is not merely loading a pre-compiled game; it is re-enacting the original, complex build process from scratch using the reconstructed tools and source materials, as they were in the UTCC of the seventies and eighties. This image allows for a fresh, authentic Decwar build to be executed on a modern emulation of the original PDP-10 hardware, preserving not just the final game but the entire software ecosystem and the intricate process that brought it to life.

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.

Ingenuity and Tool Use

The Decwar developers did not simply use the standard tools provided by the PDP-10 platform; they forged a sophisticated, multi-stage pipeline tailored to the specific demands of their project. This custom toolchain is a powerful indicator of their deep, practical understanding of the system's architecture, particularly in the context of memory management and the interoperability between Fortran and assembler.

Central to this toolchain was TECO (Text Editor and Corrector), a powerful and historically significant tool whose use connects the Decwar project to the very roots of the hacker culture of the PDP-1 era, as chronicled by Steven Levy. In this context, TECO was not used as a simple text editor but as a potent code generator. This act demonstrates a specific cultural response, a refusal to accept the base language's inadequacies, which is a hallmark of the hacker ethos. In an era before modern build systems, this macro-driven workflow served as a primitive but highly effective form of dependency management and code generation.

The developers wrote TECO macros (.TEC files) that functioned as a meta-language to control and augment Fortran. Its primary function was to extract specific content from larger master source files and auto-generate derivative source files meticulously prepared for compilation. The purpose of this extraction was a deliberate architectural strategy to overcome the limitations of the platform and its languages. By generating modular Fortran INCLUDE files, the developers could programmatically enforce consistency and manage critical resources:

• Parameters (PARAM.FOR): A single, authoritative source for game constants was extracted from WARMAC.MAC, ensuring that parameters were centralized and consistent across the entire Fortran codebase.
• Memory Segments (HISEG.FOR, LOWSEG.FOR): Common blocks were automatically defined and extracted to force data structures into specific high and low memory segments, a critical technique for managing the limited address space.
• Text Strings (EXTERN.FOR, SETEXT.FOR): External declarations for text strings were generated from MSG.MAC. This enabled two key architectural goals: it allowed the team "to force text into the high segment" and to sidestep the "annoying trailing blanks Fortran generates for literals."

This workflow revolved around a clear relationship between three key file types, forming a simple but powerful toolchain:

• .TEC files: These are the human-readable TECO macro source files. They contain the logic and commands for the build tools and, according to project documentation, require TECO version 124 to function.
• .SAV files: These are the executable TECO macros generated from the .TEC sources. They function as the build tools themselves, performing the extraction and generation tasks.
• .FOR files: These are the final Fortran source code files generated by the .SAV macros. They contain critical definitions and declarations ready to be included by the main program.

This auto-generation of code played a central role. The generated .FOR files, such as PARAM.FOR (defining constants) and HISEG.FOR (defining the high-segment common block), are not standalone programs. They are critical dependencies that are subsequently incorporated directly into the main DECWAR.FOR source code using an INCLUDE directive. This system of code generation ensured that parameters and memory layouts defined in several master source files, such as WARMAC.MAC for parameters and common blocks, and MSG.MAC for text strings, were propagated consistently throughout the program. Once these source files are auto-generated, the process moves to compilation and linking.

Beyond TECO, the .MIC files and MICRO interpreter represent another layer of this sophisticated process. MICRO was a convention for executable scripts that automated TOPS-10 Monitor command lines, much like modern shell scripts.

• L.MIC was used as a custom "sophisticated linker". It took the various relocatable object files (.REL files) generated from both Fortran and MACRO assembly code sources and loaded them in the correct sequence and into the proper memory segments to produce the final DECWAR.EXE file.
• Documentation Tools (MAKHLP.MIC, MAKNWS.MIC) were used to build the user-facing help and news files from their respective sources, using the RUNOFF documentation formatter. Their inclusion on the SDT demonstrates that the custom toolchain was designed to manage the entire project lifecycle, from code compilation to end-user documentation.
• Indexing and Search were aided by two TECO macros. NDX.TEC is the source for NDX.SAV, which creates DECWAR.NDX, a file listing DECWAR.FOR routines and their page numbers. PAGE.TEC is the source for PAGE.SAV, which searches the DECWAR.NDX file to find the page number for a given subprogram, aiding in source code editing.
• Content Management was automated via CONTEN.MIC, a MICRO tool used to create contents for a MACRO file, recompile it, and generate and print a CREF listing.

This intricate toolchain was the engine that enabled the game's unique software architecture, a structure born directly from the necessity of navigating a sophisticated workflow.

Unearthing the Source Distribution Tape

A computing platform is never merely a collection of hardware. It is a crucible, a complex ecosystem of tools, cultural practices, and latent potential that fundamentally shapes what can be created within it. The landmark game Decwar is a powerful testament to this reality. More than just a piece of software, it stands as the intricate product of a unique and demanding development environment built upon the PDP-10 platform. The game's very architecture is a fossil record of the challenges its creators faced and the ingenious solutions they engineered, reflecting a hacker-ethos of tool-building, a disciplined engineering approach to resource management, and a pragmatic focus on automation.

An intricate, multi-stage procedure is used to compile and link the Decwar code. The process highlights a reliance on period-specific tools and methodologies that represent a sophisticated approach to software engineering for their time. Understanding this build system is crucial not only for the digital preservation of the software itself but also for appreciating the evolution of development practices. The toolchain provides a tangible link to a pivotal era in computing history, particularly through its use of tools with deep historical roots.

At the heart of this historical investigation is the Source Distribution Tape (SDT), a digital time capsule preserving the development environment in which Decwar was forged. The modern-day reconstruction project represents an act of digital archaeology, a meticulous effort to restore this ecosystem not simply to run the game, but to understand the creative and technical practices it fostered. This effort was, in fact, catalyzed by a deep investigation into the contents of the SDT.

The strategic importance of the SDT cannot be overstated. Unlike a normal transport tape intended for end-users, which would contain only the executable file and documentation, the SDT is a comprehensive snapshot of the entire development workshop. It contains not just the final product, but the raw materials, the custom-built tools, the intermediate components, and the procedural notes required to construct the game from scratch. The SDT was designed to distribute the full development environment. It contains not just the end products but the entire ecosystem of source code, intermediate object files, build tools, and documentation sources required to perform a complete, fresh build of the Decwar game.

The purpose of this document is also to provide a technical overview of the Decwar build process, detailing the file dependencies, code generation techniques, and compilation sequence. This analysis is based on the reconstruction efforts of Project SDT, which has worked to meticulously document and replicate both the contents and purpose of the essential files. An objective of the reconstruction is a SIMH tape image which enables a fresh automated build of Decwar during every start of the system.

Project SDT is a dedicated effort to reconstruct the primordial Decwar Source Distribution Tape, a task catalyzed by a deep analysis of historical files that had previously received little attention. The reconstruction's primary guide is the DECWAR.TAP file, which lists the essential contents of the source tape. While DECWAR.TAP provides the manifest of essential files, additional context is supplied by a set of implementation and commentary files: DECWAR.IMP, DECWAR.COM, HLP.COM, and MSC.COM. These documents offer descriptive annotations on the roles of various files and provide insights into the build logic that complement the simple listing in the manifest. As we will see, many of the essential source files listed in this manifest are not written by hand but are auto-generated by powerful scripting systems.

The build process is heavily dependent on tools such as TECO, RUNOFF, and MICRO. These are tools whose own history connects back to the early 1960s and the foundational era of interactive computing chronicled in Steven Levy's book Hackers. TECO was created in 1962 for MIT PDP-1s. RUNOFF was created in 1964 for the MIT CTSS system and became associated with both DEC and early Unix systems. MICRO was a tool for scripting sequences of TOPS-10 monitor commands. These tools perform the critical function of extracting specific content such as common blocks, parameters, and external declarations from large MACRO assemble source files to auto-generate Fortran source code.