Advent of Computing - Episode 177 - Getting Real with RSX

Episode Date: February 23, 2026

Who wants to hear me make incorrect assumptions about old software? RSX is a system that, from the outside, can sound like it has a similar story to that of UNIX. First developed for the PDP-15 in 1969, RSX becomes much more well known when it migrates to the PDP-11. It becomes a multitasking and multiuser system. A key difference is niche. While UNIX is a very general purpose system RSX is built for real time. That leads to something very unique.

We've pretty constantly talked about the taxonomy of computers and programming languages here on advent of computing. It's hard to talk about computers for this long and not get hung up on taxonomy, right? Like, how are you supposed to explain a computer in one or two words? What's a machine's biddedness? Is it a stack machine? Does it use a von Neumann architecture? Is it a register memory or memory memory memory architecture? You could probably build up a pretty comprehensive tree this way.

I mean, in theory, you could even have digital genera and classes, although maybe using the term class could get a little bit confusing later on. If one were to create that grand tree of digital life, then one of the early splits may come from an unexpected place. That is, real-time operations. Early on, computers were pretty non-interactive. A machine just sat there waiting to receive orders. Once it did, the computer would run a program to completion

with no room for interruption unless you wanted to stop the whole darn thing. Pretty soon it was realized that, you know, it may actually be useful if a computer could react to some kind of external stimuli, like, say, pressing the keys on a keyboard. That is really basic stuff, I know, but we didn't always have the hardware for it. This split between reactive and non-reactive computers, for lack of a better term, happened sometime around the early 1950s. But that's just hardware.

With the split and hardware came a related split in software. How does one handle these newfangled, well, buttons, do you call them? How would you deal with a program that gets interrupted by someone banging away at a keyboard or more realistically, how do you write a program that can collect data and control industrial machines without everything fall into bits? It's a tricky task, one that actually requires a very different approach to programming. Welcome back to advent of computing. I'm your host, Sean Hass, and this is episode 177, Getting Real with RSX. Today, we're diving headfirst into a lineage that I know almost nothing about.

But it feels somewhat familiar. Allow me to explain. RSX11 is an operating system that was originally developed for the PDP 15. It was first known as RSX, 15, but took the 11 name when it was ported over to the PDP 11. RSX11 is itself a pretty big deal. It also goes on to influence something even bigger, an operating system known as VMS. VMS, in turn, is a major influence on Windows NT. From this short telling, it should be clear to see how important RSX is.

The lineage from 15 to 11 to VMS to NT isn't direct. There's no shared source code, but these systems are closely connected. There's at least one programmer, Dave Cutler, who worked on all of these projects, at least once we get to RSX11. This also means that if I was ever to cover VMS, which I would very much like to do, then I'll need to talk about RSX anyway. As for familiarity, well, you may not see it at first. In starting up my research for this episode, I was struck by how the story of RSX11 mirrors the early history of Unix. This is made even more apparent when you take the time period into account.

RSX is developed in 1969. That's the same year as Unix. So both of these systems are the same age, end up making their way to the PDP 11, and have at least some high-level programming involved. I say some, because according to initial research, RSX used Bliss in certain places. May not be familiar with Bliss, so let me jog your memory. Bliss was a direct competitor,

to see in this period. So, anytime I get a whiff of bliss, I'm pretty interested. But I'm not really just here to make comparisons to Unix. That would be kind of useless. The comparison here will be handy because Unix is a contemporary operating system on a very similar platform, well, on the same platform, that I'm pretty well versed in. Keeping my Unix hat somewhere nearby while I'm working on this episode will be super handy for seeing how RSX is unique. But that being said, I am very interested in RSX's story itself. A huge aspect of that is its lineage. RSX is one of those little-known programs that has had an outsized impact on the world. That is fascinating all on its own. There's also the fact that RSX is a real-time operating system. We've touched on real-time

systems on the show before, but not in a very systematic way. Talking about RSX gives us a perfect excuse to get into some of the nitty-gritty details. Today's story starts with the PDP 15. What? You haven't heard of it? That's not too surprising. There were fewer than 800 PDP 15s in the wild ever. It was the last of Dex's 18-bit computers.

That series of machines started with the PDP The 15 points to a bit of strain in Dex's larger portfolio. By the time this machine was released, there were a number of computer families kicking around inside digital. That included a family of mainframes, small lab computers, and this new PDP11 mini-computer thing. The 18-bit family filled this niche that was starting to evaporate. In theory, the PDP 15 was intended to be used for real.

