UTCC ARPANET IMP

We're learning much about the HRC DEC-10 site, from 1975 to 1983. Until meeting Rich and Clive, did not know the 10 was in HRC, always pictured it being in the old CC machine room under the stairs east of the Tower, beside the CDC 6600. And also always picture the ARPANET IMP was down there as well, installed in 75 or 76, almost in some way along with the 10. Hoping to learn more about this and now's a good time to record the current state of knowledge.

Now that we know the 10 was in HRC, it makes total sense and we're loving this part of the story. Right on the Drag, in a cool and interesting building with the History Collection there and the Art. Was Quackenbush's already there across the street on the Drag? Looking forward to learning how the move into HRC happened, who participated in that move, what was it like, who was there when the 10 was first installed, etc.

From: Noah Smith <Unknown>
Date: Sunday, January 25, 2026 at 4:38:14 PM UTC+1
Subject: Re: [pidp-10] Re: Join me, together we can rule the ARPANET
Hi Lars, we'd like to volunteer to adopt the utexas node as part DecwarOrg - suspect utexas was a bit after 1973 though, maybe around 1975 or so as a guess? fwiw, this below looks about right to me - so decwar.org node is a 'few years late':) but we'd love to be part of the story in whatever role!:)

1. Confusion with the "First Four" (1969) The "UT" in the original four ARPANET nodes refers to the University of Utah (Node 4), which was installed in December 1969. The other three originals were UCLA, SRI (Stanford Research Institute), and UC Santa Barbara.

2. Absence in Early Maps (1969–1974)1969–1973: UT Austin does not appear on ARPANET logical maps from this period. January 1974: A management study report from January 1974 explicitly noted that major commercial and research centers in "Texas are not" yet represented on the network, confirming that UT Austin was not yet connected at this time.

3. Installation and Connection (1975–1976) Appearance on Maps: The University of Texas (often labeled "Texas" or "UTEXAS" on logical maps) begins appearing on ARPANET maps between 1975 and 1977. Visual Confirmation: By the March 1977 logical map, "Texas" is clearly visible as a node, connected to the network alongside other expanding universities. Directory Evidence: The ARPANET Directory from 1978 lists the University of Texas at Austin (specifically the Linguistics Research Center and Computation Center) as a fully operational host.

From: Lars Brinkhoff <Unknown>
Date: Sunday, January 25, 2026 at 5:43:01 PM UTC+1
Subject: Re: [pidp-10] Re: Join me, together we can rule the ARPANET

There's room for more than one ARPANET project. Oscar is mainly aiming for an around 1973 network with historical hosts, and run them all on a single machine. I my first idea, and how I started this thread, is to have a somewhat later vintage network operated by enthusiasts connecting their computers together. An question for you is whether UTEXAS ran TOPS-10 or TOPS-20? I have some vague impression DECWAR was more of a TOPS-10 thing, but maybe I have that wrong. If UTEXAS was a TOPS-10 shop, the bad news is that we haven't located an NCP for that operating system.

Mainframe Culture

The middle of the 20th century marked a pivotal era in technological history, a period when the computational demands of industry and engineering forged a new, deeply interconnected technological ecosystem. From the 1950s through the 1970s the digital world was physically massive and purpose-built rather than mass-produced. Fueled by the geopolitical pressures of the Cold War, the challenges of optimizing energy and industrial operations and competing in the space and arms races could not be solved by any single component in isolation; they required a holistic system where each part was shaped by the capabilities and limitations of the others. The strategic importance of this period lies not merely in the invention of individual technologies, but in the indivisible links that formed between specific, high-value business problems (industrial optimization), a dominant hardware architecture (the 36-bit mainframe), and a programming language forged for that exact purpose (Fortran).

The narrative here will trace this co-evolution, moving from the foundational hardware to the software that harnessed it, the motivating algorithms that gave it purpose, and the subsequent technological shifts that redefined the user experience. This was not a linear progression of singular inventions, but a dynamic interplay where foundational hardware, novel programming languages, and powerful algorithms evolved in concert. These elements did not evolve in isolation; they formed a tightly-coupled technological ecosystem, each shaping and being shaped by the others. The evolution of these components was symbiotic. Hardware architecture dictated the design of compilers, which in turn influenced the structure of algorithms. Simultaneously, practical high-stakes industrial problems created powerful incentives that drove innovation across this entire space.

The example we’ll examine here is optimizing refinery operations for the energy industry using Linear Programming (LP) and the Simplex algorithm, made practical in the early 50s at RAND by Georg Danzig in conjunction with the first generation of commercial IBM digital computers. We’ll follow two related families of 36-bit mainframes that dominated two distinct eras, the IBM 7090 and the DEC PDP-10. The architectural evolution from the batch-oriented, tape-driven IBM 7090 to the interactive, disk-based DEC PDP-10 fostered a significant cultural shift in how computation was conceived and used. This is demonstrated here in the transition from large-scale strategic numerical optimization (Simplex) to shared, real-time virtual worlds (Decwar), exploring the core components of this early computing revolution: the imposing mainframes that provided the raw computing power; the Fortran programming language that made this power accessible; and foundational applications like the Simplex algorithm that translated computational capacity into tangible economic value.

