Linguistics Research Center, HRC DEC-10, ARPA

The explanation for this post will hopefully become apparent along the way. Winfred Lehmann founded the Linguistics Research Center at UT Austin in 1961 and led the Department of Germanic Studies in Schoch Hall for many years. ARPA's Bob Taylor studied experimental psychology and psychoacoustics at UT until 1959, focusing on the mechanisms of hearing and neural processing. UT was designated as an ARPANET site from 1977 and the ARPANET Directory from 1978 lists the Linguistics Research Center and Computation Center. Taylor moved to Xerox PARC, and the LRC later utilized Xerox PARC laser printer technology to produce complex, multi-character linguistic publications, such as Lehmann's A Gothic Etymological Dictionary, which required rendering over 500 special characters. [1]

Thanks to more fantastic discussion from Clive Dawson, we know a little about the LRC and this is the perfect place to share some of that. For context, Clive and Rich were discussing the lab and offices in the Harry Ransom Center where the KI DEC-10 was located from 1975 to 1982. The LRC clearly had offices adjacent to the DEC-10. Probably the DEC-10 offices were officially Computation Center, but it's even possible that UTCC and LRC were to some extent overlapping and unified? Here's a note from Clive.

Rich, the person you are thinking about across the hall at the Linguistics Research Center (LRC) was Dr. Helen Jo Hewitt, aka “HJ”.  She was a BIG fan of TECO, and was one of my “power” users.  She was one of the early “font hackers”, and I had developed a bunch of TECO macros for her.  She would come across the hall and pose an interesting problem, and a few minutes, or hours, or days(!) later, I would present her with another TECO macro for her growing collection. These tools would enable her, for example, to use a meta-language of her own creation to insert diacritics into a document, and then apply the appropriate macro to convert the meta-language into actual escape-sequence commands for the robotic typewriter to backspace, make micro-adjustments to the carriage, and type the appropriate symbol(s) to produce the desired diacritic at j-u-s-t the right position. Later on, as her daisy-wheel collection of different type-fonts grew, a macro would be used to type a partially-filled page of text, then command the typewriter to roll the page back to the beginning and pause. She could then switch in, say, the Greek daisy-wheel, after which the job would continue with the typewriter skipping directly to each blank spot where a Greek character needed to be typed.

All of this returned because of rereading the excellent ARPANET history [2], especially the section discussing the 1967 meeting where the IMPs were in some sense first thought of [3]. IMPs first became operational in 1969 and arrived at UT in 1977. A fun note from [2], "How could anyone program the TX-2, for instance, to talk to the Sigma-7 at UCLA or the computer at SRI?" This Sigma-7 at UCLA is the machine that Mike Mayfield wrote the first BASIC Trek game on [4].

View of HRC many of us are familiar with, approaching the entrance. 

[1] The university held high-value contracts for computational linguistics and translation directed by Winfred Lehmann, as well as sonar range modeling directed by Chester McKinney. The research was largely funded through traditional military service branches, such as the Air Force, Army, and Navy. The Ann Arbor meeting was uniquely focused on solving the physical and logical challenges of networking computer hardware together.

[2] Hafner, Katie, and Matthew Lyon. Where Wizards Stay Up Late: The Origins of the Internet. New York: Simon & Schuster, 1996

[3] UT Austin was not represented at the 1967 ARPA Principal Investigators meeting in Ann Arbor, Michigan. This spring gathering involved thirteen Principal Investigators who held active contracts with ARPA's Information Processing Techniques Office. The attendees, such as MIT, UCLA, Stanford, and the University of Michigan, were already deeply involved in time-sharing, computer graphics, and networking research.

[4] The SDS Sigma-7, located at UCLA's Boelter Hall, was the first computer node on the ARPANET, the precursor to the internet. On October 29, 1969, student programmer Charley Kline used the Sigma-7 to send the first message to Stanford Research Institute, establishing a crucial, albeit initially buggy, connection. At 10:30 p.m., the first message intended to be "LOGIN" was sent, but the system crashed after "LO", making "LO" the very first message. UCLA served as the Network Measurement Center, with the Sigma-7, under Leonard Kleinrock, analyzing network behavior. This event is recognized as the first footsteps of the internet.