time systems. It was meant to work with external hardware and handle time-sensitive tasks. Think industrial control or even laboratory equipment. But by 1970, there were other options. The PDP 8 was designed specifically to be a small, cheap lab computer. The newcomer, the PDP 11, quickly became a workhorse for just about, well, just about everything, including real-time systems. The PDP 11's architecture was just really, really well suited to being connected to external hardware. So, you know, it's kind of tough to beat that. There's also something to be said at this point about computers shifting from specialized to more generalized machines, but that's a much larger topic.

So I'll just say we're looking at a bit of a shift here, or at least I think you could see a larger tide. The point is, the PDP 15 is designed to be used for real-time systems. That's pretty specialized. But what does that particularly mean? For this, we go back to basics. The deck 18-bit family is originally based off a computer built at MIT called Whirlwind. I say originally based. There are quite a few steps between the Whirlwind and the PDP1,

but I'm just going to say it's based off Whirlwind. That's a short general summary. Now, Whirlwind was probably the first digital real-time system ever designed, and it was meant to be used for flight simulation. In that kind of system, a computer has to respond to inputs, and it has to respond in very particular ways. The original design was to have a simulated airplane cockpit hooked up to Whirlwind. In that system, a pilot would wrestle with real-ish,

aircraft controls and receive instant feedback. The idea being that the simulation could be used to train a new pilot or to help experienced pilots evaluate changes to an existing aircraft. In that system, tight timing is a must. For the simulation to be worth a darn, the computer needs to respond in a specific amount of time to each input. If you push down the yoke in the simulator, the computer needs to adjust the airplane's pitch after a set period of time. The important part isn't necessarily speed here, but predictability. A simulation wouldn't work very well if there was some variable amount of lag between input and response. It's bad to be slow, sure, but it's also bad to be fast. It has to be predictable. That's a tall order. Part of the puzzle comes down to

hardware. When a physical event occurs, like the yoke being pulled back, a software event has to occur. That's handled using what are known as hardware interrupts. A computer with hardware interrupts is able to receive a signal from the outside world and then act on it. A pulse hits a pin, the computer stops, looks up what it's configured to do for that specific pin getting a pulse, and then it runs the correct code for that physical event. Another part of the puzzle is purely software. Sometimes you want to schedule out execution of some code or defer execution until later. That requires a different mechanism, or at least a slightly different one.

When a user in the simulator presses a button, you might want to wait three seconds before turning on a warning light, but you still need to respond to inputs during that time period. so you schedule an event to occur three seconds in the future. That can work in a similar way to a hardware interrupt depending on the computer you're working with and how your software is set up. It should be clear to see how complex this problem is, and also how it isn't just a matter of performance. One common misconception is that real-time systems

are just very fast operating systems, but that's not really the case. Real-time systems are about predict, not speed. It can happen that sometimes being predictable means being predictably fast, but still, predictability is the prime goal. All right, with that out of the way, with the Kopsai 101 Corner done, let's go back to history. This episode, I get to use a very interesting source.

That makes it a good episode, at least as far as I'm concerned. Allow me to introduce one Dan Breivik, aka Mr. R.S. RIVC, Revik ends up writing the prototype version of RSX, and due to this is often called the creator of RSX, even though he himself will admit it was a big team effort. This is actually one of those fun cases where we have a program that's written by a lot of people, commonly attributed to one creator, and that creator doesn't really like that. I think that's neat. But anyway, I said I have a neat source.

In the thousands, Breivik wrote an outline for a talk on the history of RSX. That outline is public and gives us the full story of Mr. RSX himself from the man himself. It's neat because, despite being fragmentary, it goes into a lot of personal detail. So how did Breivik find himself intertwined with real-time systems? It all starts with the PDP8. Remember what I was saying about Dex product line being kind of confusing? This is a prime example. The PDP1 family, the 18-bit machines, were sold as real-time systems.

The PDP-8 family was sold as small and inexpensive laboratory equipment. But these machines can also be used for real-time systems. And in many cases, they were. It turns out that data acquisition, the whole point of having a computer in a lab, requires, you know, real-time system software. In the mid-60s, Brevick was contracted by DEC to develop a system called IN-DAC-8. That's INDAC-8. It was a real-time data acquisition system for the PDP-8.

In case you haven't caught on yet, if DEC software has dash number, that number is the computer that it's written for. Now, INDAQ is interesting because it's not exactly an operating system. It's also not just a programming language. It's this weird mashup. It's a language system. Maybe you'd call it a programming environment. Indac 8 would load itself onto a PDP 8,

then users would load code written in Indac 8's own language. That code would then describe the data acquisition task the programmer wanted to do. The INDAX system handled things like scheduling tasks, multitasking, memory allocation, and basically everything that an operating system would normally do. The key thing here being that the language and the operating system were tied at the hip. In that way, it's actually very similar to the Dartmouth time sharing system and Dartmouth Basic. In 1969, Breivik traveled to Purdue to show off his new system. Brevick's trip was for an event called the Workshop on Standardization of Industrial Computer Languages.

