1976 Photo of the UT Austin DEC-10

This post is entirely about the images down below. Many are from the website AtariArchivesOrg. It’s highly recommended to explore the website, despite the ads. It turns out that there was a two page article about UT in a 1976 issue of Creative Computing magazine, including a picture of the DEC10 in 1975/1976. The article describes it as a recent acquisition, and it’s almost certainly the machine used to begin writing Decwar in 1978. Here’s a direct link to the Atari Archive source.

There's more context. Creative Computing magazine was the vehicle of David Ahl, who also published the Star Trek BASIC code repeatedly from around 1973 and is in some sense at the heart of the single-player Star Trek story that led to Decwar. In other words, Ahl published an article about the UT DEC10 a few years before it was used to create an ultimate version of the Star Trek game he was championing. In the early days of the microcomputer revolution, Creative Computing and BYTE were the two pillars of the industry. While they were friendly competitors, they served different niches and even collaborated occasionally before being absorbed by larger corporate entities. Creative Computing (1974), founded by David Ahl, is widely considered the first personal computer magazine. Ahl, a former DEC employee, launched it to focus on the educational and playful side of computing. BYTE (1975) was launched about a year later and quickly became the journal of record for the industry, known for its technical depth and massive, brick-like monthly issues.

Pursuing Authenticity and Efficiency with Tape Images

The project's second stage, which began at the end of 2024, represented a strategic and philosophical shift. The motivation was not merely to escape the awkwardness of client-server file transfers, but to pursue an ideal vision: a complete Decwar PDP-10 system built from scratch using only SIMH tape images of original authentic DEC tapes. The ambition was to build TOPS-10 from DEC source tape using MONGEN (MONitor GENeration, analogous to building UNIX or Windows from source code), then install the appropriate DEC Fortran IV from DEC source tape (DEC FORTAN-10 V6), then install Decwar from reconstructed UT Austin SDT, build, and play.

The transition to a tape-based workflow marked a major jump up in efficiency and realism, with immediate and substantial improvements in cycle time and development ergonomics, rendering the Kermit-based approach obsolete for active development. The new process involved editing source files locally, creating a new SIMH tape image, an automated process taking less than a second, and simply restarting the SIMH PDP-10. The entire process, from end to end, takes a matter of seconds and is invoked with a single command or push of a button.

The new workflow was centered on SIMH tape images. The impact was profound, creating a much smoother and more flexible workflow. The paradigm shift was so complete that Kermit and client-server file transfer have completely vanished in practice and are retained as possibilities mostly for historical reasons, much like the possibility of using a terminal to perform interactive file editing on the PDP-10 using SOS or TECO. They’re possible and interesting historically, but not effective everyday workflows.

Beyond efficiency, this shift held deep cultural significance. By using the reconstructed SDT for every build, the project was "eating their own dog food." This practice is the ultimate validation of the archeological work, proving the integrity of the artifact by using it as the foundation for further progress. This also makes the entire process feel "super realistic". The technical elegance of this approach lies in its fidelity to the original hardware paradigm. The SIMH PDP-10 interacts with the tape image without awareness that it is not physical hardware. This commitment to authenticity is demonstrated in practice with every build from reconstructed SDT, ensuring a clean and consistent environment. While this Tape Era perfected the local build process, it remained tethered to a specific host machine's configuration, setting the stage for the next evolutionary step: total environment abstraction.

An Initial Pragmatic Bridge to the Past

Kermit history from the creators

Beginning in the fall of 2024, the project's first stage was defined by a fundamental logistical problem: how to transfer newly edited source code from a modern host computer onto the SIMH PDP-10. The initial solution was Kermit, a venerable client-server protocol that characterized the project's first development workflow. This approach required running Kermit on both ends, a modern host and the PDP-10, to establish a communications bridge for file transfers. Originally created in 1981 at Columbia University to allow users to move files between smaller computers and campus mainframes, Kermit requires the user to manually run executables on both the local host and the mainframe. In some sense Kermit is a serial terminal style ASCII connection between two user-layer executables, and piggybacks its own file transfer protocol on top of that. This can be juxtaposed with the early 70s ARPANET protocols such as TELNET and FTP which are in some sense lower-level and more deeply integrated into the operating system layer.

The concept for Decwar was to edit Fortran source files locally, then use Kermit to transfer them to the PDP-10. Another apparently simple alternative was to edit Fortran source interactively on the PDP-10 via telnet session using vintage DEC tools such as SOS and TECO. While entertaining, this very quickly proved too slow and cumbersome.