The First Internet Computers In Texas

Thanks to Clive Dawson's excellent discussion, it's now known that the first Internet computers in Texas were on campus at UT Austin from 1977. There was an initial PDP-11, followed soon after by UTEXAS-20 a PDP-10 based DEC-20 and UTEXAS-11 a second PDP-11. And actually of course, what really came first was an ARPANET IMP, the essential portal into the ARPANET. In UT's case, there was an initial IMP located with the first PDP-11, followed soon after by a second IMP in the old Computation Center machine room. Like modern network routers, an IMP's only purpose was to interact with the network. Unlink modern routers, IMPs came in heavy steel cabinets and were centrally managed from the BBN network control center in Boston. While it's true that UT was already at the center of an important regional network [1], the first ARPANET machines on campus were historic [2].

Thanks to the work of Lars Brinkhoff the IMPs have returned to life and it's possible to reconstruct core parts of the original UT Austin environment, in other words, the dawn of the Internet in Texas. The question then becomes, is it also possible to reconstruct the original PDP-11s and DEC-20? There things become complicated. The short answer is that it may be possible for the DEC-20 because it was in some sense a regular, normal ARPANET machine with full support from DEC, in particular the TOPS-20AN operating system and AN20 interface hardware. These were regular commercial products with fairly good records and archival material still available today.

Before diving into the topic of the DEC-20, what about the PDP-11s? The key question seems to be the NCP Network Control Program software. This is essentially software driving the networking hardware connecting a machine to an IMP, and the issue here is that the PDP-11s were running adhoc custom UNIX operating systems (from the University of Illinois?) and it seems very unlikely that the software can be reconstructed now. In a nutshell, the PDP-11s were custom oddities and there's not much hope of restoring them. What's possible is that at some point in the future Lars and others will come up with realistic-enough placeholder software to run on PDP-11s. Old bits, as Lars says, but realistic-enough rather than what it was really like originally.

For UTEXAS-20, there's hope of approaching quite closely to what things were really like originally. A DEC-20 running the special ARPANET ready TOPS-20AN, with the AN20 networking hardware connected to a UT IMP emulator, probably the IMP in the old CC. The first trick will be to reconstruct the TOPS-20AN software, hopefully as an install tape that others can use for their own DEC-20 reconstructions. Then the hardware emulation within Rich Cornwell's PDP-10 code can be tackled. With software and hardware reconstructed for UTEXAS-20, eventually packets could again flow to a UT IMP. Ideally both UTEXAS-20 and the IMP will live side-by-side, each in its own independent Docker Container, easily deployed to the cloud, along with a third Container for the HRC DEC-10 running DECWAR. And the reconstructed 1982 UT environment will live on into an unlimited future.

[1] In 1969 the Southwest Region Educational Computer Network was created around the UTCC infrastructure, particularly the CDC 6600, with the help of a grant from the National Science Foundation. By 1972 the network consisted of eleven four-year colleges and universities and three secondary schools across Texas. UTCC staff and the computer science faculty provided the core resources for the network. The establishment of the network was a pioneering step in regional academic collaboration that cemented UT Austin’s status as the regional hub for computing and served as a precursor to modern distributed computing networks and the Internet. Of the fourteen institutions in the network, only UT Austin, Rice and Trinity universities had sizable computing facilities and well-established computing programs on campus. Note that both Austin High and McCallum High were network members.

[2] The first IMP was installed at UT Austin in 1977, with a second arriving within the next few years. By the March 1977 ARPANET map, Texas is clearly visible as a node, and the ARPANET Directory from 1978 lists the University of Texas at Austin (specifically the Linguistics Research Center and Computation Center) as a fully operational host. In the transition to the modern Internet in the eighties, UT Austin was assigned significant network resources. Notably, the Class A network 39.0.0.0 was assigned to the UT Austin BRC (Balcones Research Center) in later IP registries.

DEC's description of the ARPANET ready TOPS-20AN.

ARPANET IMP

ARPANET NCC network control center at BBN in Boston

DEC and the Dawn of Interactive Worlds