Note the real-time nature of the topic and the fact that this was a workshop on programming languages. Despite being more a language than an operating system, Indakate had many of the features of a real-time operating system already. In fact, a lot of the topics at that workshop fall into a similar, weird, blended category as in DAC 8. At the workshop, according to Breivik, a committee was formed to come up with a list of standard calls used by real-time systems. Now, from Breivik directly, quote,

it was exactly what I had in mind for the basic functionality of a next-generation real-time executive. My notes became a requirements document to justify what became RSX, end quote. What exactly was discussed in committee? well, we actually have a report that won Ted Williams, the very one that organized the workshop, put together. The relevant part here is, at least in my mind, a concept called the Software Factory. This is one of those terms that I've actually never heard before, but immediately made a lot of sense when I read about it. A software factory is a system that lets a programmer whip up special purpose software that's a modification to some existing system.

That may sound a little vague. It essentially consists of a compiler, libraries, and a host environment. The idea is that if you have a lot of nerds writing real-time software, they all have very, very similar requirements. They all need to write for the same constraints and the same handful of features. You know, you read off a serial bus every 10 milliseconds and put it into a file, or you wait for a button to be pressed, and then you run a routine. If a programmer was left alone in the wild, they'd have to write a lot of code to facilitate running a routine when you press a button. So to make that easier, you bundle every tool they will need together in a way that can be reused. This allows programmers to not have to write task schedulers or interrupt handlers every time they want to do a real-time task.

You just provide that for them. That means programmers can focus on just the functional part of their code, not all the standardized bits. It's even possible to use a software factory without any custom code. The key here is modularity. A programmer could just pick up a pile of off-the-shelf modules and use that to build a system. You could, say, grab one module for recording data from a serial port and another to write data to a file, plug them together, and then type out some arcane commands and be met with a working system. This ends up being very similar to an operating system, but more fixed.

A programmer steps into the digital factory, throws in a little bit of custom code, and out the other end, they get a program that can be loaded on a computer. The programmer may have even written a small program, maybe even just code to print the time of day on a slip of paper every hour. The factory handles every other detail, giving them a full system that can run on a computer unaided. Again, this sounds pretty similar to a cross between an operating system and a language, or maybe an operating system and a compiler. But there are a few key differences. One is that the resulting system wouldn't look like any operating system we're familiar with. The theoretical software factory produces something that just runs with little-to-no user interaction.

You don't necessarily even have a user interface. It's more like a tool that lets you turn a computer into an appliance. That's why some of these early real-time systems are called executives or monitors, but not operating systems. They're just different. After attending the workshop, Breivik went back to deck filled with good ideas, and he drafted up his own report. That report would contain the earliest plans for RSX-15, the real-time system executive, of course the X from executive, for the PDP-15 computer. At the time, Brevick was

calling this the real-time monitor. The name comes along a little bit later. I'm going to try to stick to using the term real-time monitor for right now, because RSX-15 is slightly different, but not by much. So what does the real-time monitor look like? Well, it's at once familiar and kind of strange. Let me explain the user's point of view before I get into the technical details. When you boot up the system, you're dropped into the monitor's user interface, and you start the process of system generation. This is a only a temporary interface, though. It's just used to set up the executive. From here, you allocate chunks of memory for different tasks, specifically which task can go into which memory block. You

connect interrupt handlers to interrupt lines, and you set up any initially scheduled tasks. Then you tell the monitor to run, and you're kicked out of the digital loop. At least in some cases. A programmer could, theoretically, write a task that would involve a terminal. But as far as the monitor is concerned, once it kicks off the executive, it's done with humans. It's time for it to run task after task after task until the computer is unplugged. This is, simply put, a software factory. It's a factory that allows you to put together modules to form a running system. Then you can load that onto a computer, turn it on, and just let it do its thing. You can even bring your own custom modules for special jobs. With the real-time monitor, you can turn a PDP-15

into a data acquisition box, an industrial machine controller, or even an aircraft simulator. But what about the finer details? This is where the proposed real-time monitor really, really sounds like an operating system. The bread and butter of the real-time monitor is the task. That's the smallest unit of code that the system deals with. Each task is treated as an image. That is, it's a continuous chunk of data that can be loaded into memory or written out to disk.

That's important because it allows the state of a task to persist. Basically, a program can keep track of the internal data that it had between execution. Tasks can either be active or inactive. Now, that's odd language to use, but I can't think of a better set of terms off the top of my head. Active tasks are ones that are loaded into memory, and those tasks are basically just loaded up and waiting to execute. Inactive tasks are on disk. That can either mean something like Unix's swap space or just a program that's ready to load, but hasn't been pulled into RAM quite yet.

