RAND, SAGE, and Lisp

Robert Simmons began the Cognitive Science program at UT in 1968 after moving from the RAND spinoff System Development Corporation in Santa Monica, another direct connection from UT back to RAND, SAGE, and the Q-32, following on from earlier discussions of timesharing and interactive computing and networking and the ARPANET. 

While serving as the Head of the Language Processing Research Program at SDC, Simmons directed the Synthex and Protosynthex projects, which aimed to synthesize human language behavior, read texts, and generate English answers to natural language questions. This research relied heavily on Lisp, and SDC became a major hub for Lisp development, because navigating complex semantic networks required dynamic memory allocation and advanced list-processing capabilities. The physical hardware hosting this research, the AN/FSQ-32, was an artifact of the Cold War. Originally engineered as a prototype for the military's SAGE air defense system, its deployment was canceled, allowing ARPA to repurpose the machine at SDC as an open-ended laboratory for timesharing, networking, and symbolic processing. This unique environment produced groundbreaking Lisp tools. The Q-32 Lisp 1.5 port was pioneering because it discarded the traditional interpreter-first execution model. It compiled all user code directly into machine instructions prior to execution to maximize speed. SDC and its collaborators even attempted to build Lisp 2, an ambitious language designed to combine Lisp's list-processing capabilities with the structured, algebraic syntax of Algol. Ironically, the Q-32's hardware limitations, specifically its absolute ceiling of 48,000 words of core memory, proved fatal for the highly complex Lisp 2 system, which routinely exceeded the machine's capacity and led to the project's cancellation in 1967.

To understand exactly why Lisp 2 exhausted the Q-32's memory space, it helps to look at everything the development team was trying to pack into it. Beyond adding the Algol syntax, the system featured a complex meta-compiler, dynamic arrays, multiple data types, and a highly advanced, retargetable compiler designed to eventually port the language to machines like the IBM System 360 and DEC PDP-6. To force this massive environment into the Q-32's cramped core memory, developers had to engineer an intricate, application-level memory swapper. The system's execution pipeline became heavily bogged down in memory management tasks. If a required function wasn't in active core memory, the system had to page the compiled binary from an external storage file. When memory was fully occupied, the manager would initiate an immediate compaction cycle, shuffling the in-memory binary code to assemble contiguous free space. If compaction failed to yield enough room, the system would selectively excise non-essential routines or trigger a full garbage collection pass to reclaim list storage before it could finally load the new function.

This constant disk paging and memory shuffling introduced severe latency. The overhead choked the system's performance and severely degraded developer productivity, making it nearly impossible to rapidly iterate on the language's syntax translator and optimization routines. These technical roadblocks were compounded by rising costs and collaborative friction among the project's institutional partners SDC, MIT, and Stanford. When the project was ultimately canceled in 1967, the AI community abandoned Lisp 2 and migrated back to Lisp 1.5, finding a more suitable home on the PDP-6 and its descendant PDP-10 architectures. Interestingly, LISP creator John McCarthy later lamented the cancellation, noting that "much more money has since been spent to develop LISPs with fewer features". However, at the time, the developers could not have foreseen that the PDP-10 architecture, which had a much larger address space, would soon emerge to solve the very hardware limitations that doomed Lisp 2.

When Simmons moved to UT Austin in 1968 he was able to escape these specific hardware constraints and expand his work. To support his growing research group, UT bypassed the need for remote teletype connections back to SDC by implementing its own native version of Lisp 1.5 on the CDC 6600. This localized computing power democratized access to Lisp, enabling Simmons and a new generation of graduate students to run the large-scale symbolic experiments necessary to pursue his ultimate dream of enabling a "conversation with a book", where a computer system could read expository text, map the underlying knowledge into semantic networks, and generate natural language answers to users' questions.

The decision to build a native Lisp system at UT was driven by the sheer unreliability of remote computing in the late sixties. Relying on remote teletype connections back to SDC in Santa Monica meant dealing with manual dialing, fragile acoustic couplers, and unstable long-distance phone lines. Because Lisp's parenthetical syntax is highly sensitive, a single corrupted character from line noise would cause the parser to reject the input or trigger a runtime crash. To overcome this, the university utilized its CDC 6600 and 131,072 words of magnetic core storage to build a native Lisp implementation written directly in CDC COMPASS assembly language. This system, known as UT-LISP, introduced a radical and highly unique architectural innovation referred to as the three-pointer cons cell.

Because the CDC 6600 used a 60-bit word and an 18-bit address space, a traditional Lisp cell containing only a CAR and a CDR pointer, with 18 bits each, would leave 24 bits empty and wasted. UT-LISP's designers partitioned the 60-bit word into three distinct 18-bit fields. The usual CAR and CDR fields, and a special field CSR. To navigate these unique three-pointer cells, the system supported compositional accessors of extraordinary depth. Programmers could chain up to eight operations together, which the system's handler would dynamically parse and execute at runtime. To manage the memory constraints of the university's multi-user timesharing environment, Mabry Tyson also developed a specialized virtual memory system for UT-LISP that paged individual Lisp functions in and out of core memory dynamically.

This unique three-pointer architecture proved perfectly suited for Simmons' research into cognitive science and computational linguistics. His group focused on representing meaning through semantic networks, which map concepts as nodes and relationships, using labeled directed arcs. Conceptual triples with a subject, relationship, and object mapped naturally onto UT-LISP's three-part CAR, CDR, CSR pointer structures. Using this highly customized local environment, Simmons and his research group were able to bypass the physical memory bottlenecks that had previously killed ambitious projects like Lisp 2. Leveraging UT-LISP, they successfully migrated Protosynthex from the Q-32 to the CDC 6600 to parse English strings, and completely rewrote the Linguistic Research Center’s Fortran based METAL machine translation system into Lisp for real-time translation.

The UT CDC 6600.

Home of the CDC 6600. Beneath the terrace! The three windows at center-right face out of the old Comp Center. They are offices, then there is The Hall running north-south, then beyond it The Glass Wall enclosing the machine room.

[1] https://www.cs.utexas.edu/~novak/simmons.html 

Southwest Network and ARPANET

Much as it had done for timesharing and interactive real-time computing, the Q-32 in Santa Monica foreshadowed the 1977 dawning of the ARPANET and Internet at UT Austin and in Texas. The Q-32 was retired around 1970 and did not itself serve as a node in the operational ARPANET, but it played a critical role as a direct technical ancestor. In the sixties, computer timesharing and computer networking, packet switching in particular, evolved quickly as associated areas of research. Computing resources were scarce and expensive, and the overall motivation was to share the available resources among more users, with both timesharing and packet switching slicing the resources into increasingly granular pieces for better distribution both temporally and spatially. 

The Q-32 was used for early long-range networking experiments. In late 1963, researchers established a 300-mile link between the Q-32’s PDP-1 front-end in Santa Monica and a CDC 160A minicomputer at the Stanford Research Institute. This connection utilized two full-duplex telephone lines. The defining architectural feature of this experiment was the strict separation of control and data. One telephone line was dedicated to sending standard executive commands while the second line was dedicated to raw data. Because the data line bypassed the Q-32's executive command parser, the data routed directly to the active program. This setup allowed remote SRI users to interactively perform full-text searches on bibliographic databases stored on the Q-32's high-speed magnetic drums.

By 1969, the early experiments with the Q-32 had led onwards to UT Austin and the NSF establishing a large-scale regional network, the Southwest Region Educational Computer Network. Its goal was to provide computing power to smaller colleges and universities across Texas. This regional network was a socio-technical experiment funded largely by the NSF to mitigate the prohibitive upfront costs of mainframe computing. By leveraging a hub-and-spoke model, the southwest network provided the computational plumbing necessary for remote batch processing and timesharing, which in turn created a fertile environment for computer-based education to flourish. It functioned as the vital infrastructure, the hardware backbone and telecommunications architecture, that linked the central processing power and software of the UTCC to a distributed web of smaller colleges, junior colleges, and secondary schools. 

The southwest network was centered on the UTCC CDC 6600 and 6400. Schools such as Southwest Texas State in San Marcos, Rice in Houston, Trinity in San Antonio, Austin High and McCallum High, and various junior colleges connected to this central hub via remote terminals, usually teletypes. It expanded from nine initial institutions in 1969 to twenty-three in 1972, with UT Austin serving as the central host. It democratized access to high-level processing power for both administrative tasks and, more importantly, classroom instruction. While the network was a technical success and demonstrated that communication lines and terminals could be stabilized across a distributed institutional landscape, it reached a definitive structural limit. The project successfully navigated the connectivity bottleneck but failed to address the more elusive problem of pedagogical effectiveness. The network proved that data could be transported, but it lacked the content necessary to justify the technology’s presence in the classroom. This highlighted a critical gap. Technical availability did not equate to educational utility, necessitating a shift toward the production of high-quality instructional materials.

