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.