It's just not quite time to run it. I think it's probably closer to swap than anything in this draft proposal, as in a task image that's ready at a moment's notice, but just not in RAM. But hey, again, there's a draft. This is an actual software. We're a little bit ambiguous still. Each task has a priority assigned to it. The executive keeps a list of those tasks ordered by priority.

High priority tasks get to run first, and then lower price. priority ones get a chance later on. So far this is all pretty standard stuff. There are a lot of operating systems that work in a very, very similar way. What makes this proposal interesting is how interrupts are addressed. Each task can attach itself to the PDP15's interrupt lines. When an interrupt is fired, when some external hardware sends the correct signal, the monitor stops and goes through its list of tasks. It finds the highest priority one, that's bound to that interrupt and runs that handler. Once that's done, the monitor goes back to its list

and runs the next highest priorities task handler, and on down the list. There are a number of other details about I-O and device drivers and memory partitioning, but the interrupt handling is core here. Tasks are bound to interrupts, and they have definite priorities. That made for a compelling proposal,

so much so that Breivik started working work on actual software. When it came to RSX, Breivik didn't go it alone. He did have a co-conspirator. That was a man named Sam Rees. Now, the details on Reese are, say it with me, pretty scant. Initially, Breivik had written in-deck 8 as a contract job, but by 1969, he was working at Deck as an employee.

After writing the initial RSX proposal, Breivik needed some programming muscle. He knew Reese had just written a similar real-time executive for Honeywell. So, he called up Reese and offered him a part-time job. Funnly enough, this earlier executive was called Sam Tran. No details here. I just love that name. It reminds me of an old friend that used to call my software Sean's World. Anyway, this is where we get to a bit of an odd bridge. By the summer of 69, Breivik and Reese are writing the first version of our

RSX at deck. Now, I don't know exactly how they are able to go from draft design to code. I don't think it was a super official project, though, from Breivik. Development done at night when a PDP 15 might be available in working condition on the production floor. So we fell into a pattern. I design Sam programmed, end quote. They aren't exactly using stolen resources, but they're using. using the next closest thing. What's kind of funny is that the production line process actually limited RSX-15's feature set. The PDP15 had an optional memory management unit.

That could have been pretty slick for a multitasking operating system, but initially RSX didn't really make use of that feature. The reason, well, according to Breivik, quote, hardly anyone bought it, so difficult to find a machine on which to use it, in quote. your software project might not be high priority if you're programming on machines just before they're shipped out to customers. Now, Reveck and Reese worked in this somewhat clandestine manner for a few months and made really good progress.

RSX-15 was shaping up before their eyes. One of the very early decisions going all the way back to the draft proposal was to focus on the real-time niche specifically. this wasn't going to be a general purpose operating system. Rather, it was a software factory for real-time systems. Breivik is also clear that he took good ideas wherever he could get them. His original draft proposal was heavily influenced by that real-time programming workshop he went to. He borrowed the idea of interrupt blocks tied to tasks from Oler,

the online executive for real-time, which was an earlier real-time operating system developed for NASA. One interesting aspect of this early RSX was that it didn't do dynamic memory at all. One of the more complex aspects of most operating systems is memory allocation. That is, how does a program request some memory to use, and how is that memory kept track of? This is crucially important because memory is the bread and butter of a computer program. With multitasking systems, it's also crucial that allocated memory is true. so you don't accidentally give two programs the same chunk of RAM. That can be disastrous.

Early on, Breivik decided to sidestep that complication. Instead of allowing a program to dynamically request more RAM, early RSX used so-called memory partitions. Each program got a partition. There was some fixed size. That was all you got. If a program needed one kilobyte, then, well, you better. have made a one-kilabyte partition and dropped the program into that partition.

If that program suddenly realized it needed a few more bits, well, that's kind of sad, isn't it? The period of isolation ended in early 1970 when Hank Kretchi joined the team. Now, this is a fun part where Breivik is a little vague, from, I will remind you, his outline of a talk, quote, Hank came on board about January 1970. He just showed up at my office led by Martha Siffness. Dan, meet Hank Kretche. Hank, meet Dan Breivik. Hank is going to be our representative.

Bye. We connected instantly, end quote. Now, here's the 10-scent question. Who is Martha Siffness and who does she represent? I know she was a deck employee. My guess is that she was from another department inside deck. this is another little mystery that I don't really want to solve. It wouldn't add a whole lot to the story.