The Kermit workflow, though an indirect way to code and test, was at least somewhat automateable using Kermit's scripting capabilities. One would edit Fortran source files on their local machine, and an automated script would then use Kermit to move those files over to the PDP-10 in order to rebuild Decwar and prepare it for testing. This workflow had a dual nature. It was a learning tool that enabled the project to get started quickly, and it was indeed worthwhile to learn more about Kermit because of its familiarity and relative ease. At the same time, this method imposed significant limitations. The process was comparatively slow and more than a little bit awkward, highlighting the friction between the modern and historical systems and ultimately serving as the catalyst for a more integrated methodology.

In retrospect, this workflow, while functional for initial system exploration, presented significant efficiency bottlenecks. It likely slowed down progress compared to what would have been possible using better approaches. The reliance on manual, multi-step file transfers created an indirect and cumbersome development cycle that was ripe for optimization.

From the Command Line to Containers

The endeavor to reconstruct a fully functional UT Austin Decwar SDT represents a significant act of digital archeology. The project's evolution through three distinct stages in its development workflow offers a unique case study in the nature of computing systems. It demonstrates how a system is defined not just by its original hardware and software, but by the modern tools used to resurrect and interact with it. Developing and maintaining software for legacy computing environments such as the DEC PDP-10 presents a unique set of challenges. These systems, while historically significant, often rely on workflows and hardware that are incompatible with modern development practices. The need to bridge this technological gap, preserving the integrity of the original environment while leveraging the efficiency of contemporary tools, is paramount.

For any software reconstruction project, the first strategic imperative is to establish a stable, simulated hardware environment. This foundation serves as the core or historical substrate, upon which all subsequent creative and technical work is performed. For the SDT project this foundation consists of a meticulously simulated historical computing environment with DEC PDP-10 hardware running the TOPS-10 operating system and a particular early Fortran IV compiler. This environment forms the static, historical core around which the project's dynamic and evolving development workflow is built. It is this core that the developers had to interact with, leading to the initial dynamic challenge of bridging the gap between modern tools and the faithfully recreated past.

This document will examine the three eras of this reconstruction, beginning with the foundational SIMH PDP-10 environment itself and tracing the evolution of the development methodology from earlier, more cumbersome methods to a modern containerized approach, detailing the technical components and concluding with an analysis of the benefits this modernization delivers.

To fully appreciate the innovations of Project SDT, it is essential to understand the historical development workflows that preceded it. The journey toward a modern, portable environment was a three-stage evolution, with each phase introducing improvements while also revealing limitations that prompted the next leap forward. This progression from early manual experiments to a fully abstracted, containerized system highlights a deliberate path toward greater efficiency and portability.

The journey from initial dependence on the Kermit protocol and simple file transfers into and out of a SIMH PDP-10, to a more authentic system using SIMH tape image files and a reconstructed SDT, and finally to a fully containerized environment reveals a fascinating interplay between historical authenticity, developer efficiency, and the modern imperative for portability. We will trace the project's workflow from the pragmatic but awkward Kermit era of 2024, through the efficient and realistic SIMH tape image era that began at the end of 2024, to the ultimate containerized portability achieved in late 2025, a year after the project's inception. This progression is a compelling narrative of how a historical platform is re-contextualized and ultimately preserved through the lens of contemporary technology and development culture.

The result is a modern, container-based solution designed to overcome many of the practical obstacles. It transforms the intricate process of building and running a complete PDP-10 system and environment into a simple, automated, and platform-independent workflow. It simultaneously achieves historical fidelity by preserving the original tape-based build process and embraces modern principles through complete automation and hosting abstraction. By encapsulating the entire environment, both legacy and modern, within a set of interoperable containers, the project has freed the historical UT Austin Decwar artifacts from hardware-specific constraints and manual, time-consuming setup procedures.

Setting the Stage for the UTCC Part 2

The evidence indicates that the LBJ presidency, from late 1963 to early 1969, was a catalyst for this shift, leveraging his political power to cultivate a new technological corridor in his home state. The interconnected developments of the 1960s demonstrate his influence. This confluence of political, industrial, and academic expansion positions LBJ not merely as a benefactor but as a prime political architect of the technological ecosystem that culminated in the UTCC’s 1966 acquisition of a state-of-the-art CDC 6600 supercomputer. This was the institutional capstone of these powerful, politically-driven forces.