In 1965, ARPA funded a project proposed by Thomas Marill and overseen by Larry Roberts to link the Q-32 directly to the TX-2 computer at MIT's Lincoln Laboratory in Massachusetts. This experiment proved that two independent, geographically distant time-sharing operating systems could exchange digital data and invoke programs remotely. It also exposed severe flaws in the era's networking capabilities. These technical frustrations directly convinced Roberts, who would subsequently become the program manager and principal architect of the ARPANET, that building a robust, large-scale computer network would require abandoning circuit-switching in favor of packet-switching technology. 

Marill and Roberts devised what they called the "elementary approach". The primary goal was to bridge the gap between the two structurally incompatible operating systems, the TX-2's APEX and the Q-32's TSS, without having to modify or rewrite their complex core kernels. Under this protocol, the local user executed an application that intercepted terminal inputs, repackaged them, and directed them over the communications link so that the remote host monitor treated the connection exactly as if it were a local user terminal. A successful demonstration of this setup involved a researcher at the TX-2 in Massachusetts utilizing a program called the Algebraic Translator to automatically dial the Q-32 in California. The program bypassed standard human login prompts to gain administrative access, loaded a Lisp compiler on the Q-32, transmitted a complex Lisp program across the country, and had the Q-32 execute the calculations before returning the results to the local TX-2 console.

The experiment was a technical success but a practical headache, proving two major things. A user on the TX-2 in Massachusetts could log into the Q-32 in California and run a time-shared program. It showed that computers didn't just have to talk to human typists. They could talk directly to each other and share workloads. And it highlighted the fatal flaw of using standard telephone infrastructure for computing. Because the connection used circuit switching, with a dedicated analog line, it was unreliable and inefficient. Because human-computer interactions and data exchanges happen in short bursts, the line remained idle for most of the session, resulting in extremely low bandwidth utilization and proving that circuit-switched computer networks would be prohibitively expensive. Furthermore, the analog lines were highly susceptible to electrical noise and signal attenuation, which frequently caused data corruption through bit-flipping. Since the remote software did not have automated, system-level error detection and recovery, a single flipped bit meant the user’s local software had to abort the session, clear remote memory buffers, and retransmit the entire data block.

Bob Taylor, the director of ARPA's Information Processing Techniques Office and a UT Austin graduate [1], recruited Roberts from Lincoln Laboratory to become the program manager and principal architect of the ARPANET in Washington. Remembering the lessons of the 1965 Q-32 and TX-2 hookup, Roberts realized that instead of dedicated phone circuits, the new network had to use packet switching to handle the data efficiently. Some researchers advocated for the dual-line model used in the 1963 Q-32 and SRI experiment, arguing that separating command and data channels simplified hardware and eliminated processing overhead. Roberts argued that leasing dual transcontinental telephone lines was economically unsustainable for large-scale networks. He insisted that any viable network must use a single physical channel, with the operating system dynamically multiplexing and parsing commands and data. The 1965 experiment's severe telecommunications bottlenecks had decisively proven that scaling a wide-area network required abandoning circuit-switched telephone lines in favor of packet-switching technology. By breaking data into small, self-contained packets, the network could maximize line utilization and automatically handle error recovery through intermediate switches, rather than forcing the user's application program to handle all error checking.

Drawing on his experience connecting the TX-2 and Q-32, Roberts initially proposed at a 1967 meeting that all host mainframes connect directly to one another and manage their own network administration, terminal routing, and error checking. Mainframe operators, termed principal investigators in the ARPA context, fiercely opposed this plan. They were highly protective of their expensive mainframes and refused to sacrifice 10% to 15% of their limited computing power to handle network overhead. 

In response to this resistance, computer scientist Wesley Clark told Roberts, "You've got the network inside out," and proposed a decoupled architecture. Clark suggested installing a small, standardized minicomputer at each site to act as a universal interface. These minicomputers would all speak a uniform language and handle all the routing, packet buffering, and error-checking tasks, completely insulating the main host computers from the network overhead. Roberts adopted the idea and named the specialized communications processors Interface Message Processors or IMPs. By separating communication logic from application processing, the IMPs allowed structurally incompatible mainframes to easily join a unified wide-area network, successfully establishing the foundational architecture of the ARPANET and the modern Internet.

Thanks to Clive Dawson, it's now known how the first ARPANET IMP in Texas arrived at UT in 1977, and in some sense the Southwest Network began fusing into the ARPANET. The first IMP was initially installed alongside the HRC DEC-10. Because the standard TOPS-10 operating system did not yet support interfacing with the IMP, the DEC-10 did not become the first Internet computer in Texas. The many PDP-10s across the ARPANET from its earliest days in 1969 were running custom operating systems, and the HRC machine was kept factory stock. Instead, the first actual host to connect was a PDP-11/45 running a hacked version of UNIX, located across campus in the Daily Texan composing room. Accessible via dial-up modems by a small group of users, this machine became the UTEXAS host on the net and served as the UT's pioneering gateway.

Charles Warlick discussing the Southwest Network in 1973

Southwest Network operations in the UTCC machine room circa 1973

Computation Center subterracean heart of the Soutwest Network circa 1973

[1] Bob Taylor earned a masters in psychoacoustics from UT in 1959. Interestingly, acoustics research at UT during the forties and fifties was connected with Bolt Beranek and Newman in Boston, and BBN would become central to the ARPANET from 1969 onward when it won the contract to create and operate the IMPs. UT Austin and BBN frequently collaborated on major federal and commercial acoustics projects. Researchers at UT Austin have conducted sponsored research and acted as co-chief scientists on defense-oriented ocean acoustic initiatives via BBN and Raytheon. There are also quite likely ties with the Linguistics Research Center at UT from the forties and fifties. It's reasonable to say that Taylor arrived in his ARPA role because of Joseph Licklider, a psychoacoustice researcher, BBN employee, and ARPA appointee.

RAND and SAGE 1964

The introduction of timesharing on the UT Austin CDC 6600 in 1967, soon after its arrival in 1966, was a student-led initiative that fundamentally changed how the university's computers were used. Instead of originating from faculty or administration, the push for timesharing came from three graduate students, including Forest Baskett, who would eventually run day-to-day aspects of the UTCC systems programming staff. Frustrated by the CDC 6600's primitive batch operating system, the students proposed replacing it with a timesharing system that utilized online terminals. They took their idea to Jim Browne, an early computer science faculty member, who supported the project and got the Computation Center's approval. [1][2]

Baskett drew inspiration from a summer job in 1964 at the System Development Corporation. Spun off from RAND Santa Monica in 1956 to handle the unprecedented software demands of the SAGE project, SDC is widely considered the world's first independent computer software company. The SDC facility originally required an air-conditioning system powerful enough to cool 20,000 homes to offset the heat generated by its early vacuum-tube systems. In this environment, operators monitored radar scopes in dimly lit rooms, surrounded by massive walls of neon bulbs displaying the state of the machine's logic gates. This summer job was while Baskett was an undergrad at Rice University in Houston and already involved with interesting computer research. He was working for a chemistry professor, running simulations of the molecules in a gas and making movies of the results. They had a cathode ray tube with a 16-millimeter film camera attached to it. It could put dots on the screen, take a picture, clear the screen, and advance the film by one click. During this period in the early sixties, Baskett was fortunate enough to experience the SAGE system at SDC.

SAGE, initially designed in the fifties as a military command-and-control system for Soviet bomber defense, featured pioneering real-time processing and early timesharing capabilities. The machine Baskett interacted with specifically was the AN/FSQ-32, commonly referred to as the Q-32, a transistorized prototype that succeeded the massive, vacuum-tube-based machines originally built for the SAGE air-defense network. The Q-32 occupies a unique and somewhat ironic place in computing history. Its cancellation as a military asset is exactly what allowed it to become a pioneering testbed for modern interactive computing.

The Q-32 was originally commissioned by the Air Defense Command to solve the glaring vulnerability of the massive, above-ground AN/FSQ-7 SAGE blockhouses. It was designed to be installed in hardened, underground nuclear bunkers capable of withstanding 200 psi of blast overpressure, called Super Combat Centers. By 1960 the Department of Defense realized that the rapidly increasing yields of Soviet nuclear weapons and the shift toward Intercontinental Ballistic Missiles rendered even these underground bunkers vulnerable. As a result, the Super Combat Center program was cancelled, and the Q-32's military career was terminated before series production could begin, leaving the single completed prototype at the SDC headquarters in Santa Monica.

Because it was no longer needed for active air defense, the Advanced Research Projects Agency, under the guidance of Joseph Licklider, repurposed the Q-32 prototype to research multi-user interactive computing. SDC engineers built the Time-Sharing System for the machine, which achieved its fluid, conversational terminal interactions by utilizing a round-robin scheduling algorithm. The system rapidly swapped active user programs between the machine's 65,000-word core memory and high-speed magnetic drums, allowing it to support upwards of 30 simultaneous users via remote terminals routed through a PDP-1 interface. 