Besides, I kind of love the idea of someone at deck just being like, Hey, Dan, here's my buddy. His name's Hank. Good luck. Kretchi got sucked into the project pretty quickly. He also starts contributing basically immediately. He had just been working on some memory management software, so RSX wasn't stuck with only partitioning for too long. However, to be clear, partitioning still plays a huge role in RSX.

And with that, we have the early team built. Something I want to note here that doesn't really fit anywhere is the nomenclature. RSX borrowed heavily from IBM's term book. That included calling a program a task, regardless of if it's running or not, and calling the core of the operating system a kernel. This has no bearing on the larger story, but it's worth noting because, well, it's a neat fact. This is exactly how terms spread around and become popular.

It takes adoption. In this case, Reese suggested it would make things clear if they used existing terms. By late 1970, RSX-15 is completed. What we get is actually pretty close to Breivik's rough draft. However, I'd like to point out a few salient points of the new system. The first is, well, partitioning. What can I say?

This is weird, so I'm kind of obsessed with it. There are two sides to each partition. Well, kind of, I guess. When you initially set up an RSX-15 system, you create a memory partition table. That includes partitions, just chunks of RAM, where tasks will live, and these things called common blocks that are used for data, between tasks. Think of this as setting up predefined spots for programs to use later. Tasks are a little different than normal programs, or at least RSX tasks have some special

properties that other programs don't. The heart of a task is a binary, the actual program itself. That binary is relocatable, meaning that it can be constructed in such a way that it can run from any location in memory. That usually just means you have no definite addresses, just relative ones. In theory, that also means you could, well, you could throw a task any place in RAM. But RSX adds a restriction. A task specifies which partition it can be loaded into. That means a task can only be slotted into one partition in particular. This is resolved by the partition's name, starting location, and size. A task also contains information about what common blocks it needs access to. Something else to note is that these tasks aren't executed in the usual sense. Rather, they're

installed. That's the word that RSX-15 uses. Once a task is installed, it's not running, but it's ready to run. You can then schedule it to execute at some given time, at some recurring interval or hook it into hardware interrupt events. RSX uses all this extra task information to figure out how to actually load tasks into memory. That's key here. An installed task isn't necessarily in RAM. If a partition isn't available, then the task could be waiting on disk for quite a while. RSX then figures out when and if that task needs to come into RAM and when it gets to execute.

Remember, this isn't really an interactive operating system. It's not meant for a human to sit at a terminal and use. It's meant to reduce a computer into an appliance. In that sense, it's very different from other operating systems. It also means there's not constraints on things like input latency. It doesn't matter if a user would have to wait a few seconds for a program to be loaded into RAM. RSX is smart enough to know when that program will need to be executed and get everything hooked up and ready to go for just the right time.

Now, what about dynamic memory? Well, this is a bit of a technical dive that I want to include here, purely to satisfy myself. This isn't for you, this is for me. Plus, it's kind of funny. So, I mentioned RSX-15 did have the ability to allocate memory outside of partitions. This is done using the deck. It's pronounced deck, but spelled D-E-Q-U-E.

Hardy, har-de-har-ha-ha, very funny and very annoying to read. Alpha name aside, what is this? Well, the deck is how RX-15 handles all its memory that's outside of partitions. When you set up the system, you set aside a region of memory for the deck. It has to be at least a few kilobytes. This is used for two things. Storing internal data used by RSX itself, and for dynamically allocating memory for tasks.

That's pretty normal, all things considered. This is similar to the heap in Java, a pile of memory that's pre-allocated for later use. RSX calls this the pool, so again, similar concept. What makes this interesting to me is how the deck is implemented. It is a circular, doubly linked list.

Here I'm working off RSX-15's reference manual, which is very detailed. I feel like I could use this as a guide to write my own RSX clone. And I'm only partly joking here. It goes all the way down to describing internal data structures, which is why I can tell you so much about the deck.

Okay, so the deck is a very special type of linked list. Each entry in the list, called a node, has a link to the next node and to the previous node in the list. that forms a chain. Each node also has eight words of space. That's to hold data on the chain. That's a pretty classic doubly linked list.

From one node, you can traverse up the list and down the list. What makes the deck a little special is that the chain winds back on itself. The final node in the list points to the first node in the list and vice versa. Think of it as a loop. Once you get to the end, you move forward one more node,

and you're back at the start. As nodes are allocated, they're removed from one list and added to another. In this way, RSX-15 is able to keep track of free and used memory pretty effectively. Now, why did I say I'm personally interested in the deck? Well, I've actually written something almost identical myself. I've written a few really simple hobby operating systems. None of them were ever any good, but they were fun programming projects. At one point, I ended up writing a memory manager that used the same linked list structure as a deck.