This post is a mashup of two draft book sections. What was the first section has been moved to the end here because it's a bit disorienting in the context of this blog, and maybe somewhat palatable here in the following order.

The arrival of the DEC PDP-10 marked a pivotal shift away from the IBM paradigm of computing. While the IBM 7094 had perfected batch processing, the PDP-10 pioneered interactive, time-sharing systems. This innovation fundamentally altered the relationship between the user and the computer, moving from indirect asynchronous process to a direct, real-time conversation. The philosophical differences between the two machines were stark, representing a clash between an established empire and an agile challenger. The PDP-10 was both an heir to the 36-bit mainframe tradition and a radical departure from its batch-processing legacy. It emerged in the late 1960s as a platform that pioneered interactive, multi-user computing, offering a glimpse of a future where users could engage with the machine in real time. The PDP-10's architecture was an evolutionary leap, fundamentally reshaping the relationship between user, software, and hardware.

DEC's market strategy was as sophisticated as its technology. The company positioned the PDP-10 to serve the same market niche as the 7094, large-scale scientific and engineering computation, but camouflaged its direct challenge to IBM by emphasizing its next-generation interactive and time-sharing capabilities. This approach was a deliberate effort to avoid direct competition with IBM, a priority of DEC’s Ken Olsen. [1] The result was a platform that preserved the 36-bit architectural lineage while introducing revolutionary features that would foster a new and unique software culture.

Fortran IV code naturally migrated over along with the 36-bit legacy. In some sense Fortran IV, 36-bits, and the punch card era are bound up together. Critically, the PDP-10 maintained this essential architectural link to the past and thus ensured the portability of Fortran IV numerical codebases, easing the migration of applications such as the Simplex algorithm and more generally Operations Research to this new, interactive environment. As part of that legacy, the implicit contract between the Fortran IV and Assembly language layers was maintained. The DEC Fortran IV compiler and MACRO-10 assembler were tightly coupled, and both had 6-bit character data in their genes, so the overall system was preserving continuity with the sixties.

Decwar is a late flower of that legacy, being genetically a member of the 36-bit Fortran IV and Assembly language family. Here is the ancestral link with Simplex, Operations Research, and the IBM 7090 series. The culture and spirit is a direct continuity back to the pioneering large software systems of the fifties and sixties, such as Simplex, now somewhat freed from the presence of actual physical punch cards, tapes, and batch processing by the introduction of video terminals, disks, and time-sharing, but preserving the family traits from a software perspective.

In the post-WWII industrial landscape, Operations Research emerged as a strategic discipline, transforming complex logistical challenges into solvable mathematical problems. The capital investment required for early mainframes was partly justified by the clear and substantial return on investment promised by solving large-scale optimization problems. These machines were purchased to answer critical industrial questions. How can we use our resources with maximum efficiency to generate maximum profit? A key to unlocking the potential of Operations Research was the Simplex algorithm, an automated method for solving complex linear optimization problems. It stands as one of the most important algorithms of the 20th century and was a quintessential application for the early IBM commercial digital computers. The first practical implementation was led by Dantzig using IBM hardware at the RAND Corporation in the early 1950s.

For industry, this was not an academic curiosity; it was a tool of strategic significance. When applied to the complexities of refinery operations, it could produce a deterministic, optimal solution for resource allocation. By implementing the Simplex algorithm, Exxon could systematically improve its profit margins, turning abstract mathematics into tangible financial gains. This direct line from computation to profitability provided the economic imperative for the entire mainframe ecosystem. Within the oil industry, the application was direct and transformative. By determining the most efficient processing pathways and product mixtures, the algorithm delivered a clear and massive return on investment, easily justifying the expense of purchasing and operating mainframe computers.

Computationally, the Simplex algorithm is pure numerical computing, grounded entirely in linear algebra. Its implementation consists of a series of vector and matrix operations designed to find a deterministic, optimal solution. The historical implementation of Simplex mirrored the evolution of programming itself. The earliest versions were coded directly in machine code, and all through the fifties, well into the sixties, implementation in Assembly language or directly in machine code was standard. Fortran entered the picture for this type of high-end computing gradually. In fact, the Simplex algorithm's industrial deployment paralleled the maturation of Fortran, which was created by IBM's John Backus in the early fifties at the same time that Dantzig was creating Simplex at RAND.