This was the specific architecture that allowed Baskett to sit at a terminal and interact with the machine. It demonstrated that a computer could be an immediate, conversational medium for mathematical exploration. Given the unstructured nature of his summer job, Baskett used the time to teach himself John McCarthy’s Lisp from a textbook and wrote a custom Lisp interpreter directly on the SAGE machine. This hands-on experience became his mental model for how computing should ideally operate when he later encountered the CDC 6600's restrictive, punch-card-based SCOPE batch system. The Q-32's influence extended far beyond Baskett's individual career. In October 1965, the Q-32 in Santa Monica was directly linked via a dedicated dial-up telephone line to the TX-2 computer at MIT's Lincoln Laboratory. This connection marked the first successful transcontinental exchange of data between two independent operating systems, successfully proving the viability of wide-area distributed computing and serving as a direct precursor to the ARPANET. [3]

Understanding this context highlights exactly why Baskett found UT's CDC 6600 so frustrating just a few years later. While the Q-32 at SDC was designed for real-time command, control, and multi-user interaction, the CDC 6600 was engineered purely for maximum scalar floating-point performance. The manufacturer-supplied SCOPE operating system was strictly batch-oriented to keep the central processor constantly fed with scientific simulations. When Baskett and his fellow graduate students proposed building a timesharing system, they were essentially attempting to graft the interactive, user-friendly philosophy he had experienced at SDC onto the raw, unyielding computational power of a machine designed solely to crunch numbers. The students' frustration with the SCOPE system was entirely justified. SCOPE was engineered purely for batch processing, completely isolating the user from the machine. To fix even a minor bug, researchers were forced to submit physical decks of punch cards to operators and wait hours for printed results. The system enforced counterintuitive, rigid rules, such as requiring users to define their maximum runtime in octal seconds, capping execution at exactly 77777 octal seconds, or about nine hours.

When Baskett and his two fellow graduate students approached Jim Browne with their radical idea, Browne's response was enthusiastically pragmatic: "Hmm, that could be fun. Let's try". Browne's backing was the critical catalyst for the project. He had to navigate the university's administrative hierarchy to convince the Computation Center to allow a small group of students to completely replace the core software of a $5.9 million supercomputer. In addition to his work in systems software, Browne served as a Principal Investigator for the Conduit project at UT Austin, working alongside Charles Warlick and George Culp to test, evaluate, and distribute computer-based curriculum materials across different universities. Ultimately, his early experiences supporting timesharing and multi-institutional resource sharing shaped his later career, and Browne went on to become a major proponent of national high-speed computer networks. [2]

Once Browne secured the Computation Center's approval, Baskett and his team ingeniously repurposed the CDC 6600's unique hardware to solve the software bottlenecks. By programming the mainframe's ten independent Peripheral Processors to handle the input/output operations of remote interactive terminals, they freed the central processor to execute user programs in rapid, multiplexed time slices. The trust that Jim Browne and the Computation Center placed in these students yielded extraordinary results. The initial system was up and running within a year and a half, and its subsequent revisions proved so stable that it remained in active production at the university for a remarkable ten years. Browne also went on to serve as Baskett's doctoral thesis advisor, supporting his groundbreaking mathematical proofs on system scheduling and queuing theory that emerged from the project.

The primary goal of the new UT system was to make the computer easier to use, more enjoyable, and highly productive for its target audience of faculty researchers and graduate students. Through data analysis of user habits, Baskett deliberately aimed to optimize the system to minimize customer complaints. The system initially used Teletype terminals and relied on the existing compilers supplied by CDC, ensuring the operating system maintained all the interfaces that users were already accustomed to. Baskett implemented a job-scheduling method using round-robin timeslicing, similar to the one he had experienced on the SDC Q-32, keeping the time slices as small as possible while remaining consistent with system overhead. 

Tasks were kept memory-resident and managed via the 6600's base and bounds registers, which provided memory protection on a per-job basis. Because the CDC 6600 completely lacked hardware paging, segmentation, or virtual memory mapping, user programs were forced to reside in contiguous physical blocks within the central memory. The base and bounds registers provided strict per-job memory protection so users couldn't maliciously or accidentally corrupt each other's data. To effectively multiplex dozens of users with round-robin timeslicing, the system had to swap these memory blocks rapidly. The team achieved this by leveraging Extended Core Storage. When a user's time slice expired, the TAURUS scheduler initiated an extremely fast block transfer, copying the user's entire contiguous address space into ECS and immediately swapping the next active user's program into central memory.

During this period, Baskett encountered Seymour Cray and asked the legendary architect to modify the 6600 hardware so that privileged instructions in user mode would cause an exception rather than a no-op. This was essentially a plea for hardware-level virtualization. Cray’s succinct refusal "No, I don’t think so" illustrated the persistent gap between architectural vision and hardware implementation that Baskett would spend his career bridging. As he assumed leadership of the twenty-five-person systems staff at the computation center, he balanced these practical infrastructure challenges with the theoretical rigor that would define his doctoral dissertation. Between 1971 and 1982, his career exemplified a unique industrial-academic synthesis, bridging the gap between national laboratories and corporate research. He led the Demos operating system for the Cray-1 at Los Alamos National Laboratory, which was notable for its use of software-based property tags, an early precursor to modern object-oriented systems. Simultaneously, he conducted VLSI research at Xerox PARC.

The initial timesharing service, known as RESPOND, was officially initiated on the 6600 in March 1967. It proved to be an astounding success, with the system and its subsequent revisions remaining in production for a decade. RESPOND was later replaced by a more advanced system called TAURUS (Texas Anthropocentric Ubiquitous Responsive User System), which operated as an integral part of the UT-2D dual operating system, managing both the CDC 6600 and 6400. Ultimately, the UT Austin students' project was highly influential in the broader computing industry. It demonstrated the viability of timesharing on the CDC 6600, prompting both Control Data Corporation and the Lawrence Livermore National Laboratory to realize the need for such systems and launch their own competing efforts.

SAGE terminal with interactive radar display and light pen.

SAGE terminal.

SAGE AN/FSQ-7 computer. The Q-32 in Santa Monica was a follow-on transistorized version.

[1] CHM Oral History Interview with Forest Baskett 

[2] Jim Browne 

[3] By June 1963 the Time-Sharing System Model Zero was demonstrated after magnetic drums were added to the time-sharing. Each user was given a priority-based time slice, measured in milliseconds, when the user's program was written from the magnetic drums into much higher speed memory, processed, and then written back to the magnetic drums with any computational changes that had occurred. It was influenced by early experiments at Bolt, Beranek, and Newman, and the CTSS project and Project MAC at MIT. Terminals included several Teletype Model 33 ASRs. In October 1965 Lincoln Labs' used a TX-2 solid-state computer tied to the Q-32 prototype for the first telecommunication of time packets. https://en.wikipedia.org/wiki/AN/FSQ-32#Time-sharing 

CDC 6600 Checkout Testing (Space Wars)

Where there were computers, there were computer games. Even the original CDC 6600 checkout engineers famously used the 6600's innovative CRT monitors for early games like Space Wars, Lunar Lander, and Baseball as a way to test the machine. Because it was among the first commercial computers to feature an interactive cathode-ray tube display console instead of just glowing lights and typewriter text, it became the perfect sandbox for early coders. CDC's checkout and maintenance engineers needed a fast, highly visual way to ensure that all parts of the multi-million dollar system, especially the graphics consoles and peripheral processors, were firing correctly under heavy stress. To do this, they programmed a suite of highly advanced, real-time diagnostic games. [1]

While Spacewar was originally coded on the MIT PDP-1 in 1962, the CDC 6600 Space Wars version took full advantage of the supercomputer's relatively immense processing speed. It featured two vector-graphics spaceships maneuvering in real-time, firing torpedoes at each other while being pulled by the gravity of a central star. Lunar Lander was an early, real-time precursor to the text-based and arcade lander games that would explode in popularity in the seventies. Players had to precisely calculate thrust and fuel consumption using the console controls to safely descend a spacecraft onto a jagged vector-graphics moon landscape without crashing. Baseball was a unique vector-graphic sports game. A pitcher would throw a pitch, and the batter would have to swing with strict timing to hit the ball out into a digitally rendered diamond. Some historical legal documents from Magnavox patent lawsuits in the seventies point to this exact CDC game as a precursor to early video arcade sports games.

CDC engineers openly admitted that the games became the primary incentive for getting the temperamental machines operational. If a newly assembled CDC 6600 could smoothly run Space Wars or Baseball without freezing or crashing, it meant the entire system architecture was completely sound. Because these games utilized the console screens long before commercial video games existed, they can be considered among the first computer games to use graphical displays.

Possibly a checkout engineer?

Baseball [2]

[1] Mention of the checkout testing games https://www.cisl.ucar.edu/ncar-supercomputing-history/cdc6600 

[2] Baseball photo 

[3] One reason that the following link is so interesting is that have met an original european CDC sales rep. He's a prominent art dealer, gallery owner, and respectable old gentleman of Frankfurt. Was there to meet family for their art opening in October 2024. His home was over the gallery, and during the dinner after the event, quite magically we had a conversation about CDC. Just one of those unforgettable things. CDC 6600 arrives at CERN in 1965 

CDC at UT Austin and IBM at Exxon Houston