So I know a thing or two about shooting this particular ball. Using a linked list for memory allocation is nice because there's very little overhead, at least if you do it right. Your only overhead is the links to each node. The ratio of link to data in the deck is a little high, but it's not that bad. The double link also makes it easy to remove nodes from the list. You only need the address of the node you want to move, and that points to the nodes you need to modify. Adding a node is just as easy.

The downside is determining when you've reached the end of a list. You have to either have a marker that says when you're at the list's head, or keep track of what the address of the first node is. it's a little bit of added complication that you have to consider if the list loops like a deck. I found it's usually easier to not make it loop. Now, I could go on talking about the finer internal details here, but we should keep moving. After all, you probably don't want to listen to me talk about specific data structures and assembly language for an entire hour. RSX starts life on the PDP 15, but that's not its best known home. Its most common version is RSX11 for the PDP 11.

How did it go from the 15 to the 11? Well, there's a bit of a complication. There were actually many versions of RSX11, and I'm not talking about version numbers per se. The better word might be distributions, actually. there was RSX 11A, 11B, 11C, 11D, M plus F, and probably a few more obscure ones. Which came first? Uh, about that.

I think it was 11C. The reason for my belief is Dave Cutler, who worked on 11C, claims it was the first. But there's some ambiguity here. If you check Wikipedia, there's a handy-dandy timeline of RSX, 11 releases, and it groups together A and C, and it cites the release date from a reference manual published in 1973. That's not exactly concrete or clear. It also doesn't help that the letters aren't always in order or sequence.

Deck themselves in the book Digital 1957 to the present doesn't even mention RSX11C. Their timeline shows 11M as the first mention of RSX, which has a release date of 1973. So, what is one to believe? Luckily, I'm going to pull a slight of hand here. A, B, and C are almost the same. The only real differences show up when we get to D and M. So let's just start with the first three. RSX11A, B, and C were small parts of the RSX executive.

These loaded from tape and, like 15, were used to turn a PDP 11 into a real-time computer appliance. Something crucial here is that these lesser RSXs had to have a little outside support. This was also a feature of RSX-15, or perhaps feature isn't the right word. Remember, these aren't interactive operating systems. You had to do any programming in some other environment. For RSX-11s, you had to work under DOS. That's not Microsoft DOS. That's the PDP-11's disk operating system.

You would write code, compile it, and prepare task images all inside DOS. Then you would use special tools to prepare everything for RSX-11 to load. Then, finally, you'd switch over to RSX to actually run tasks in real time. What's interesting is that RSX was actually a contingency, at least somewhat. Cutler explains in an oral history with the Computer History Museum that at the time, around 1971, there was a competing project. This project, called OS-45, was supposed to be a full-on real-time operating system for the PDP11. We're talking multi-user, multitasking, the whole shebang.

A one-stop shop for programming and real-time control. As a side note, why 45? Well, it's because OS-45 was designed to run on the PDP 11 slash 45. The naming convention is very consistent over at deck. Now, this project floundered. It sounds like it was just too big and too ambitious. RSX, on the other hand, is just a little guy. It was much easier to take that to the finish line,

since it wasn't very ambitious at all. Now, I can't tell if any of these PDP11 versions were actually ports, per se. At least, they wouldn't have been ports in the traditional sense. The 15 and the 11 have totally different architectures and even different word sizes. RSX-15 was written in assembly language, so you can't really port that. I believe that RSX-11, A, B, and C were rewritten in PDP-11 assembler, or more realistic, macro-11, which is the macro-assembler for the 11. These new versions were pretty similar to RSX-15, but there are some complications added in. Tasks can now have message cues, for instance.

It's not a huge change, but it is a slight complication. Then we get to 11D. This is where we start to diverge and where RSX15 dies. The timeline here can be a little odd because, well, there's actually two timelines. There's the outward facing timeline which is composed of press releases, manuals, and software distributions. Then there's the interfacing timeline which is composed of memos. That inner timeline is always operating ahead of the outward one.

The RSX-15 hits the scene publicly in 1970. Almost immediately, work starts on RSX 11. In August, 1971, there's a very spicy memo that circulates inside Deck. The company was trying to figure out if RSX-15 should be pushed for industrial control systems. To do so would require some changes to the system. I'm guessing probably for things like compliance, but don't quote me. me on that. I will, however, quote the memo. I believe that the investment required to make RSX-15 an industrial product far exceeds the benefit to the corporation in short-term and