IBM's development of Fortran was a strategic masterstroke. The language was not merely a piece of software but a critical component of a complete system, engineered to make the formidable computational power of machines like the 7094 more accessible, practical, and valuable to its industrial clients. The core design philosophy of Fortran IV was explicit and unwavering: it was built for numerical computation. Its strengths lay in vector-matrix operations and linear algebra, precisely the kind of mathematics required by Simplex and the oil and aerospace industries.

IBM's business strategy was aligned with the parallel evolution of Simplex and Fortran. The company did not merely sell computers; it sold a packaged solution for industrial optimization. The IBM 7090 series of mainframes, Assembly code, and the Fortran IV compiler were designed to work together as a seamless platform for numerical computation. IBM understood its market precisely and was selling FLOPS (floating-point operations per second) to corporations like Exxon for the express purpose of running Simplex and similar algorithms. The value proposition was unambiguous. Invest in our hardware and software, and we will give you the computational power to make your operations more profitable. IBM did not merely sell hardware; it engineered and marketed a holistic computational solution.

Fortran IV, Assembly code, and the 7094 were, in essence, designed to work as a symbiotic system to dominate the burgeoning field of numerical computing. In the early 1960s, the 7094 stood as the archetypal supercomputer of its time. For major corporations like Exxon, it represented more than just a piece of advanced machinery; it was a strategic asset that could translate computational power into tangible industrial results by solving the largest and most complex numerical problems of industry. The 7094 was the engine of a new era of data-driven optimization, and its entire design was geared toward solving complex numerical problems at an unprecedented scale.

In a world where every machine cycle was a valuable commodity, programmers adopted a pragmatic, hybrid approach that blended high-level logic with direct, unmediated access to the hardware. Expert programmers viewed Fortran not as a final tool, but as a potential impediment to achieving maximum speed. Standard practice involved writing the high-level structures and logic of a program in Fortran, but pushing the performance-critical inner loops down into Assembly language or even pure machine code. it was common practice to rewrite performance-critical inner loops in Assembly language. This allowed direct access to the hardware, ensuring the machine's floating-point capabilities were exploited to their absolute fullest. The more frequently a section of code was executed, the greater the pressure to move it from Fortran into Assembly.

Recognizing the cultural realities of the Assembly tradition, where seasoned programmers viewed high-level languages as an impediment, IBM anticipated and facilitated a hybrid programming model. IBM was fully aware that this was the standard workflow for their most demanding customers. Consequently, they made every effort to ensure that the integration of Fortran and Assembly was as smooth as possible. The compilers and linkers were explicitly designed to facilitate this hybrid model, acknowledging that true performance lay in the fusion of high-level structure and low-level optimization. This pragmatic, two-tiered programming model became common in the sixties and seventies.

The system’s core architectural and operational paradigm was built around batch processing. A programmer's primary input method was a physical stack of punch cards, a card deck. Decks were submitted to operators, who loaded them into a card reader. The contents of card decks were recorded onto magnetic tape, which formed the heart of the 7094's data-handling system. The role of magnetic tape was paramount and fundamentally different from modern storage. An IBM 7094 was flanked by a row of ten tape drive cabinets. These constituted the machine's online file system, with each tape effectively a file. This simple, direct mapping obviated the need for a hierarchical file system with directories and subdirectories. The machine had ten online files, the ten physical tapes mounted on the drives. The user experience was defined by this batch-oriented workflow. It was an asynchronous, indirect, and entirely non-interactive process.

[1] Rifkin, Glenn, and George Harrar. The Ultimate Entrepreneur: The Story of Ken Olsen and Digital Equipment Corporation. Chicago: Contemporary Books, 1988.

Casscam Image Dissector Star Tracker