There's a curious parallel between UT Austin's CDC hardware and Exxon Houston's IBM hardware during the sixties and seventies, bookended by a shared IBM era in the fifties and a shared Cray era in the eighties. CDC and Cray were members of a family of Minnesota companies (ERA, CDC, Cray) that, along with its UNIVAC relatives, was a vigorous competitor to IBM in the engineering, scientific, national lab, and cryptography fields. In a sense, UT Austin moved from IBM to the ERA tradition in the sixties, and Exxon Houston followed in the eighties. UT Austin's early move was due to David Young's being firmly in the ERA tradition from his work at Ramo-Wooldridge (TRW) in the fifties. He arrived at UT in 1958 and led the acquisition of the CDC 1604 in 1960 and CDC 6600 in 1966. The CDC Cyber hardware that UT acquired in the seventies was essentially updated versions of the CDC 6600, based on the same 60-bit architecture and running similar code.

There were multiple important connections between computing at UT Austin, Exxon, Rice, and Houston. A sign of these connections was the story of how, in 1958, Humble Oil in Houston (now Exxon) donated its IBM Card-Programmed Electronic Calculator to UT Austin. UT’s Al Matsen was a consultant for Exxon Houston and New Jersey for over thirty-five years. The CPC was a landmark gift and a direct result of Matsen’s extensive ties. To bypass bureaucratic paperwork, Matsen, his graduate students, and other faculty physically carried the heavy machine components into Welch and installed it themselves. Exxon had acquired the CPC in 1952 and used it to implement ground-breaking subsurface reservoir simulations and the beginnings of the ADI Alternating Direction Implicit techniques for Finite Difference Methods. This work put Exxon, Rice University, and Houston in a leading position for subsurface modeling and computational engineering and science.

ADI was forged in late 1953 out of urgent commercial necessity by Peaceman, Rachford, and Douglas. Driven by the pragmatic need to simulate oil reservoirs for high-stakes drilling decisions, they bypassed academic idealism in favor of industrial utility. Rather than chasing elegant theorems, they engineered ADI as a brilliant, gritty algorithmic hack, splitting complex multi-dimensional problems into a sequence of cheap, one-dimensional coordinate sweeps to circumvent both the memory bottlenecks of early hardware and the finicky tuning required by SOR. The alignment of Exxon with IBM, and David Young’s association with UNIVAC and Control Data Corporation, mirrors the structural, financial, and philosophical divides of the early computing era. [1]

The IBM CPC was not a computer in the modern sense. It was a hybrid electro-mechanical system. It consisted of an IBM 402 or 417 Accounting Machine (the printer/controller) connected to an IBM 604 Electronic Calculating Punch (the arithmetic unit) and an electromechanical storage unit. It functioned as a decentralized network of specialized units rather than a unified stored-program architecture and was fundamentally incapable of holding both the data and the instructions required for the Simplex Method. Consequently, the program existed not as a digital state within the machine, but as a physical sequence of punched cards. This required the operator to function as a manual control unit, physically re-entering card decks to execute the iterative loops essential for finding an optimal solution within a linear system. 

The development of the CPC itself actually originated from clandestine, user-driven engineering at Northrop Aircraft rather than inside IBM's own research labs. In late 1946, a specialized computing group at Northrop led by engineers Greg Toben, Bill Woodbury, and Rex Rice was tackling complex aerospace calculations, such as jet propulsion and guided missile trajectories, which vastly outstripped the capacity of standard accounting machines.

Because true stored-program computers were not yet available, the Northrop team decided to build their own hardware solver by merging two leased IBM machines: the new IBM 603 Electronic Multiplier, which was fast but lacked sequencing control, and the older IBM 405 Accounting Machine, which was slow at math but had excellent card-reading and printing capabilities. In direct violation of their IBM rental agreements, the Northrop engineers took the protective covers off the machines, exposed their internal wiring, and physically linked the two units together. They affectionately dubbed their makeshift, hybrid creation the poor man's ENIAC.

This prototype, which the engineers nicknamed Betsy, was remarkably powerful but suffered from physical instabilities. The multiplier section would occasionally freeze mid-operation, trapping card decks inside. To clear the jam, the operators often resorted to physical force. In one famous incident, an engineer was told to "Kick it, Gib", and his literal kick drove a heavy metal cover directly into a 60-ampere fuse block, causing a massive, hazardous shower of sparks. When Northrop's founder, Jack Northrop, reached out to IBM's CEO Thomas Watson to demand manufacturing support and standard parts for their modified system, IBM realized the commercial potential of the hybrid concept. IBM immediately flew Woodbury and his colleague George Fenn to New York to present their 603 and 405 combo. IBM's engineers then standardized the physical interfaces, replaced the 603 with the newer 604 calculating punch, and officially announced the commercial Card-Programmed Electronic Calculator in May 1949.

Even after the commercial release, Northrop continued to drive the CPC's evolution. Early users struggled because instruction cards had to point to highly specific, hardwired microprograms on a physical plugboard, making it almost impossible to share programs. To break this hardware bottleneck, Northrop's Rex Rice engineered a general-purpose control panel. By wiring a generalized set of logical pathways and math routing systems directly into the board, programmers could write various mathematical applications entirely on standard card decks without needing to manually rewire the plugboard for every new problem.

The CPC can even be traced a few years further back, to 1943 Los Alamos and the race to build the atomic bomb. All of the pieces that would become the CPC three years later were already being brought together at Los Alamos and even earlier at Columbia University, and it’s extremely likely that some of the Northrop researchers had been present at Los Alamos and possibly Columbia. Here's a description of the arrival at Los Alamos of the pieces of what soon would become known as the CPC, and Richard Feynman’s reaction.

Feynman, frustrated, turned to Nicholas Metropolis, a mustached Greek mathematician who later became an authority on computation and numerical methods, and said, “Let’s learn about these damned things and not have to send them to Burbank.” (Feynman grew a temporary mustache, too.) They spent hours taking apart new and old machines for comparative diagnosis; learned where the jams and slippages began; and hung out a shingle advertising, “Computers Repaired.” Bethe was not amused at this waste of his theoreticians’ time. He finally ordered a halt to the tinkering. Feynman complied, knowing that within weeks the shortage of machines would change Bethe’s mind. Escalation of the computation effort came in the fall of 1943 with an order to IBM for business machines to be delivered to an unknown location: three 601 multipliers, one 402 tabulator, one reproducer-summary punch, one verifier, one keypunch, one sorter, and one collator. Astronomers at Columbia had been experimenting with punch-card computing before the war. A multiplier, an appliance the size of a restaurant stove, could process calculations in large batches. Electrical probes found the holes in the cards, and operations could be configured by plugging groups of wires into a patchboard. Among the computation-minded at Los Alamos, the prospect of such machines caused excitement. Even before they arrived, one of the theorists, Stanley Frankel, set about devising improvements: for example, tripling the output by rearranging the plugs so that three sets of three- or four-digit numbers could be multiplied in a single pass. Having requisitioned the machines, the scientists now also requisitioned a maintenance man—an IBM employee who had been drafted into the army. They were gaining adroitness at military procurement. The crates arrived two days before the repairman; in those two days Feynman and his colleagues managed to get the machines unpacked and assembled, after a fashion, with the help of nothing but a set of wiring blueprints. [6] 

Exxon donated its IBM CPC to UT in 1958. The CDC Cyber was essentially an updated CDC 6600. By the eighties, both UT and Exxon were in the ERA tradition with Cray hardware.

Is this Seymour Cray during installation of the CDC 6600 in 1966? Genuine question, as it does seem at least possible.

Official event for the CDC 6600 in 1966. David Young is at the very top center, somewhat less visible because of lack of contrast against the background. Curiously, Al Matsen seems not to be present in this photo. Both Young and Matsen are variously described as founders and heads of the UT Computation Center.

[1] SOR Successive Over-Relaxation and the work of David Young at TRW were prominently applied to fluid and heat flows for atmospheric reentry vehicles. At the same time, ADI Alternate Direction Implicit was being applied to fluid and heat flows for the oil industry in Houston. This was all in the mid and late fifties, and among the most important early applications of computers in modeling and simulation, alongside Dantzig's work on Simplex at RAND.

[2] For more about Exxon Houston, A Personal Retrospection of Reservoir Simulation, Donald Peaceman 

[3] The photos above related to the CDC 6600 are thanks to the Briscoe Center 

[4] Here's an excellent new post about the IBM CPC from Ken Shirriff.

[5] Notes about the post 6600 CDC hardware in Austin. UTCC upgraded to systems like the Cyber 170/750 and 175, which maintained compatibility with the older 6000 series code but introduced crucial magnetic-core and semiconductor memory enhancements to support operational runs on much larger scales. The Cyber 170/750 was a critical high-performance resource managed by the UT Computation Center. While the university's primary, general-access academic mainframes such as the original CDC 6600 and early Cyber systems were famously housed in an underground facility beneath the East Mall on the main campus, the Cyber 170/750 was deployed differently. The university utilized facilities at the Balcones Research Center, now known as the Pickle Research Campus, to host high-performance systems like the Cyber 170/750. At this off-campus site, the 170/750 was dedicated to handling specialized research and mathematically intensive data analysis tasks. Researchers also utilized a CDC Cyber 175 during the late seventies and eighties. At the time, the Cyber 175 was one of Control Data Corporation’s top-tier, high-speed scalar processors, and it was used intensively for complex finite element and alternating-direction method simulations to solve the types of convection-diffusion problems that frequently appear in reservoir engineering and geology.