Fittingly, a specially designed building was created to house the supercomputer, just to the east of the UT Tower, at the head of the East Mall. This unique building still bears the simple name of Computation Center, though it has long since become obsolete and been repurposed as a backup emergency data center. It is built of the local tan colored limestone, like most of the classic campus buildings, but is uniquely mostly underground, with the Tower’s wide eastern terrace as its roof. This underground location is said by some to be so that it doesn’t block views of the Main Building and Tower. Others say that the motivation was the CDC 6600’s cooling requirements and its sheer complexity. The system contained 400,000 individual transistor components and more than 100 miles of internal wiring. Cooling was via a Freon refrigerant system that circulated through metal plates in contact with tightly packed circuit boards designed to keep wire lengths short and signal speeds high.

In any case, from the Computation Center’s broad terrace roof, a wide flight of stairs descends to the East Mall and directly faces a unique landmark complex of buildings in the distance, the Lyndon B. Johnson Presidential Library. The view and scene are ideal, as the Library is a superb embodiment of the fifties and sixties era and a monument to the spirit of those times. It is a "living Star Trek set" giving architectural form to an era that believed the world's problems could be solved through operations research, systems analysis, and computational power. One can easily imagine Captain Kirk and Mr. Spock beaming down besides the Library’s main Tower, an utterly unique Space Age masterpiece.

This was the worldview that drove the Apollo program. Big science took on bureaucratic form in a proliferation of research centers and, at UT Austin, physical form in the establishment of the Pickle Research Campus, isolating sensitive Cold War projects far from the main campus. J.J. Pickle was at the heart of LBJ’s inner-circle, and the name is a fitting reminder of the era. The political and geographic transformations driven by the LBJ era set the stage for a series of highly consequential technological decisions that would define the university's future role in national research.

The creation of the UTCC and its associated academic centers was part of the national effort to ensure that the practical knowledge forged by Cold War and Space Race efforts was communicated into new academic disciplines, creating a lasting foundation for future generations of scientists and engineers. The objective here is to trace how that process took place in two particular cases: the work of two researchers, George Dantzig and David Young, at two companies, RAND and TRW, and how both of these currents flowed into and shaped the ensuing growth of UT Austin.

As part of tracing these two intellectual currents, some background context is helpful. Both currents, the work of Dantzig and that of Young, share a deep underlying basis in mathematics and physics. A deepened understanding of the nature of this underlying reality is in fact one of the types of knowledge that was clarified and transferred by the new academic channels created during this period. The structure and content of the textbooks, courses, and even departments were completely reshaped in the fifties and sixties. The fact they have been fairly stable for the following five decades points out how definitive the changes were. As part of exploring the stories of Dantzig and Young, this underlying context will be pointed towards and foreshadowed where appropriate, in preparation for a dedicated discussion of floating-point hardware and computerized linear algebra.

Floating-point hardware lagged behind the general-purpose digital computer. Digital computing became practical during the forties and then grew explosively into a powerful tool during the fifties under the impulse of the Cold War and Space Race, while floating-point hardware developed more slowly across the fifties and sixties. It was not at all obvious from the beginning that floating-point would play the critical role that it did. In fact, John von Neumann famously opposed putting effort into floating-point. That story will be explored here as an example of how the course of events was not at all obvious and straightforward to the researchers involved at the time, and to highlight the pragmatic roles played by Dantzig and Young.

The raw power of early digital computers could only be unlocked through the creation of systematic, repeatable algorithms. This marked a fundamental change in approach for problem-solving; a decisive move away from an adhoc, human-centric expert art, towards the standardized, machine-executable automated science of rigorous mathematical procedures. The intuitive calculation methods of the pre-computer era had to be replaced with standard algorithms that could be expressed in computer code and then executed automatically, a shift essential for solving problems at a scale previously unimaginable.

This was the birth of modern linear algebra, numerical analysis, scientific computing, and computational science. In the fifties and sixties, this field was largely synonymous with the complex challenge of solving systems of linear equations, using applied linear algebra executed with pure floating-point arithmetic on the most advanced machines available. Later, the overarching terms supercomputing and high-performance computing would also become synonymous with this field. It was here that the careers of key individuals like George Dantzig and David Young flourished. They were computational pioneers whose expertise was shaped in the dense aerospace and defense milieu of Southern California. The professional connection between them was forged within this Los Angeles ecosystem, rooted in the shared and foundational discipline of numerical computing. 

Setting the Stage for the UTCC