definitely is a bad investment in the long term. The memo continues. All engineering expenses and people should be allocated to the PDP-11 industrial efforts, RSX-11 B, C, and D. They should help speed up those projects to the marketplace, end quote. memo goes into pretty fine detail to back up this decision. Something fascinating to take note of is that in 1971, a total of 22 copies of RSX-15 were sold. So it isn't exactly a hit in the marketplace. I mean, neither was the PDP-15. So energy was directed from the PDP-15 software to new code for the PDP-11. RSX 11, A, B, and C would all appear publicly in 1973, but as early as 72, there was already

work underway for this thing called 11D. This new system was much, much bigger than earlier RSXs. Part of that came down to the simple fact of disk drives. Other versions of RSX had disc drivers. In fact, good old 15 could handle a disc with ease. However, that was all done pretty directly. You could read and write blocks of data to and from disk. RSX11D added support for full-on file systems, with directories and everything.

That increased its size. 11D also greatly expanded the console. In earlier versions, the only user interaction needed was during system startup. A monitor console would come up during initial boot, a user would configure the system, and then once RSX started running, you were no longer required. In fact, you were out of luck if you actually wanted to use the computer yourself. Remember, software factory, that's the whole point of RSX. In 11D, the console would stick around, and I mean that literally.

There is never anything to stop a programmer from hooking up some kind of text interface as a task in RSX. An 11D does just that. It's called the Monitor Console Routine. You can access it by pressing C on any attached teletype. That would raise an interrupt and, after a while, you'd be greeted with a prompt. That means that 11D could be used as a normal operating system. You can actually use your real-time system like another computer. Better still, it was multitasking, multi-user, and even had a compiler.

Instead of developing software on a separate operating system, you could do it inside RSX11 itself. Now, funnily enough, a pamphlet on 11D actually recommends against doing this. I guess their compiler was pretty limited, but still, the capability existed, and that meant that 11D was the largest RSX ever constructed. There were also just some odd choices made with 11D. To quote Dave Cutler, RSX11D had an architecture where basically every single everything ran as a process. And doing that meant the drivers ran as a process, which meant that

there was an IPC, an inter-process communication mechanism that had to exist between the program that wanted the service of a driver and the driver, which wasn't really conductive to the real-time performance we wanted to have, end quote. Why would that matter? Well, in short, IPC, inter-process communication gets complicated when you're multitasking. With priority scheduling, not every task gets the same amount of time to execute in a given period. So imagine this. You have two tasks that need to get some data from a serial port. That requires a call to the serial driver, which, in 11D, is another task. The serial driver task could currently be asleep, as in it's not active.

The first task that wants serial data sends a message to the serial task, which is still asleep, then, let's say, a second task makes a similar request. Sometime later, the serial driver task wakes up. That time is dependent on what else is running inside RSX. The driver wakes up, realizes it has two requests for data, and starts processing those requests and sending the data out. As a task, the serial driver could be interrupted and put to sleep while it's processing those requests. The task that requested serial data could be sleeping for a while before they receive any data,

before they wake up and start processing. That, well, that is quite the task. The point is, that puts you in a position where you don't actually know how long it will take to get your data. That is not very real time of RSX. That said, there are reasons to build drivers this way. This approach of drivers running as tasks is very similar to something called a micro-cernel. That's an operating system design that aims to be small and simple. Making drivers run as tasks means that device drivers are not part of the kernel.

They exist as a separate program. That makes the operating system more resilient to issues in the drivers, and more modular. Micro kernels are actually a very modern design for those two reasons. So 11D may have been a bit ahead of the curve, but that led to practical issues for its intended application. Funnily enough, Cutler was actually trying to stay out of the RSX game in this period. Apparently it tried to bail as early as 71, to quote, When I did B, I said, I'll do B, but I want you to promise me that I don't have to work on this again, end quote. That, uh, that didn't go too well for Cutler.

He would be involved with some of 11D's code around linking and memory management. He saw firsthand as 11D got bigger and bigger and his issues mounted. As the story goes, Cutler thought he could do better. He thought he could make a smaller and more authentic. version of RSX. His proposal was actually taken up by the industrial products group within deck. He was given eight other developers for the project and set to work. In just 18 months, he would return with RSX 11M. One of the huge changes between D and M was, well, huge, D was huge, M was not. By this point, RSX had been written five or so times.

The problem space was very well understood. This is actually a pretty cool position to be in. Cutler had the opportunity to start from scratch and build up a new operating system that worked like RSX, but it didn't need to be completely compatible. In fact, Cutler targeted what he called subset compatibility. This new RSX could do almost everything that D could do, with some exceptions. A program written for 11D could work on 11M with few modifications.

But with how simple RSX actually is, well, that gave Cutler a lot of space to work. As for size, well, his approach was pretty funny. It included a rubber stamp to quote, everybody had a budget about how much memory they could use, and so that was their target. So if somebody came back and said, I can't possibly do that, and whatever the budget was, then we'd rethink that. But generally, everybody met their budget.