[6] James Gleick, Genius: The Life and Science of Richard Feynman (New York: Pantheon Books, 1992)

Welch Hall 1958, Benedict Hall 1960

Two threads in the story of early computing at UT Austin are of special interest because of their links with the subsurface and outer space. There’s Exxon Houston’s 1958 donation of an IBM CPC to the chemistry department in Welch Hall, representing the pragmatism of the oil industry and its ties with Al Matsen. And there’s the 1960 purchase of a CDC 1604 for the math department in Benedict Hall on the South Mall, representing the systems thinking of the aerospace industry and its ties with David Young. Both Matsen and Young are variously described as founders and first directors of the UT Computation Center from 1958 up through roughly 1970, and it seems likely that they collaborated in UTCC’s early days and blended together the influences of their respective industries and technical fields. A curious fact is that when the CDC 6600 arrived in its underground home in 1966, it was located roughly midway between Welch Hall to the north and Benedict Hall to the south. The 1966 Computation Center sub-terrace building and million dollar 6600 were a landmark for the end of the early days, symbolizing the onset of computing maturity, and how computers and software had grown larger than particular industries and departments.

One of the interesting aspects of this very early period is the clear differentiation between IBM and CDC hardware. There’s no question that at the time Exxon and the oil industry in Houston were using IBM hardware and that this heavily influenced the chemistry department at UT, which also ended up having two IBM machines. Meanwhile, David Young was associated with TRW Los Angeles, which was a UNIVAC shop. CDC was a spinoff from UNIVAC, and when Young arrived at UT, CDC hardware followed soon after. There was clearly an important contrast between the oil and aerospace industries at work here, and between the nature of IBM and CDC and their customers.

The chemistry department acquired an IBM 650 Magnetic Drum Data Processing Machine in 1955 using specific research grant funds secured by Al Matsen [1]. The 650 was almost certainly in Welch (always and for all time The Chemistry Building) and the first real computer on campus. Though note that there's evidence of IBM hardware up at DRL/ARL [4]. The 650 was a very early mass-produced computer, and at least somewhat comparable to the LGP-30 of The Story of Mel fame [2]. Matsen and colleagues used the 650 to compute the seminal Quantum Chemistry Integrals and Tables, which provided the computational foundation for molecular orbital calculations across the field. Although the machine was purchased for his own work, Matsen established a precedent of shared usage at the university by allowing faculty members and researchers from other academic disciplines to utilize the computer. In one legendary exchange, the university president complained to Matsen that the "computer center" did not have long enough open hours and help was not always available. Matsen informed the president that UT actually had no official computer center and was merely using his grant-funded machine, but emphasized that the university desperately needed to build a centralized facility.

A second transformative event occurred in 1958 when Humble Oil in Houston (now Exxon) donated an IBM Card-Programmed Electronic Calculator to the university. Matsen was a consultant for Exxon Houston and New Jersey for over thirty-five years. In his Reminiscences he relates a story “Amusingly, I had been lecturing at an unnamed university on the unitary group formulation of the many-body theory. I apparently went way over the listeners' heads since the only question I got was, What possible use could you be to Exxon?” The CPC was a landmark gift and a direct result of Matsen’s extensive ties. To bypass bureaucratic paperwork, Matsen, his graduate students, and other faculty physically carried the heavy machine components into Welch and installed it themselves.

The IBM CPC was not a computer in the modern sense, and in fact was a major step backwards from the IBM 650, but it was useful in the Welch Hall of 1958. The CPC will always be legendary as the machine that George Dantzig implemented the Simplex method on at RAND in 1952. It was a hybrid electro-mechanical system. It consisted of an IBM 402 or 417 Accounting Machine (the printer/controller) connected to an IBM 604 Electronic Calculating Punch (the arithmetic unit) and an electromechanical storage unit. It functioned as a decentralized network of specialized units rather than a unified stored-program architecture and was fundamentally incapable of holding both the data and the instructions required for Simplex. Consequently, the program existed not as a digital state within the machine, but as a physical sequence of punched cards. This required the operator to function as a manual control unit, physically re-entering card decks to execute the iterative loops essential for finding an optimal solution within a linear system. 

IBM CPC Card-Programmed Electronic Calculator 1949 

In 1958 David Young moved to UT from TRW and the Los Angeles aerospace environment. He was tasked with founding the Computation Center and serving as its first director. When Young arrived, the Computation Center was "almost non-existent," consisting of Young, his colleague Robert Gregory, and a secretary sharing a single office next to the IBM 650. Within 18 months, Young leveraged his formidable reputation to secure a $400,000 NSF grant for the CDC 1604, and in 1966, he secured the first $1,000,000 NSF grant towards the purchase of the CDC 6600 supercomputer. Emphasizing that this was a personal triumph for Young rather than a political favor, Gregory stated: "I could not have done this, you could not have done this, but David Young did it." [3]

I joined David at UT six months after he arrived there in Fall 1958. At that time the Computation Center was almost non-existent. They had acquired an IBM 650 and David, I, and a secretary shared a single office next to the computer room. Within 18 months David, on the basis of his reputation alone, got the first $400,000 grant from NSF towards the purchase of a CDC 1604, the first transistorized computer. It beat the IBM 7090 into production by one month. Thus, UT went from nothing to a first class Computation Center in one big jump. Then in 1966, after acquiring a building to house the CDC 1604, and after it became saturated with users, David (again on his reputation alone) got the first $1,000,000 grant from NSF towards the purchase of a CDC 6600. This, again, put UT at the front of the line as far as University Computing Centers go. UT was the first university to have a 6600 and this put them ahead of Berkeley, Stanford, MIT, Harvard and all the rest.

Benedict Hall, the old home of the math department and probably of the Numerical Computation Center and the CDC 1604 in 1960. Pearce Hall (the old Law building, replaced by GSB around 1975) was to its east, which may help explain why it had a remote job entry point in the early seventies. 

A nice view of Welch for those of us who spent years working in ESB and saw the same daily.

[1] https://utphysicshistory.net/FrederickAMatsen.html 

[2] The Royal McBee Librascope LGP-30 and the IBM 650 represent two contrasting architectural philosophies in early 1950s computing, both leveraging magnetic-drum memory but targeting distinct operational paradigms. The IBM 650 emerged as the world’s first mass-produced mainframe, utilizing a power-intensive architecture of roughly 2,000 vacuum tubes and employing a unique "one-plus-one" addressing scheme to optimize instruction timing on a high-speed drum. In stark contrast, the LGP-30 pioneered the concept of the desk-sized minicomputer by prioritizing hardware minimalism; it utilized only 113 vacuum tubes, required no specialized cooling, and relied on low-cost paper tape input. While the IBM 650 dominated high-throughput corporate and institutional markets through punched-card workflows and faster drum rotation speeds, the LGP-30 democratized decentralized scientific computing by offering an affordable, single-user system that could operate seamlessly within a standard office environment. The IBM 650 was the world's first mass-produced computer and a massive financial success, renting or selling for upwards of $100,000+. The LGP-30 was aimed at a cheaper, scientific market segment, retailing around $40,000.

[3] Robert Todd Gregory, testimonial letter, August 24, 1982, quoted in David R. Kincaid, Legacy of a Giant: The Career of David M. Young (Austin: Archives of American Mathematics, Center for American History, The University of Texas at Austin).

[4] After the end of hostilities, the name was changed to Military Physics Research Laboratory and the group moved to the site of the Wartime Magnesium Plant. later to be named the Off-Campus Research Center, a little later the Balcones Research Center (a name suggested by Jim Han. the first Chancellor of UT), and more recently the J. J. Pickle Research Campus. MPRL continued to work with the Texas Tester and exterior ballistics for some years. It was the first group in Austin to use large mainframe IBM computers. ln time, the program decreased in size and in 1964, at their request, they merged with DRL. https://utphysicshistory.net/ARLOriginsMcKinney.html 

Dave Matuszek Oral History Interview

Oral History Interview 
Dave Matuszek

Noah Smith Interviewer
February 15 and 16, 2026

Noah: We're talking with Dave Matuszek, co-creator with Paul Reynolds of the 1974 Fortran Star Trek game on the CDC 6600, and we're going to learn about your experiences and your history in 1973 and 1974. So we'll start off with background. So tell me a little bit about yourself. 1973, 1974, how did you end up at UT?

Dave: Okay. I did my undergraduate work at Michigan State University. At that time there basically was no such thing as a computer science program. Nonetheless, a lot of people were interested in computers, and my wife and I took courses where we could find them, like from sociology and psychology and mathematics, and I just got hooked. It was a lot of fun. After I graduated, I wanted to do something more serious with my life, so I went into psychology. And after a year of that, and just deciding it wasn't for me, the ACM at that time posted a little pamphlet of all the computer science degrees in this country and Canada. And we looked them over. I selected five of them and applied. Decided to end up going out to the University of Texas. University of Wisconsin was a strong contender at that point. But that was at the point where people were talking about possibly blowing up the computer there. And in fact, after we moved to Texas, they did try to do that. So I ended up at Texas as a teaching assistant. I really love teaching. I really love programming. And we got into this Star Trek program.