The Cold War and ensuing Space Race were a context where military imperatives, academic breakthroughs, and shrewd political maneuvering converged, creating the conditions for a world-class computational facility to take root in Austin. The direct influence of LBJ was a driving force behind federal investment in Texas. LBJ's well-established ties to the aerospace industry in Dallas helped steer contracts and development to the region. The establishment of the Manned Spacecraft Center in Houston was a signature achievement of this effort, anchoring the Apollo program in Texas.

Concurrent with these industrial and federal developments, UT Austin experienced a rapid increase in funding, enabling its ambition to become a top-tier research institution. UT provided a unique and essential combination of academic skills and computational resources that were vital to the Cold War mission, particularly in aerospace. The university became a center of excellence in geodesy, gravity field determination, and orbit determination, skills fundamental not only to the space and missile programs but also to regional economic drivers like Texas oil exploration.

The strategic convergence of elite talent, state-of-the-art supercomputing hardware, and targeted federal funding allowed UT to institutionalize its expertise. The creation of the UT Computation Center established UT as a national center for supercomputing, aerospace research, and numerical analysis for a generation. From this base, it projected its influence directly into the nation's most critical Cold War aerospace and defense research programs.

The 1958 National Defense Education Act formalized the Space Race and established the federal government's significant role in education through student loans, fellowships, and curriculum support. It marked the first time the federal government injected significant funding into higher education, framing it as a matter of national security. The results were transformative, creating the modern American university system and the federal student loan infrastructure. It effectively militarized the justification for education funding, leading to a golden age of American research universities. It converted the U.S. education system from a local responsibility into a key component of national security policy.

The Space Race was an expression of a much broader cultural and ideological zeitgeist that defined the fifties and sixties. This era was defined by a profound faith in big science, systems analysis, and centralized, computer-driven problem-solving. It was also marked by an equally dramatic transformation of this worldview in the subsequent decade, with the seventies becoming an era of limits and inward-looking Earth-centered humanism.

This was also a period of profound geographic and political realignment in the American scientific-industrial complex. There was a purposeful migration of leading researchers from defense-oriented corporations and laboratories back into universities. This was explicitly the means by which sensitive technologies were released into the broader commercial and educational spheres, via the individuals directly involved, making the interpersonal links between leading researchers central to understanding what was taking place.

Driven by powerful political and economic forces, the center of gravity for aerospace and computational research began a shift from its established base in Southern California to the rapidly emerging ecosystem in Texas. This movement was effectively a dispersal of the Los Angeles aerospace and Cold War researchers, seeding their expertise into new academic institutions as part of a new national network for computational science.

A particularly powerful connection was forged between UT Austin and the NASA Jet Propulsion Laboratory in Los Angeles. This relationship was so strong and influential that it became widely known by its moniker, the UT Mafia. A key figure in cementing this bond was Byron Tapley, founder of the UT Center for Space Research. Even earlier, in the fifties, there were already important researchers binding California to Texas. The roles of George Dantzig and David Young and their ties with the Los Angeles based RAND and TRW corporations are explored in depth here.

RAND and TRW were the intellectual and industrial engines of the American Cold War. While the military provided the funding and the mandate, these two organizations provided the strategy and the systems engineering that built the U.S. nuclear arsenal and space program. Their early histories are deeply intertwined with the U.S. Air Force’s desire to harness scientific brainpower outside of the traditional military hierarchy. Safe in their Santa Monica headquarters, RAND civilians pioneered Operations Research, Game Theory, and Systems Analysis. If RAND provided the theory, TRW provided the management for Los Angeles based contractors (Lockheed, North American Aviation, Douglas Aircraft, Northrop, Hughes Aircraft) to build the hardware, creating the modern discipline of Systems Engineering.

Deconstructing the Decwar Source Distribution Tape

The Decwar SDT serves as a remarkable archaeological record, preserving not just the game's code but the very practices of its creators. The process of reconstructing this artifact is akin to a digital excavation, where the DECWAR.TAP file, a listing of the original tape's contents, acts as the site map. This file is the key to distinguishing the original architecture from later modifications.

