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. 

Notes For Beginning A Timeline

1973 - 1974 There is a historical backstory behind Decwar's Romulan, stretching back to the 1974 UTCC CDC 6600 Fortran Star Trek single-player code created by Dave Matuszek. At that time, there were many variants of the single-player BASIC Star Trek game, with a rapidly expanding zoo of improvements and unique curiosities across all of the versions. Dave was able to introduce something very special into his Fortran version: a threatening computer-controlled adversary that would intermittently raise the tension level for the human player. This was almost certainly the genesis of what would become the Romulan in Decwar, likely transmitted by Robert Schneider across the gap between 1974 and 1978. In the 1974 code, Dave named the threat The Thing. Simply replace The Thing with Romulan, and the idea is clear. Notably, Decwar’s text SCAN map used the same ? mark to represent the Romulan as Dave's SCAN map used to represent the The Thing. Dave had played the UTCC CDC 6600 BASIC version, and explains that it had a bad habit of throwing long quotes from Marcus Aurelius at the users, a feature he found intolerable on a 110 baud terminal. Dave also explains that UTCC staff hated the BASIC version because of its performance issues.

1978 - 1982 UTCC DEC-10 people are creating Decwar, building on the Fortran Star Trek single-player and two-player code that was created on the CDC 6600 from 1973 onwards. They're usually working in the offices around the DEC-10, in the HRC building on campus, right beside the Drag, Dobie, etc.

1983 - 1998 The game is exploited by CompuServe (CIS). In the first months as a commercial CIS game, it's called Decwars (with an "s", instead of Decwar). This period lasts roughly six months to a year. It's pure Decwar, no real changes, fast, responsive, and thrilling. This is the source code we have today. In our project utexas reconstruction we're actively removing the small CIS additions to the code. They're glaring and obvious, related to selling things to players, so it's not a real issue. Soon, it's rebranded as MegaWars and intentionally slowed down. CIS charged by the minute, enough said. With MegaWars, all Star Trek names are removed to dodge lawsuits, this is 1984, maybe as early as late 83. Later, MegaWars III is even slower and more time consuming. By that point the original UT Decwar was a rather distant ancestor.

1995 All through the nineties, people are searching for the code on the Internet, primarily via USENET newsgroups. In 1995, a mystery person sends the very early CIS codebase and environment to Harris, attached to a mystery email. The complete original UTCC tape contents are in there, including even the original letter from UT to CIS. Things are all jumbled together and it takes research and patience to disentangle. We've done that in the project utexas reconstruction. The code is from 1982 and 1983. It's a snapshot from the months immediately after the UT tape arrived at CIS, while CIS was still working on getting the code working in their environment. UT code was not changed, CIS was only adding a few commercial things and getting everything working. Our theory is that the mystery person carefully preserved a tape containing this early snapshot when they realized what was coming, and because they knew that it would become historic later, when the real, serious, major CIS changes kicked in. They are a hero for doing that! Decwar was an immediate hit and sensation on CIS, and the mystery person was wise enough to understand what that meant and took action. This was well before the MegaWars era. There is even debugging style output showing the state of the CIS DEC-10s, almost certainly reflecting the period when CIS was getting the game working within their commercial environment. Their primary concern was bringing in paying customers to their special dedicated DEC-10 and charging those customers by the minute. The expert on this period is Merlyn. Merlyn very likely knows more about the CIS period than anyone except the actual CIS employees and contractors.

2011 The code from the mystery 1995 email becomes publicly available. It's in the UT Austin Briscoe Center archive, and downloadable from the Briscoe website, and it's on GitHub in Merlyn's Decwar repo. At this point, Merlyn does intense work to deactivate CIS specific customer billing and network control code so that the code runs on a standard SIMH PDP-10. He commented all of the changes directly in the source files for all to see, and has mentioned using DDT at points during his effort. Merlyn is also the first person to discover the-hard-way that it's essential to use a DEC F66 Fortran complier, FORTRAN-10 V6 in particular. Fact is, F77 is simply a no-go. This was the heroic phase of the archaeology, and Merlyn's accomplishment should become legendary.

2024 PiDP-10 front panel reconstruction is released thanks to efforts of Oscar, Lars, and RichC. This naturally leads to many new things.

So, long history, and the 1995 mystery email is quite early in all that! Three central names forming the essential historical skeleton for UTCC. 

1. Dave Matuszek 73-74
2. Robert Schneider 74-82, the bridge from the CDC 6600 era to the DEC-10 era. That's Robert to the left in the picture above.
3. Bob Hysick 78-82. Bob is working at the terminal in the picture up at the top.

UTCC ARPANET IMP

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

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

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

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

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

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

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

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

Mainframe Culture

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

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

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

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

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

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

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

UTCC DEC-10 Staff

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

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

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

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

The following two photos and accompanying info are from Rich.

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

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

And the following info is from Clive.

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

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

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

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

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

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

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

Small interconnected world.

Assembly and Fortran

By the 1980s, PDP-10s were entrenched in universities, computing centers, and time-sharing installations. The economics of the period favored incremental software refreshes rather than disruptive changes in language standards. DEC's choice to maintain a robust Assembly language and Fortran IV toolchain reflected the installed base's dependence on legacy code, local modifications, and mixed Fortran and Assembly programming. Decwar emerged from this institutional ecology. An environment in which students, researchers, and system programmers routinely extended existing subsystems, shared code across accounts, and optimized routines for a time-shared population of users. In this milieu, stability and coding conventions mattered as much as language expressiveness. 

Decwar was written not for isolated personal machines but for multi-user communities sharing a common computational space. Its reliance on predictable compiler output and stable low-level encodings enabled a shared, real-time game environment on a platform never intended primarily for interactive entertainment. More broadly, Fortran IV demonstrates how language stability can enable specific creative forms. The persistence of its semantics allowed a hybrid program, part high-level logic and part low-level Assembly code, to function reliably over many years within its birth ecosystem.

This case study demonstrates a foundational principle of legacy system migration. Historical fidelity of the toolchain is not a matter of preference but a core engineering requirement, overriding any perceived convenience of more recent tooling. The process of migrating vintage software such as Decwar presents unique challenges that transcend simple code porting. Success hinges on a precise understanding of the intricate dependencies between an application and its original development environment. In fact, it is fair to say that it would be very difficult to migrate Decwar’s Fortran IV. It’s too intertwined with the environment in which it was created. It can be recreated and reproduced in other environments and languages, but it can not easily be migrated piece by piece.

Decwar's longevity therefore depends on specific historical layers of the PDP-10 software ecosystem. It is not merely a Fortran IV program. It is an artifact of specific compiler and assembler versions, all deeply rooted in PDP-10 hardware and TOPS-10 operating system installations circa 1980. In the study of digital history, it is tempting to view computing hardware and software as neutral tools, passive instruments waiting to be wielded by human creators. There is a more nuanced premise, however. That these systems are active environments, technological ecosystems that both enable and profoundly constrain the creative works born within them. The mainframe systems of the sixties, with their unique architectures, toolchains, and cultural norms, constitute a world unto themselves.

Containers and Ultimate Portability

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

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

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

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