To comprehend the software of the mid-1960s, one must first inhabit the physical and architectural reality of its native environment. A computing center of this era was a world of refrigerator-sized tape drives, the percussive clatter of teletypes and punch card hardware, and roaring cooling fans. It is strategically critical to understand that these were not viewed as obstacles to be overcome; they were the fundamental ecosystem in which all software was structured and evolved. The IBM 7094 and the DEC PDP-10 were each dominant systems and shared a common architectural heritage, but represented distinct evolutionary paths.

	IBM 7094	DEC PDP-10
Era of Dominance	~1957 - 1969	~1966 - 1983
Memory	Magnetic core memory with 32K 36-bit words.	Magnetic core memory with 1M 36-bit words.
Primary I/O Method	Punch Cards	Interactive Terminals (Time-sharing)
File System Concept	No formal file system; each magnetic tape reel was a single "file".	Modern file system with six-character filenames, suffixes, and disk-based storage.
Target Market Niche	Batch-processed "imperial scale" numerical computation.	Interactive "large scale" system, camouflaged to avoid direct competition with IBM.

The most defining characteristic of this hardware generation was its 36-bit word architecture. This was not an arbitrary choice but a direct consequence of the punch card. The 6-bit BCD (Binary-Coded Decimal) and Hollerith character codes, which represented data on punch cards, were the iron fact of reality. A 36-bit word was the natural and efficient way to store this information, as six 6-bit characters fit perfectly within it. This hardware reality is why 36-bit words, not the 32-bit standard that would later emerge, became the bedrock of mainframe computing. These physical hardware characteristics, from the nature of I/O to the very size of a machine word, profoundly shaped the software development practices that arose to master this powerful but unforgiving environment.

By analyzing each system (IBM 7094, DEC PDP-10) and representative applications (LP, Decwar), we will draw broader conclusions about the profound and often-invisible relationship between technology and creative practice, demonstrating with stark clarity how the historical dependencies between hardware, compiler, and code persist across decades. It reveals how these deep-seated relationships dictate the challenges and triumphs of modern digital preservation efforts, and how software is an artifact not just of code, but of its complete technological world.

UTCC DEC-10 Staff

Thank you to Richard Denney for the photos in this post, and to Rich and Clive Dawson for the information discussed here. 

We've learned an enormous amount in the last week from Rich and Clive, and would like to at least begin recording some of the core info as a kind of baseline reference for the future. Maybe the best way to begin is just to take a first small step and begin recording some names and connecting those with stories.

Meanwhile, a very interesting phenomena happened yesterday. I was researching the UTCC DEC-10 using google, and twice the results included a pair of names together, and it turns out they are the two people behind the teletype in the photo to the left, Clive Dawson in the blue shirt and Rich Denney in the green shirt. 

Currently I'm thinking, well, it could be that google could be aware of and tracking what I'm working on, and that influences the results. Or, it could be that Clive and Rich are a big part of the reason the results are including things like "The staff itself was described as an extremely close-knit group that felt a deep personal connection to the machine. This connection was shared by the users, many of whom spent thousands of hours connected while developing software and helping others."

The following two photos and accompanying info are from Rich.