This is an experimental post. It's the first to expand the scope to cover the history of computing at UT's McDonald Observatory and Center for Space Research, as discussed in the About. And it's related to an excellent new post on Ken Sherriff's Blog. Ken's blog is a direct inspiration, much like the TCHC Blog. Ken's post explores a historical star tracker. Star trackers are a fascinating topic and played a role in the history of computing at UT. This post will focus just on the image dissector star tracker used in the McDonald Observatory 82-inch telescope Cassegrain Camera. Later posts will discuss the CCD star trackers used by the Center for Space Research for the NASA ICESat and ICESat-2 missions, and the associated computational modeling and data analysis. It's a long and complex story, covering different eras of computing at UT, and best explored gradually over time. There are also three good books for background reading on these topics [1], [2], and [3]. 

Around 1990, the 82-inch telescope at McDonald Observatory was used to make glass plate photographs of asteroids for the Texas Minor Planet Project (TMPP) and the Hubble Space Telescope Astrometry Team. It was the Indian Summer of traditional analog glass plate imaging, digital CCD imagers had not yet taken over this niche. The heart of the TMPP system was the suitcase-sized Casscam and its integrated star tracker. The Casscam was among the last and most advanced plate cameras. It's possible that the star tracking control loop was entirely analog electronics. Based on operational experience and the environment at McDonald, it's also possible that at least the encoders and logic were digital. It was directly descended from the first instruments used on the 82-inch. Below is an old photo of a direct ancestor, probably from the thirties. [4] The knife-edge focus frame and glass lens were still used in 1990, as discussed below.

An 82-inch telescope instrument and direct ancestor of the Casscam. The knife-edge focus frame lies to the left and has the basic outer dimensions of a glass photographic plate. The cone mounted on top is a heavy glass lens. Peering through the lens, celestial objects appeared much as in a long-exposure full-color astrophotograph.

Even the largest asteroids were small and faint, requiring a relatively long exposure to build up an adequate spot in the photographic emulsion on the glass plate. While building up an asteroid image spot, the Casscam had to track the asteroid’s apparent motion to hold the spot still on the glass plate. This apparent motion was principally from the Earth’s own motion and parallax effects. Against the background of effectively fixed stars, an asteroid moved appreciably when viewed from the Earth, especially when imaged with the magnification of the 82-inch telescope. The Casscam had to nullify this apparent motion during asteroid tracking. The photographic plate holder was rotated to align the asteroid's motion along the Casscam's primary axis. Then, during asteroid tracking, the Casscam moved the plate at the same speed as the asteroid's apparent motion, nullifying it. This was open-loop tracking, without feedback or active error correction.

Star tracking was also needed, separately from asteroid tracking. The stars in the image near the asteroid were also faint, and it was essential to build up adequate spots in the photographic emulsion for them as well, as they were the means to computationally tie the asteroid to the celestial reference frame. The computational modeling and data analysis aspects of this are subjects for later, dedicated posts. In this post, the focus is purely on the Casscam’s capability to track the stars and hold their image spots still on the glass plate. It did this using a combined image intensifier and image dissector tube star tracker locked onto a guide star. The image intensifier was a close relative of a photomultiplier tube. Incoming photons initiated a cascade of electrons down a cylindrical tube, roughly twelve inches long and a few inches in diameter. The circular end of the tube was a glass phosphorescent screen with a cross-hair etched on it. In normal operation the green fuzzy ball of a star image was kept centered in the cross-hair. Below is an example with a much lower magnification and wider field of view. Imagine this zoomed in on the central bright star, with a cross-hair on it.

Stars in an image intensifier. This one has a much lower magnification and wider field of view than the one on the Casscam.

Image dissector tubes seem to have been named to suggest dissecting or taking apart an image, in other words sampling an image. Image sampler may be a more suggestive name to modern eyes. An image is formed using electrons, and that image is then sampled, all within the tube. In the picture below, the lens on the right forms an electron image on the photo-electric plate while the aperture and valve samples the electron image.

An image dissector tube in its early role as a television camera. [9]

The Casscam's combined image intensifier and dissector was sampling the electron image just at the center of the field of view, around the cross-hair. Once a star was placed in the cross-hair, the sampling would output an error signal whenever the star began to drift away. The control loop would then move the plate holder to zero the error signal and correct the drift. The control loop was running at about 1 Hz, and produced a loud clicking noise every second. This soon became a familar sound in the darkness of the 82-inch dome, a steady click click click while the star tracker control loop was active.