Noah: Well, we'll spend a lot of time on that. We're going to get into that, but let's get a little bit more background. Where did you actually grow up? Were you from Michigan? Dave: Yeah, I was born and grew up in Michigan. Noah: Okay, so moving to Texas was a big move. Dave: Yes. My wife and I kept looking at each other and saying, "Texas?". Okay, but it turns out Austin is a pretty nice cosmopolitan city.

Noah: Agreed, agreed. What was your official role? So you said teaching assistant in what? Dave: In computer science. Noah: In computer science, okay. So you came in as a computer science graduate student, is that right? Dave: Pardon? Noah: You were a graduate student. Dave: Yes, in computer science. Noah: Okay. And did you have any direct affiliation with the computation center? Dave: I'd have to say no.

Noah: Where was the computer science department at the time, 1973, 1974? Do you happen to remember what building it was located in or where on campus it was? Dave: I can't bring the name of the building to mind right away. It was right next to the speech building. Noah: Okay. I mean, I'm thinking it might have been Taylor Hall. Dave: Yes. Noah: Okay, yeah, we know roughly what part of campus. So there was Taylor Hall, and this wasn't far from the actual computation center, right?

Dave: Correct. Noah: Can you maybe just describe a little bit what the computation center was like, the actual building, if you can call it that? Dave: Basically, I can't. Okay, what I can tell you is that there was a building quite a ways across campus called Pearce Hall, which is where we typed up our card decks and submitted them, and they were entered into the system and run there. That was physically separate from the computation center. Okay, and then of course after a couple of years we aren't using card decks anymore. Noah: We'll definitely check in on that, like how you physically were interacting with the machine. Let's get a little bit more background before we dive into it though. So, what was your life like outside of UT when you were in Austin? What part of town were you living in in Austin?

Dave:  Well, let's see. At first, we were living in someone's rented basement. And let's see, after a while, we got into married student housing. Noah: Okay, was this down by the river, by the lake? Dave: Yes, it was. Noah: Yeah, that's still married student housing today, so I know exactly what you mean. Dave:  And it was what, Colorado Apartments, I think? Noah: Uh-huh, something like that, right. It's still there. What would you say Austin was like for you? And were you a Star Trek fan, by the way?

Dave: Less so than a lot of people. I'm a science fiction fan and Star Trek was sort of science fiction, and yes, I enjoyed it. Noah: But not a hardcore Trekkie. Dave: Not a hardcore Trekkie, that's right. Noah: Did you appreciate any other things about Austin like the music or anything special that you remember about Austin at the time? Dave: We were never really into music. My wife was also in a graduate program there. We spent most of our time eating at some of the nearby restaurants. After a few years, we started having children and found a very nice Mexican babysitter for them. Once we had children, spent quite a bit of time going to the nearby library and getting out books. I was there for quite a long time. I was actually in the graduate program for 10 years. And the reason for that was we were getting by okay with the money that we were making, and they kept coming up with new courses, and there was always something new and interesting, and you know of course doing the final dissertation is work. But I eventually got around to it.

Noah: So you were there until the early 80s basically in Austin. Dave: Yeah, not good at dates, but that's about right. Noah: It's about right. So let's go ahead and dive in to actually dealing with the machine and then we'll get into Star Trek. Let's explore a little bit what working with the machine was like. Describe the physical situation. So you say Pearce Hall you were submitting card decks. How did that work?

Dave: Well, in Pearce Hall, they had the card punch machines, and you would write up your program, go to a card punch machine, punch it out into cards, put it into a tray, and they would take the tray, and sometime, probably the next day, you'd come back and get a printed result. Now obviously that was not an interactive system, and after a couple of years, don't ask me how many, we had terminals and we could interact directly with the 6600 rather than this baroque and Stone Age way of doing things. The 6600, although being quite powerful, is really still pretty small, and all of my material was stored on a magnetic tape. The magnetic tape was kept in the center, and when I started a session, I would log in and request the tape and then they would mount that and I'd have my programs and things available.

Noah: So the 6600, yeah, my picture is that it was actually in the computation center which is next to the main building. This kind of subterranean bunker style building and you could walk down into the hallway and behind the glass you could see the machine, right? Dave: Correct. Noah: Was your tape stored there inside the machine room? Okay. And you would be in a different building and you would have to request your tape to be mounted, is that exactly right? How long did that take usually for that to happen?

Dave: A minute or two. Noah: Really? That's nice. Dave: And so you see, although the computation center was right there, there was hardly any reason for me ever to visit it. Noah: Right. Because all you could do would be peer through the glass windows and look at the machine like everybody else. What we can say is because it's in this kind of basement underground bunker, there wasn't a lot of space. There certainly wasn't room for terminal rooms down there. There was just the machine room and maybe some offices, right?

Dave: There was a machine room, as to offices possibly. But you know, as I say, why would I ever go there? Noah: Yeah, there wasn't much space down there. So the machine rooms were in other buildings and people should picture that the users were in other buildings. Let's jump ahead just a little bit to talk about Star Trek. When you were working on Star Trek, did you have a terminal already?

Dave: Yes. Noah: Okay, that's key. Dave: It was interactive. 80 characters, 24 lines, I think. Green screen. Noah: The name Pearce Hall sounds kind of familiar to me. Can you orient me a little bit, like where it was on campus? Was it near the main building? Dave: Okay, there is a, and I think it's still there, a major business building. Sort of on the south end, southwest corner. And it was a bit north of that.

Noah: Okay. Dave: From the westmost corner. And I don't know how long it's been gone, but I'm sure it's been gone for quite a while. Noah: Yep, could be. The name sounds familiar to me, but not. So the terminal room, it was shared with other departments? Was it purely a computer science terminal room or was it shared? Dave: It was shared. If you want a bit of history, it was on the main floor occupying I think pretty much the main floor, although I don't recall. Down below in the basement was anthropology. And it was full of skeletons and things. And there was one office right at the back where if you go down and go through the anthropology room, there's an office. And that was my office for a while.

Noah: Nice. Dave: And I did not get many visitors. Noah: But you were right next to the terminal room, which is nice. It was on the floor above you, right? Dave: Yep. Noah: Was there any possibility of having a terminal in your office? Dave: No, we're still talking about the first year or two. Noah: Actually we skipped over, I missed. How did you meet Paul Reynolds? Dave: He and I were both new. I think he came in the year after I did. In fact, I think, I can't swear to this, but I think he took the Fortran course that I was teaching.

Noah: Okay. Dave: And we got together, did a little bit of programming together, became friends. Noah: So he actually might have been in your class. He was learning Fortran. Did you work together in the terminal room? Did you do coding sessions together? Dave: Okay, now, going back to the terminal room. Again, that was with the punch cards the first year or two. And that was you walk in, you use a machine, you hand in your cards, you walk out again. Except for a period when instead of having an office downstairs, I had an office in what was basically a broom closet in the terminal room, which was a very fascinating place because people thought I was a consultant and they would come to me with all sorts of problems.

Noah: Oh, that's funny. And you were trying to work though. This was your office, and hey I'm willing to help. Dave: I don't care if I don't know the language. You make the same kind of mistakes in every language. Noah: This is curious. Obviously people were using Fortran. Were there people using COBOL? Maybe business students were there as well using COBOL? Dave: Oh God. Okay, here's the truth. COBOL was invented for an IBM 605. Its layout was designed to work perfectly with that machine. That machine was a character-oriented computer where the arithmetic was, you specified how many digits you wanted in each number, and it did the arithmetic from the end like a human would and had a multiplication table stored. 6600 had 60-bit words. It didn't have characters. So fitting COBOL onto that machine was sort of putting a motor on top of a camel or something. And I recall this very well because at one point I got stuck teaching a one-credit course in COBOL, and many is the time I would go in and say to the students, "I tried to prepare for this lecture, but I just couldn't. It's so terrible.".

Noah: Understood, understood. How did you feel about Fortran? Dave: It's what I learned. It was my first language. Fortran II, actually. What we were using on the 6600 was Fortran IV. And I think it was locally developed, their version of it. So let me point out that back in those days, you can't assume that Fortran on one machine was anything like Fortran on another. Noah: Okay, understood. Dave: So we wrote in 6600 Fortran and that was it.

Noah: So, let's start looking at what happened with the Star Trek game. First of all, it sounds like you were quite busy with graduate studies. You were spending a lot of time in the terminal room. Were you aware of games on the CDC? Dave: There was a Space War-type game that the people in the computation center played, but the first and I guess maybe the only game that I was aware of that was terminal-based was Star Trek. And I should recall who wrote that, but I don't.