This photo below is the going away party for Elissa Vogel in 78. George Culp is mentioned in the Creative Computing article. And David Phillips had taken on the manager role for the DEC-10 by 77 when I got there. Not sure where Clive was that day? At least three of the good people in that photo have left us. That is Rick Watson on the right. In that photo left to right: Kathleen (programmer new hire, went on to bunches of companies, Tandem, IBM), Mildred (help desk), Norma (secretary), Dawn (programmer), Bob Hysick, Doug DeGroot (programmer, PhD later), George, David (manager), Rick Watson, and of course Elissa Vogel operator. I was there 77-83 and did my masters under Elaine Rich in AI, then went on the AI ride til the big crash (AI winter #2).

To complete the list of managers, after David Phillips, Tommy Loomis was manger. Or maybe he took over after the shutdown with the DEC-20. That was around when I left so a bit fuzzy. Staff wise I think those I sent pretty much covers most everyone. Well .. Cecil, who was one of the operators, was missing. He left in 82. And Debbie (Rice?) that replaced Norma is not included. There's also the topic of DEC-10 users. Mary Jo (?) I remember. Those folks in the Linguistic group. There were a number in the offices on the floor that surrounded the DEC-10.

And the following info is from Clive.

I was at UT starting as a grad student in 1971 and left in 1985 to join MCC.  I was on the Computation Center staff starting in 1975 as a systems programmer for the DECSystem-10 through 1982 when the ’10 was decommissioned.  The final party was the subject of “The Soul of an Old Machine”.  Then I became the manager of the Research-20, a DECSYSTEM-20, until I left in 1985.

Bob Hysick was also on the DEC-10 staff and I was well familiar with his DECWAR project.  One of my projects during those years was the development of TECO-124, which among many other things added video support for dumb terminals to DEC’s standard text editors, TECO.  I was happy to see the TECO macro directory in the DECWAR sources!

I was also friends with Dave Matuszek and Paul Reynolds, fellow grad students and the authors of the original STARTREK game on the CDC-6600, which was one of the main inspirations of DECWAR.  My friend and fellow grad student Rich Cohen was also a good friend of theirs.  I’ve shared your original email message with him.  He stays in touch with Dave and Paul and can give you their contact info.  He can also suggest a few corrections to your timeline.  For example, he tells me that “Super Star Trek” was not done at UT, and was based on a stolen copy of the Matuszek/Reynolds original FORTRAN source.

While doing some rounds of feedback on this post, we got a bit more information that follows-on nicely and help build up the overall picture, so will just continue on with that below. This is from Rich.

Speaking of SWT in San Marcos, be sure to ask Clive about the "sister" DEC-10 that was there. I remember attending a LOTALUG meeting there a time or two (Louisiana, Oklahoma, Texas, Arkansas Local User Group).

We need to get confirmation from Clive that Tommy took over. I remember he had an office down the hall. Tommy was Board of Control, today's Comptroller Office. They had a 10 and were located north of the Capitol building. When Tommy moved to UT I don't recall exactly. But the first time we met he was at BOC.

Both Rich Cohen and Tommy wound up at Semantic Designs years later; Ira Baxter's company. Ira and I were both at Schlumberger and had a common good friend Jorge Boria RIP, also at Schlumberger. Then later I wound up consulting at the company Jorge was with, TeraQuest Meterics, a software process consulting. One of the principals at TQ is Joyce Statz who is now our neighorhood president and I do history articles for the newsletter.

Small interconnected world.

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.

Containers and Ultimate Portability

Initiated in the fall of 2025, the project's third and current stage is the culmination of the Decwar workflow evolution. The objective in this era is to free the entire system from any specific host hardware and achieve true simplicity and independence through containerization, creating a fully encapsulated digital artifact that can travel freely into the future. The architecture is a deliberate strategic decision to preserve the proven efficiency and authenticity of build-from-tape while leveraging containerization. The entire SIMH PDP-10 Decwar environment becomes a self-contained, portable ecosystem that can run on virtually any modern computer, whether it be a Raspberry Pi, a MacBook, a Windows machine, or a Cloud service. Once containerized, the system is "free to roam the Galaxy" and capable of running on any machine from a local laptop to a Cloud instance. The complex historical simulation is packaged into a simple, distributable artifact.

The architecture is a microservices-inspired, three component network managed by Docker Compose. Each component runs in its own container. On any machine with Python and Docker Engine, a user runs an install script once to pull the necessary Git repositories, and thereafter simply runs a start script to build and launch the entire three-container environment automatically. The only requirements are Python and the Docker Engine, making the entire workflow fundamentally portable. Three key technologies work in concert to deliver a seamless user experience. A Python script serves as the initial bootstrapper. It automates the one-time setup process by retrieving the Git repositories for generating the Docker containers. Docker is the core containerization technology that enables the encapsulation and isolation of the SIMH PDP-10 environment. It allows the complex legacy system and its dependencies to be packaged into a standardized and portable unit. Docker Compose is the orchestration tool used to define and run the multi-container system. It manages the networking and lifecycle of the individual containers, ensuring they launch and communicate as a single, cohesive system.

The environment is composed of three distinct Docker containers, each with a specialized role. Together, they form a complete, networked system for running and interacting with the Decwar game. The first container houses the reconstructed SDT and the SIMH PDP-10. It is responsible for the automated build of Decwar on every startup. The second container is both the primary controller and the primary API layer. It contains the main start script that initiates the entire Docker Compose system. It also provides the central REST API for controlling game robots. The third container is the presentation layer. It runs a web server that provides a visual interface to the running Decwar game by reading the central REST API to display game state.

This elegant three-container architecture separates concerns, making the system modular and manageable while providing a complete, end-to-end user experience and delivering tangible, transformative benefits for system development. By building upon the successes of the tape-based approach and leveraging modern containerization, the project provides a superior workflow that excels in portability, automation, and efficiency. Complete hardware abstraction is achieved by design. Unlike previous eras, which were tied to specific host configurations, the containerized system is entirely self-contained and capable of running on any machine that supports Python and the Docker Engine. This eliminates hardware dependencies and allows the development environment to be deployed consistently across developer laptops, testing servers, and cloud instances. Procedural, multi-step workflows are replaced with a declarative, single-command system activation. The entire lifecycle of the environment, from fetching source code to building the SIMH PDP-10 system and launching all necessary services, is condensed into a single start script. This push button simplicity drastically reduces setup time, eliminates the potential for human error, and makes the system accessible to those unfamiliar with the underlying DEC PDP-10 architecture. The project’s architecture inherits and perfects the speed of the tape-based workflow. The process of creating a tape image remains nearly instantaneous, and the SIMH PDP-10 Decwar startup and build cycle completes in seconds. By containerizing this already-efficient process and automating it end-to-end, the fastest, most reliable, and most repeatable development cycle is achieved. These combined benefits represent a paradigm shift, moving the historical artifacts from a specialist's pursuit into the realm of modern, professional engineering.