In note [5] below there's mention of a 64x64 image dissector at McDonald in the seventies, so clearly something like sampling of a pixel grid was possible and a viable technology until solid-state CCD imagers became available in the eighties and nineties. The transition to CCD star trackers will be explored in a future post about the Center for Space Research and the NASA ICESat star trackers.

Since this post includes a photo showing the knife-edge focus frame, its use can also be described. At the beginning of an observing run, early steps included preparing the Casscam and focusing the telescope. The Casscam was a heavy instrument, about the size of a suitcase. The McDonald operations staff would mount it onto the back of the 82-inch using a lift and heavy bolts. The combined system then needed to be focused by moving the secondary mirror, which was roughly fifty feet overhead. The secondary mirror was moved by an electric motor controlled from a control paddle on the observing platform. Focus was achieved using a knife-edge technique within the focal plane. By placing a metal frame with a straight knife-edge into the Casscam’s plate holder, the observer could adjust the secondary mirror until the light from a star was cut off instantaneously rather than gradually. On occasions when time permitted, the knife-edge focus frame could be replaced by the massive glass eyepiece also shown in the photo. Needless to say, star-gazing through the 82-inch telescope was something very special. 

Notes and photos

[1] MacKenzie, Donald. Inventing Accuracy: A Historical Sociology of Nuclear Missile Guidance. Cambridge, MA: MIT Press, 1990.

[2] Spinardi, Graham. From Polaris to Trident: The Development of US Fleet Ballistic Missile Technology. Cambridge: Cambridge University Press, 1994.

[3] Grewal, Mohinder S., Angus P. Andrews, and Chris G. Bartone. Global Navigation Satellite Systems, Inertial Navigation, and Integration. 4th ed. Hoboken, NJ: John Wiley & Sons, 2020.

[4] Evans, David S., and J. Derral Mulholland. Big and Bright: A History of the McDonald Observatory. Austin: University of Texas Press, 1986.

Direct ancestor of the star tracker discussed in Ken's post. [1] 

Another direct ancestor.

[5] Though the image dissector is capable of scanning a two-dimensional image, it is difficult to do so before the phosphor of the last intensifier has decayed substantially. McDonald observatory did indeed build an area photometer which scanned a 64x64 two-dimensional array (P. M. Rybski, G. W. Van Citters & G. F. Benedict, IAU Coll. 40 Astronomical Applications of Image Detectors with Linear Response, 1976). Bull Astr Soc India, 406-423 December, 1985. This could very well have been related to the Casscam star tracker. Fritz Benedict was a member of the Hubble Space Telescope Astrometry Team into the nineties.

[6] Image dissector tubes have found widespread use in astronomy, beginning with the pioneering work of L. Robinson & J. Wampler in the early seventies. Though occasionally used as imaging devices for either recording extended fields or guiding in automatic/remote-manual mode, the more popular usage has been in intensified scanning spectrometers. Such a system was first developed at Lick Observatory (Robinson & Wampler, Publ. Astr. Soc. Pacific 84, 16 1972), who subsequently duplicated it at the Anglo-Australian Observatory. Kitt Peak National Observatory, European Southern Observatory and Ohio State University have subsequently built similar instruments, some of which are still maximally used. The introduction of more sensitive detectors like the image photon counting systems and charge-coupled devices, and resultant shift in the emphasis of observing programs to fainter limits, have rendered the image dissectors less popular in recent years. However, the image dissector remains the most useful detector at intermediate light levels where avenues remain open for astronomical research. Ibid.

[7] The Intensified Image Dissector Scanner has been in routine use at Kitt Peak National Observatory for two years ... In this instrument, the output phosphor of a three-stage image intensifier is used as a temporary storage medium for incoming photon events. An image dissector tube is used to rapidly scan this output phosphor. Instrumentation in astronomy III, Proceedings of the Society of Photo-optical Instrumentation Engineers, v172, p86, 1979.

[8] An image dissector, also called a dissector tube, is a video camera tube in which photocathode emissions create an electron image which is then swept up, down and across an anode to produce an electrical signal representing the visual image. It employs magnetic fields to keep the electron image in focus, and later models used an electron multiplier to pick up the electrons ... they continued to be used for imaging in early weather satellites and the Lunar lander, and for star tracking in the Space Shuttle and the International Space Station. Wikipedia