Essential to interpreting this map are the commentary files, which function as Rosetta Stones for the project. These documents, DECWAR.IMP (IMP for “implementation”) and several .COM files (COM for “commentary"), contain the developers' own notes, explaining the purpose of the myriad files and the relationships between them. Without this guidance, the logic of the source code's organization would be harder to decipher.

These records reveal an archaeological finding. The game's core logic originally resided within a single, monolithic Fortran file, DECWAR.FOR. The dozens of separate Fortran files seen in modern repositories are anachronistic, an probably associated with CompuServe.

Recognizing this fact is significant for understanding the game's original hybrid structure, which contrasted the massive Fortran core with a collection of smaller, targeted MACRO assembler files like WARMAC.MAC and MSG.MAC. While Fortran handled the main gameplay, the MACRO assembler was employed to solve specific technical challenges associated with Fortran IV and with the DEC environment.

Based on the developers' commentary, the motivations for this hybrid approach were precise and pragmatic. Dummy Fortran routines, specifically HIGH.FOR and LOW.FOR, were used to implement memory segmentation. Containing no game logic, their sole purpose was to provide anchors for the linker to correctly place shared memory blocks (HISEG.FOR and LOWSEG.FOR) into distinct high and low memory segments. The developers used the assembler to handle text strings, noting that it allowed them to "get rid of the annoying trailing blanks Fortran generates for literals," a subtle but important optimization for both memory and display. Setup routines (SETUP.FOR, SETMSG.MAC) were written as separate modules that could be "deleted from core after initialization," a crucial technique for conserving precious memory during gameplay.

The DECWAR build process was far more than a simple sequence of compilation and linking. It was a multi-stage pipeline that automated the generation of source code and documentation from master files before assembling the final executable. The following sections provide a step-by-step deconstruction of this workflow, demonstrating how code generation, documentation compilation, and sophisticated linking were integrated into a single, automated system.

The first stage of the build process involved automated code generation using TECO macros. TECO, a powerful text editor of the era, was leveraged as a primitive scripting engine. A series of scripts with a .TEC extension were executed to process the primary MACRO assembler source files, specifically WARMAC.MAC, MSG.MAC, and SETMSG.MAC. These scripts would "crawl over" the assembly code, extract specific information, and reformat it as valid Fortran code. This process automatically generated several critical Fortran files, which were then used throughout the rest of the project.

The strategic purpose of this metaprogramming was to establish the assembly code as the single source of truth for shared parameters, memory layouts (common blocks), and external text strings. By auto-generating the corresponding Fortran INCLUDE files, the developers ensured consistency and eliminated the risk of manual data entry errors between the assembly and Fortran domains. This entire mechanism, however, relied on a non-standard feature of DEC's Fortran IV compiler, the INCLUDE statement.

Concurrent with source code preparation, the Decwar build process also automated the creation of user-facing documentation using RUNOFF. As one of the earliest text-formatting systems, RUNOFF is a direct ancestor of modern tools like troff, LaTeX, and the entire "documentation-as-code" paradigm. It allowed developers to write documentation in plain text files with simple formatting commands and then "compile" them into polished, final documents.

Within the DECWAR project, RUNOFF scripts were used to process text-based source files like DECWAR.RNH and DECNWS.RNO. This compilation produced the final, formatted documents that were shipped with the game, DECWAR.HLP (the help file) and DECWAR.NWS (the news file). The integration between the project's different toolchains is evident in how this process was invoked. The use of MICRO scripts, MAKHLP.MIC and MAKNWS.MIC, to control the RUNOFF compiler demonstrates the types of automations that have become common with command shell scripts and Python. MICRO is notable for providing parsing of the arguments in the calling command line and the ability to respond with primitive help messages. This is a direct ancestor of modern scripting tools. After generating both the necessary Fortran includes and the user documentation, the pipeline could proceed to the final stage of creating the executable program.

The final and most complex stage of the build was orchestrated by a MICRO script L.MIC which is described as the “sophisticated linker”. Today this script would probably be described as a wrapper around the DEC linker. L.MIC contains the sequence of commands to be entered at the monitor and linker prompts. The same effect can be achieved manually by a human typing at a terminal. MICRO and L.MIC automate that and remove the human from the loop. It dictates the precise sequence for loading the various object files to ensure correct symbol resolution and program structure. The script was used to explicitly force specific Fortran common blocks (HISEG and LOWSEG) into distinct high and low memory segments. This was accomplished by linking dummy Fortran routines (HIGH.FOR and LOW.FOR) whose sole purpose was to declare the HISEG and LOWSEG common blocks, respectively, thereby anchoring them to the desired memory regions during the linking process. This level of granular control over memory was essential for the game's operation on the PDP-10’s core memory system, and showcases a level of sophistication typically associated with modern systems programming. L.MIC is perhaps an ideal showcase of MICRO as a primitive scripting language.