Noah: And we have a few names. I don't have them at hand right now, but Jim Corp and Brady Hicks. So, the notes we have are that they implemented Star Trek in BASIC on the 6600. Dave: Okay, it was in BASIC, it was on the 6600. Noah: Did you play that game? Dave: A few times, which is why I decided to write it. Okay, there were two basic problems. One is that this is still on a terminal. You're getting text across character by character and it's fairly slow, and it was full of quotes from Marcus Aurelius, who has to be the most boring philosopher that was ever born. And you know you'd be playing and then you'd sit there and twiddle your thumbs for a while while you got some stupid quote. So there were a number of other minor irritants. The computation center really hated it because this is a 6600. Now this is a supercomputer. The BASIC program took 20 seconds to load. And that's an incredible amount of time. And that's not the fault of the programmers, that's the fault of BASIC, but we decided to write our own version in Fortran minus quotes from Marcus Aurelius. And although the official position of the computation center was no games, this is for work, this is for study, you don't play games on it, they loved our Star Trek. First of all, there were a lot of Star Trek nerds. And secondly, instead of taking 20 seconds, it took 1/20th of a second to load. So the pressure on the machine practically vanished with that game.

Noah: Understood. So the 6600 was running in a time-sharing mode. So there were multiple users. So I wanted to ask you about how the computation center felt about games and I think you've made clear that they weren't too happy with it at first. I wanted to ask you, you mentioned that this computation center had a Space War-type game. Dave: I believe so. If you look into the history, as I'm sure you have, there are a number of games floating around at that point that you had to be at the computer in order to play. And it was my impression that they did do that. But of course, nobody told us.

Noah: Over your career, did you ever see the original Space War on a PDP-1? Dave: No, I have not. Noah: Okay. I think that this was a lucky small group of people that actually saw it on a PDP-1 because there just weren't that many PDP-1s. Dave: Right. For a while I used a PDP-8, but that's another story entirely. Noah: So, is there anything else about what we've discussed so far today? Is there anything else that you would like to say about all of that?

Dave: Yeah, let me mention one thing. The game got quite popular among students there at Texas, of course, and because Paul and I had written it, they assumed I was good at playing it. The fact was that I hardly ever finished a game because whenever I started playing, I'd find something that needed polishing or something that could be added. And I had more fun programming it than playing it. Noah: Understood. So I get the impression that you weren't playing a lot of games. In any case, it was more of a programming challenge.

Dave: Yes, that's correct. And in fact, I still don't play many games. Noah: Understood. Can we get a little more information about Paul Reynolds? So, were you working together? When you were working on the game, would you code together or was it more you shared your work but asynchronous? Dave: Well, I actually wrote most of the game. Paul Reynolds and another person, Rich Cohen, spent a lot of time talking about it and planning what to do. Paul's main contribution was writing the photon torpedoes code. At one point, I decided I didn't like that code and tried to rewrite it myself and discovered what a great job Paul had done with it.

Noah: So, was there anyone else there that were hands on with the code? Or it was mostly you? Dave: Just Paul and myself. Noah: Okay. You said that it became quite popular. Did you have any idea that it would have a history and be talked about 40 years later? Dave: No. So, if I had to choose one thing that I'd be famous for, I'm not sure this would be it. But on the other hand, I can't think of anything else I might ever be famous for.

Noah: So on this topic, Eric Raymond, his website and Git repo kind of records the history of the Star Trek games, and you know we learned a lot about you from that. When you interacted with Eric, did you have any idea that what he was doing would grow into kind of an archive of a type? Dave: Oh, yeah. I met Eric at a science fiction convention in Philadelphia. We were both science fiction fans. Became friends, discovered he lived about a mile from me. And so we were friends for many years. We sort of still are. When I say sort of still, we don't talk politics. He's a libertarian and I'm very much a liberal. Noah: Understood. And Eric has strong opinions. Dave: He does have strong opinions. He's somewhat controversial. My editor asked me not to use a quote from him in my data structures book, which I can respect. But you know, he can still be an interesting person and a great programmer and all that stuff even if his politics are not anything I would want to touch with a 10-foot pole.

Noah: Understood. Dave: We used to be a lot closer, but things changed. Noah: What years was this that you were living nearby? Dave: 80s or 90s. We moved here in '85. We probably met him somewhere around '90. I don't know. Paula, when did we first meet Eric? Yeah, my wife says 1990s. 

Noah: All right. So we're going to start with talking about the 6600 and any other machines, any other platforms that you'd like to discuss, right? So, we don't have to stick just to the 6600. So I'm really curious, you were there for around 10 years whether you saw any kind of change over that period. So if you remember anything, maybe you noticed the CDC Cyber come in. I'm quite interested in the history of the Cyber that kind of replaced the 6600, and then we'll go from there into the Fortran, into the game. So let's just start with tell me a little bit about the 6600. How do you feel about it?

Dave: It was a great machine. It was of course a supercomputer in its time. As for changes as I mentioned, started with punched cards and by the time I left we were playing Star Trek online and doing most of our editing online. Let me tell you just a little about the editing process because it wasn't like today when you pull up everything you've got and start editing it. What we did for Star Trek was print the whole thing out every week or two, go through and mark our changes on the printout, and then go to the computer and enter them.

Noah: Would you say that it was kind of pre-screen editor? Dave: Oh, yes. Well, okay, as I remember, now bear in mind that this was a long time ago, I don't remember exactly how the editing process worked, but I know that, yes, we did do it on a relatively limited terminal, 80 characters by 24 lines as I recall. Maybe it wasn't 80 characters. Noah: I'm thinking of some of the early editors I'm familiar with like TECO on the DEC system. So, these were I think they were even called character editors rather than screen editors. You know, this started with editing on paper tape even, right? Dave: Do I remember what editor I used? Absolutely not. Noah: I'm just trying to picture, you know, you would be looking at your printout. Would you maybe enter the line number like I want to edit line number something? Dave: I don't remember line numbers. And as I say, I don't remember exactly how we did the editing on a limited text-only terminal.

Noah: But you, I guess the printout was important. This is a good hint, right, the printout was important. Dave: Oh, yes. That was by far the easiest way to look at the code. Noah: What was your workflow like? You say you print it out once a week roughly speaking and then? Dave: Well I'm a bit amused by calling it workflow. My work was my courses. But whenever I thought of a change I wanted to make or an addition I wanted to make, I would figure out where in the code it went, write it out, and then go type it in. And then, as I recall, I could try it right away. Noah: Okay. I mean you had to compile it and run it but that wasn't a long process at that point. How about a debugger? Was it kind of just run it and see what happens? Dave: Yeah. And I'd go out and club a cave bear and bring it home for dinner. Noah: Right. Dave: Yeah, things have changed a great deal believe me. We're talking what, 55 years ago something like that. Yeah, and this is not a field that has ever stood still.

Noah: Understood. So, it's interesting that you mention that the 6600 was a supercomputer. And you know, it's common to see this that it was the first commercial supercomputer. So did you remember hearing that back at the time? Dave: Oh, yes. I mean, nobody today would call it a supercomputer. Noah: Did you know or have much context on the company? So CDC, this is I guess Minneapolis right? So kind of up north?

Dave: I think so. Noah: Did you know the name Seymour Cray for instance, and that he was involved with the design? Dave: Oh yes. As far as I know, he did the complete design of that and the follow-up machine. I never used it. I don't remember what the next machine was that he designed. I remember one of his comments was that he was done messing around with small computers and was going to build something impressive. I remember pictures of it that showed basically a pillar with what looked like seats all the way around it. So probably tonight in bed I'll remember what that computer was called.

Noah: This is interesting. It might just be the Cray-1. My picture is that UT had kind of all three generations from the 6600. So the next CDC machine, big machine was the Cyber, which was a transistorized version or brought in integrated circuits. That's the second generation and then the Cray-1. And eventually all three generations were there in Austin.

Dave: My undergraduate work was at Michigan State University. They had a Control Data 3600. I spent some time at Indiana University and I think at that point they had a 6600 fairly sure. And then I went to Texas and they had a 6600. By the time the Cray-1 came out, certainly by the time Texas got one, I had been gone from there. But it probably came out well before I left. Noah: So it sounds like you had a lot of experience actually with CDC hardware and CDC Fortran.

Dave: And very little with IBM. Noah: Okay, understood. So yesterday you mentioned that the 6600 was a 60-bit machine. So tell us a little bit about what you think about when you think of 60 bits rather than say 36 bits or 32 bits. Dave: Sure. Two things come immediately to mind actually. One is that there were six bits allowed per character which meant that we didn't have lower case. The second one was that it had 24 registers in groups of three: the index registers, the accumulators, and the third group. And when you got into the assembly language programming for efficiency, you had to keep track of what was in each register. So you didn't have to go up to memory any more often than you had to. And doing some very careful, very efficient programming on that is what decided me that I was done with writing in assembly language.

Noah: Okay understood. Did you do any let's say major projects in assembly? Dave: I did some projects in assembly because I definitely remember struggling with trying to use those registers as efficiently as possible. But I don't remember what it was and I wouldn't call it major in any case. Noah: Okay. So the picture I have is that the 6600 and the 60-bit words were really for floating point and you essentially get the effect of double precision on most machines, but it was single precision on the 6600 because it had the 60 bits. So you got effectively a double precision effect at single precision speed. So this was big for engineers that were doing early numerical simulations, right?