[9] https://www.earlytelevision.org/baird_and_farnsworth.html

Machines in Austin and San Marcos

Thank You to Clive Dawson for this fantastic info! What Clive is discussing here fits together perfectly with info from the PDP-10 serial numbers webpage, as discussed below in the Notes.

I am not aware of a dual KL DEC-10 on the UT Austin campus. The KI DEC-10 was in the Humanities Research Center (HRC) (Now known as the Harry Ransom Center). The Research DEC-20, named "UTEXAS-20" on the early ARPANET and R20.UTEXAS.EDU after the domain system came about in 1983, was in Painter Hall. The Academic DEC-20, named the A20, was housed in the Graduate School of Business (GSB) which was, incidentally, built on the site of the old Pearce Hall.

Any report of DECWAR being played on a TOPS-10 Dual KL would not have occurred on the UT Austin campus.  The Texas State Board of Control, which later became Texas State Purchasing and General Services Commission, had at least one KL, possibly a dual KL.  I believe that Tommy Loomis, a systems programmer who worked with me on the KI DEC-10, moved over there sometime after the demise of the KI, so maybe he took DECWAR with him?!  Another nearby KL (possibly dual?) was at Southwest Texas State University in San Marcos (now Texas State University).  I’m pretty positive that DECWAR was running on that system.

An intriguing question is whether DECWAR was ever ported to TOPS-20.  It never ran on the Research 20 (I would’ve known about it) but perhaps it found its way to the Academic 20?   DEC supplied a piece of software called PA1050 (aka “the compatibility package”) which allowed most TOPS-10 programs to run on TOPS-20.  But the memory organization of both operating systems was very different, so I’m guessing that porting DECWAR would have required a bunch of extra effort (i.e. a complete rewrite of the MACRO code) considering the tricks it employed with the shareable high segment.

Notes

We also have the following from the PDP-10 serial numbers webpage

690 TOPS-10 University of Texas Austin, TX KI10 ------> HRC!:)

1114 TOPS-10 Texas St. Purc. Austin, Texas KL10B CPU1? -------> AHHA!!! [1]
1360 TOPS-10 Texas St. Purc., Austin, TX KL1099D CPU0?

2403 TOPS-10 (MARS::) Southwest Texas University, San Marcos, TX KL 1095 --> [2]
2908 TOPS-10 (SATURN::) Southwest Texas University, San Marcos, TX KL1095

[1] Now Texas St. Purc makes sense!!! Thank you Clive:)

[2] This is where teenage me played DECWAR, circa 83 to 85!:)

[3] History and Functions of the Texas Board of Control. Published: 1976. The Board of Control was established by the Texas legislature in 1919 and was composed of three members appointed by the governor for six-year, overlapping terms. The major duties of the board were to purchase supplies for the departments and eleemosynary and educational institutions of the state; control the state's public buildings and grounds; rent extra buildings and offices for state agencies; prepare the biennial appropriation budget and submit it to the governor; and control the state historical parks. ... In the 1970s the board's responsibilities included managing a system of telecommunications services for state agencies. It maintained a central office-supply store, messenger service, and telephone service, as well as an office-machine repair service. The agency was organized into six divisions: Central Purchasing, Centralized Services, Automated Services, Building and Property Services, Security, and Telecommunications Services. In 1979 the Board of Control was abolished and replaced by the State Purchasing and General Services Commission.

Tommy Loomis. Thank you to Rich Denney, with the antennae, for these photos!

Sam Houston State Office Building on the Capitol's grounds.
Could be that the dual KL was in here?

Fall 2025 Event Pictures and Videos

This post is an early experiment with sharing pictures and videos, in this case from the Fall 2025 Event. And also an early collaboration with the Travis County Historical Commission blog and Richard Denney in particular. Rich is a historian, one of the original UTCC staff working with the DEC-10 in HRC, and a photographer. Many of the photos here in the DecwarOrg blog and on the TCHC blog are by Rich, and we will repeatedly say Thank You for Rich's work: photos, articles, discussion, and feedback. TCHC blog and Rich are the role models for DecwarOrg blog. Here are two TCHC posts of special historical computing interest. First the new TCHC post