And so to reinforce that, I had this rubber stamp that says, size is the goal, and everything was stamped with size is the goal, end quote. You got to love that, right? Cutler is setting a hard line, but giving it some reasonable flexibility and reinforcing it on every sheet of paper use for the project. I can't find anything that's been scanned that has this stamp, sadly. However, I have found the phrase, size is the goal in some source code, for an RSX-11 terminal emulation program, so the phrase was going around inside deck for sure.

11M was completed and released in 1974. The resulting system was just 16 kilobytes of code. That is truly minuscule for what it was capable of doing. Like its direct predecessor, 11M was a fully multitasking and multi-user system. This is something on par with Unix in terms of, complexity, but aimed at a totally different niche. Unix would become the programmer's playground, while 11M was designed to be a tool for industrial systems.

It's fascinating that even in this highly refined form, RSX still feels very low level. 11M's executive reference manual makes it all of eight pages before it starts discussing data structures and system traps. Want to learn how to program for 11M? Well, you better also be ready to learn assembly language, how memory is laid out, and how to write macros. To be fair, the manual is meant for programmers, but still, something that keeps fascinating me is how upfront RSX is with its implementation details. Let's take another text as a comparison here.

The Unix programming environment written by Carringon and Pike. That's the quintessential guide to early Unix. That book is meant for programmers. It doesn't, however, dive straight into internal data structures. It takes a higher level approach, describing components of Unix and how to use the system. It's not until pretty deep into the book that it's explaining things like data structures used for the file system. I think part of this difference comes down to implementation. Unix is famously written in C, a high-level programming language.

RSX is written in assembly language. Funnly enough, both Unix and RSX-11M specifically are distributed as source code early on. For Unix, that leads to this tacit expectation that a Unix programmer or even user knows C. You get a pretty high-level interface for the system, but you still need to know the Lingufranca. Something similar appears to be going on with RSX. It's an assembly language. Tasks will probably also be written in assembly, so you need to know that tongue.

Assembly requires a more deep-down knowledge of the system. You do have system calls that can give you a file descriptor, but that will be handed over as raw data. You'll need to know how to write code to process that table. Hence, you get thrown right into the nitty-gritty. Another piece to this is the fact that RSX is essentially a micro-colonel. Unix is monolithic. What does that mean?

In the case of Unix, the kernel is all-encompassing. It provides every service a program could ever want, from file access to dynamic memory allocation to device drivers and process control. That leads to a large and lumbering system. RSX takes the opposite approach. tasks are largely left to their own devices. There is some code for a dynamic memory allocation and some basic device drivers. This isn't 11D with task-based drivers.

11M does give you a little bit of support. But the programmer is expected to work out everything else. RSX really just gives your task the raw resources that it needs to execute. That's about it. The result is a shift of responsibility. For a task in RSX, you may end up writing more code or using more libraries that end up linked into your program. For a process in Unix, you may end up writing less code, and the libraries you do link

actually just call out to Unix for help. RSX came out of a more restricted design space. Its early goals were very specific. Deck wanted a real-time system for handling data acquisition. That core never went away. In fact, very few frills were added. I think the biggest change between 15 and 11M is just user interactivity. But as I said earlier in the episode, there was nothing stopping you from writing an interactive

shell for RSX-15 back in 1969. All right, that does it for our dive into RSX. What have we learned? Well, first off, Bliss was a red herring. In all the papers and interviews I went through, I saw nothing about Bliss. I don't think the language actually shows up until well into the 1980s. That pattern continues. I assumed RSX would have a similar history to that of Unix.

That was from my external viewpoint. And I was flat out wrong. I was asking the wrong questions. And, well, what can I say? I'm kind of glad, actually. RSX's purpose as a real-time operating system shaped its destiny entirely. Sure, it was made in the same period as Unix and has some outward signs that look similar to Unix. But that's where the similarities end.

This is what I mean when I say I'll never run out of things to talk about on the podcast. Each little nook and cranny has its own story that's wildly different than that of its neighbor. As for RSX, well, it would soon see a major change. New versions would continue to be developed. In fact, 11M would still see new code well into the 80s. But the PDP 11 wouldn't be a top-line machine for that long. In 1977, Deck introduced the Vax, their new 32-bit computer family. That same year, an operating system called VMS was announced for the platform.

one of VMS's lead designers was none other than Dave Cutler. So in that way, RSX set the foundation for a much longer lineage. Thanks for listening to Advent of Computing. I'll keep this short because I'm hungry. I want to go get lunch. You can find links to everything over at advent of computing.com. I'll see you in two weeks' time, and until then, have a great rest of your day.