Dave: Yes, I don't recall any distinction between single and double precision. Noah: So what I wonder is, were you aware of any of these power users that were doing numerical simulations on the 60? Were there people that would hog the machine with these big simulations? Dave: I'm sure people were getting into that. It was time shared and there were not any periods where we as students couldn't use it. So nobody hogged the machine to death.

Noah: Okay, in that sense. The reason I ask is I've got some documentation that describes that there were actually two machines. This is the picture that I'm learning about that there was the 6600 and there was a 6400 and they called it the dual dinosaur. So there were two, they had shared memory and the 6400 was handling the time sharing and the 6600 was for the heavy batch oriented big jobs. I was curious if you saw any signs of that. It might have been a different period that this was happening.

Dave: I vaguely recall hearing about something like that, but I don't think that was at UT at the time. Noah: Okay. And this might be later. What I see often is they call it UT2D for the UT dual dinosaur and this suggests these two CPUs with the shared memory. Dave: Well, it's a cute name, but I'm pretty sure that I didn't deal anything with directly with that. It could have come in later. Noah: And there's also a lot of documentation about how the UT system was using kind of a custom operating system. So there was evidently a standard CDC setup and then some oddball sites and UT was one of those oddball sites.

Dave: True. Noah: Something about the character handling. There was something about the line terminations. Does this sound familiar at all? Dave: I think you understand when I say that I don't recall and I doubt that I knew at the time what was being used as a line terminator. And because at no point were we doing any character searches or anything like that. It was just writing code. Every line of code was on a separate line and that's pretty much all we knew.

Noah: What I've seen signs of in documentation is that these kind of odd sites, they had a hard time sharing software and code with the normal CDC sites. It's like code had to be rewritten a bit. Dave: Yes, the word I was trying to think of was standardization. That was in the future.

Noah: That's right. For the languages, for the operating systems, for everything. So you know, I thought about this earlier that let's imagine that we actually recovered your Fortran code. We do have a 6600 simulator, the SIMH type simulator. What I wonder is because your code was on a UT machine would this be a challenge? And I have no idea. It's just something to explore.

Dave: Okay I'm guessing here. The operating system I know UT pretty much did their own. The language I don't think they messed with particularly, the Fortran language. Noah: I think that's the hope that because it's in Fortran, and as you said yesterday Fortran was not standardized but for the 6600 we could hope that it would be a bit standard, so I think we would have hope that it would run. Dave: Yeah. I'd probably give you at least 60 40 odds on that.

Noah: Yeah, understood. That's about what I would guess too. So, before we leave the hardware and move into the Fortran, what would you say was the best part and the most painful part with the 6600? Just to sum it up for people, what did you love the most and what did you find kind of the hardest with the 6600? Dave: Well 6600 was what there was. I mean what am I supposed to compare it to? I very much enjoyed programming on it. There were quite a few workarounds to use characters on it since it was designed as an engineering machine, but it was what we programmed in.

Noah: How many years do you think of 6600 programming did you get? Close to 10 years? Dave: Oh, I'd say so. I've really been into programming languages and although Fortran was my first language, Fortran for the 3600 was different from for the 6600. I've gotten into a lot of other languages and I can't say how much toward the end of that I was actually using Fortran anymore. I think I probably was because I think all the introductory courses were still being taught in Fortran. And that means the upper level courses that I was teaching at that time would also assume Fortran.

Noah: That's important. So this was kind of the academic language in that environment right? Dave: Yep. Noah: So, let's move into the game itself. I think you did an excellent job of describing how you and Paul Reynolds kind of decided to redo this game that was written in BASIC. How long did you spend creating the Fortran version? Dave: I have no idea. I'm guessing probably a month or two to get the initial version running and then probably a few more years of tinkering with it.

Noah: Did you start from the BASIC code of the previous version or just start? Dave: Oh, no. God, that would mean I'd have to look at the BASIC code. And are you familiar with BASIC at all? Noah: A little bit. Dave: Okay. Let me briefly just point out that it depends on line numbers. All the lines are numbered, they have to be in numerical order, and you refer to other parts of the program by line number. So in terms of high level concepts, no. I played the game and I played the game enough to know how it went. I think I changed 8x8 sectors into 10x10 sectors. Nothing fundamental.

Noah: That was all recreating it from what you knew it was supposed to do. When you first saw the Star Trek game, even the BASIC Star Trek game, do you remember seeing this ASCII artifact of when you did the scan and you see a sector grid? Do you remember seeing this ASCII artifact and did that impress you at the time? Dave: I don't think I know what you're talking about. I mean, there was certainly ASCII art, like Snoopy calendars and things like that, but I don't remember seeing any artwork in the game itself.

Noah: Okay. So, I'm not sure that the early Star Trek games did this, but what I'm thinking of is when you typed scan, it would show you a map. That's what I mean by art is this map. Dave: Oh, okay. Noah: Short range scan. Long range scan. The first Star Trek that you saw already had that. And do you think that intrigued you that seeing this kind of map was?

Dave: Well frankly my basic impression of that is that it was useful and it was nice to have the range, nice to be able to type out the map when you needed it. But this was at 33 baud, which is like 10 characters a second or something like that. And so I mean, you'd ask for a long range and go make a new cup of coffee. Noah: Understood. How big do you think the code base was? Was it a large code base that you were working on? Dave: Oh, I'm guessing about 30 or 40 pages. Noah: I would say that's pretty big. Dave: We weren't counting bytes, we were counting printed pages. Noah: I would say that's pretty complex and sophisticated in some way. Do you think that the game was a bit sophisticated for its time?

Dave: No. I mean there was already the BASIC version of it and there were a few other games that I was vaguely aware of. I mean, you could play things like Hangman or Nim. Noah: So let's ask this. What part of the implementation was kind of the most fun or interesting for you and what were you proudest of in some way? Dave: Oh, I most enjoyed, I think that would be The Thing. It occurred to me one night when I went in and added to the code and set it up so that when you saved the game, it wasn't saved. So you would see The Thing appearing maybe once every 20 or 25 games. And you either dealt with it then or it was gone. Do you know what I mean by The Thing?

Noah: I'm guessing some kind of space monster? Dave: Yep. It appeared as a question mark. And Spock would say, "Fascinating.". And about the only thing you could do with it was shoot it with a photon torpedo in which case it screamed and disappeared. Noah: So was there a Romulan ship in those early Star Treks? Dave: No, I'm afraid that what happened was that, as I say, we listed out our code and used it for a while and threw it away and then apparently someone stole our code from the garbage can. Now, we did not have Romulans or dilithium crystals in it. But someone stole our code, created Super Star Trek, and added it. And that was annoying, of course, but if they had simply come to us and said, "Hey, can we get involved in this?" I'm sure we would have.

Noah: Well, Dave, this is fascinating. I did not know this twist to the history that someone got your code and separately created Super Star Trek. Dave: Correct. Noah: So, you know what happened then was within two years there was the two-player Star Trek on the 6600. Dave: I'm not aware of that. I wasn't paying a lot of attention. I mean, it wasn't my game anymore. Noah: So, then within four years there was this later 18-player game and in it the Romulans appeared as question marks. So, kind of like The Thing.

Dave: Now, I know nothing about that. Noah: Yeah, so in the 18-player game this AI controlled enemy, the Romulan ship, comes in and it appears as a question mark and it acts somewhat like you described The Thing. So what I'm thinking is you might have in fact invented what many people know as the Romulan when you invented The Thing. Dave: It could be. Let me also mention one of the things that kept us occupied in talking about the game was trying to get everything balanced so that there was not a best way to play. Initially the impulse engines were worthless. So we made it possible so that if you used the impulse engines to enter a sector you weren't detected right away. And that meant you had first shot. But then that meant that the way to win the game was to go every place at a crawl using only the impulse engines. So at that point we decided that impulse engines took time and every once in a while a star would go nova. So if you depended entirely on the impulse engines you'd run out of stars or star bases.

Noah: So this is another thing, stars going nova, that I'm realizing you might have invented several of the things that later became quite familiar and famous to people in your version. This is entirely possible. Dave: Could be. The thing in particular I know while I was at UT had quite a following because anybody that could claim that they had seen The Thing got a certain cachet. Noah: That's right, yeah, this is fascinating. You know we've got one minute left, but what I'm thinking is I'm going to hope that we can explore some of these stories more in the future. I had no idea that Super Star Trek was a separate production from your code.

Dave: Well, you can't call it a separate production the way that Star Trek was separate from BASIC because that was our code. They just took it and added to it. Noah: Yep, okay. So, I'm glad that we got to learn this, I had no idea. So this is something to follow up. You know, a lot happened at UT with Star Trek, let's put it that way. And we're just starting to explore all of that history. So okay I think we're going to run out of time for right now, but I hope that we get to discuss this more in the future. And thank you very much for the last two days.

Dave: It's been fun.

Later note. Thanks to Clive Dawson for additional discussion on some of these topics. Highly recommended to see that here.