https://traviscountyhistorical.blogspot.com/2026/04/ut-austin-computation-center-and-decwar.html 

and second, a TCHC post about MCC and Austin's AI history

https://traviscountyhistorical.blogspot.com/2023/05/a-history-of-ai-winter-and-austin.html 

Mk Haley and Eric Freeman are faculty in the UT School of Design and Creative Technologies, and Noah Smith is a UT Aerospace Engineering alumni. Mk, Eric, and Noah collaborated on the Fall 2025 Event, spontaneously forming DecwarOrg along the way. The website and this blog are building on that. Roughly speaking, DecwarOrg began taking shape around the nucleus of the Event, and things have been growing spontaneously from there.

Below are a few pictures of attendees experiencing a bit of living history, thanks to Eric's DecwarJS reconstruction. Eric's work brings the seventies technologies from UTCC all the way up to the present day, making them completely accessible. Eric's code and workflows are cutting-edge and provide a great experience for everyone interested in the history. At the same time, anyone interested can also simultaneously get hands on with the original fifty year old code and environment. Both the modern and the vintage are available side-by-side, open for use together, separately, or in ways we haven't foreseen yet. In particular, both the modern and vintage approaches together are an ideal foundation for future AI applications, with AI players bringing to life the sights and sounds of eighteen players battling across the galaxy back in 1982. In short, the Org is working with something very special here, and is sharing that, and welcoming everyone to participate in the next chapters of this surprising, thought-provoking, and historic fifty-year story.

In the entrance to the event, arcade-like terminals with DecwarJS running.

Old-timers from the eighties were also playing remotely, from other states and countries.

Eric watches over his DecwarJS work in action.

Here's a video walk through of the event.

And two videos that were created for and shown during the event. The first is an intro to some of the history, and the second was designed for use with a projector to help establish the vibe during the event.

The Computer Science Department Locations On The UT Campus

We received a fantastic note from Clive Dawson this morning that we have to share right away. This explains and clarifies mysteries that have confused even those with decades of experience on campus!:)

From Clive Dawson

This is what I remember about the buildings that the Computer Sciences Dept. occupied over the years.  When I arrived in the Fall of 1971, CS was housed in Waggener Hall together with Classics and Philosophy.  Pearce Hall (Building) was to the south, across Inner Campus Drive, just west of the Business Building (BEB).  It housed an RJE (Remote Job Entry) terminal which is where Dave Matuszek remembers going to submit card decks and retrieve printouts.  These functions could also be performed in the Computation Center proper.

A year later ('72), CS moved to Painter Hall, north of the Main Building, where it stayed for many years.  We shared it with the Physics Department, and it also housed the Painter Hall Telescope.  If any building can be dubbed the “Home of Star Trek”, it would be Painter, just as the HRC was the “Home of Decwar”.

In the early ’80’s  there was talk about constructing a new dedicated building for CS.  A “slot” was even reserved in the UT construction schedule for this, but much to the dismay of many CS faculty, this slot was “stolen” by the new MCC building at Braker and Mopac around 1986-88.

The Taylor Hall Annex on the corner of 24th and Speedway housed another of the Comp. Center’s RJE sites, together with several CC user services (consulting) offices.  It was torn down in the early ’90’s to make room for the ACES building.  By then, the CS Department had moved from Painter into Taylor Hall proper. 

In 2010, the plan was to tear down Taylor Hall to make room for the Gates Computer Science Complex and Dell Hall, commonly known as the Gates-Dell Complex (GDC).  So the CS Department was scattered to various places on campus, including the ACES building as well as a temporary building in the parking lot on the northeast corner of 24th and Speedway.  The CS Department Office was moved to this temporary building.

Finally, in 2013, the GDC was completed.  Some CS people who had a significant affiliation with ACES (now known as the O’Donnell Building) stayed there, but the bulk of the CS Department moved into GDC where it remains today.

Waggener

Pearce Hall (Old Law Building)

MCC

Later note. Thanks to Clive for this discussion. It started with the Oral History Interview with Dave Matuszek. Highly recommended to see that here.