Advent of Computing - Episode 163 - Ever Heard of the PDP-11?

Episode Date: August 24, 2025

The DEC PDP-11 is one of the most influential minicomputers of all time. Some would even call it the most influential computer of all time. But where exactly did it come from? How was it designed? This episode is the start of a 3 part series that will look at how the PDP-11 was created, adapted to changes, and the strange places it ended up.  

Have you ever been somewhere new and had a strange feeling of familiarity? Like, you've been there a thousand times before, but something's a little off? I have a bit of a recurring experience with this, thanks to a certain grocery store. And I'm not even joking around here, being hyperbolic. The big grocery store in my hometown is called Winco. It's something of an institution in the community. Winko is also a chain. There are stores in, well, Washington, Idaho, Nevada, California, and Oregon, plus some other places that I'm not sure of.

I know my local winco like the back of my hand. If you blindfolded me, I could walk out with a tub of ice cream, no problem. But my winco isn't the only winco. When I'm traveling in a certain region, what I have taken to calling the winco belt, I'll sometimes happen upon one of these stores. and, well, it is an easy place to get a good deal on groceries. That's when the feeling sets in. Every winco is laid out differently, but stocked with the same foods. The signs are all the same, but they're in the wrong places.

Produce and meat shouldn't be that close together. Some even have the same refrigerator and freezer hardware, I swear. Just installed at different angles. My home winco faces north-south, but I've been in some that go east-west. It's uncanny and an oddly visceral experience. I think we've all felt something like this, maybe even in a strange winco in another town. You can get a similar feeling with programming languages, or at least I've experienced something similar. When I've been working in older languages and all of a sudden run across,

something eerily familiar, that's when the feeling sets in. Dope, the lesser-known predecessor of Basic, is one of the places I felt that most strongly. Running face-to-face with line-numbered statements was an odd feeling. But you can see it in other places. Algole's early scope is one spot that tripped me up. Scope is such a basic concept that's so intimately familiar to any programmer. Seeing its earliest form and seeing how similar it looked felt really odd. Or get this, how type generics and typescript follow the same exact syntax as an ada.

Maybe that's more niche, but I hope you get the point. Now, of course, I said this is a similar feeling to walking into the wrong Winko. The key difference here is lineage. All lincos feel similar because they are all the same store, more or less, just in different localities. But languages tend to form lineages. Algal's scope feels oddly familiar because that's where scope comes from. That's where it's invented and popularized.

Later, languages are, at least in part, based off work done on Algoal. It's weird to see line numbers in dope because we're used to seeing that in Basic. But Basic uses line numbers because of dope's earlier work. That's the origin of the feature. The lineage aspect goes even deeper if we go looking. We can run into computers that feel familiar even though we've never used them. There's this machine called the PDP11. Now, personally, I've never used it.

I've never done more than really skim its documentation, but in learning about this computer, I feel like I've known it for decades. Welcome back to advent of computing. I'm your host, Sean Hass, and this is episode 163. Ever heard of the PDP 11? Today, I'm starting on a journey. It's finally time to cover Digital Equipment Corps' PDP 11. It's one of the most popular and most influential mini-computers ever made.

It's the common setting for many a tale of hackery, and it's the unofficial home of Unix for decades. The PDP 11 is a very important machine. It's one of those machines that I've been aware of for years, but I know very little of its history. What very little I do know is almost all technical. But I assure you, it's only fuzzy recollections at best. The first assembly language code I ever saw was for the PDP 11.

When I was a teenager, I got my hands on a macro 11 assembly manual, and I spent a long time marveling at the idea of memory mapped devices. But that's about all I can remember. The PDP 11 is interesting on a technical level because we'd go on to influence a number of the most popular microprocessors of all time. That includes, supposedly, the X-86 family and the Motorola 68,000. The PDP 11 is also crucial as the home for Unix during its adolescence. Unix isn't really Unix without the 11.

Thus, the two have intertwined stories. I know I've probably said this before, but when looking at computers, They often feel like settings to me, since, you know, I'm a software guy, a computer's what runs your stuff. It's where things happen. And the PDP 11 is one of the most common settings during the early period of Unix. We have a huge topic here, but I'm going to expand the scope. My current plan is to run this as a trilogy.

First, we'll be looking at the origins of the PDP 11 itself. But from there, things will get a little funny. at least my plans to make it funny. Deck would later churn out a series of PDP11s on chips. These were known as the LSI 11, the Large Scale Integration 11. In this next episode, we'll be looking at this microification of the classic computer. And finally, to go fully off the rails, I want to spend the third episode in this trilogy looking at some of the strange applications and derivatives that these chips live.

lead to. That's kind of one of the interesting things about the 11 to me, is that its design spans this massive arc all the way into the 1990s. What I want to do is tell this grand tale of how a successful computer is developed, how it adapts to changing technology, and finally the weird destinations that road leads to. Hopefully, we'll laugh, will cry, and get confused about large-scale integration along the way. Today, however, is just the start of that journey, and the start of the PDP-11. We should already be in for a bit of a treat. I haven't been able to find any one definitive history of the PDP-11, so this episode

will be full of oral histories, posts to early forums, sketchy papers, and redacted memos. Prepare. Traditionally speaking, the story of the PDP 11 starts with the failure of the PDPX. And I see no reason to break from tradition. However, I do want to expand that older understanding a little. The PDPX project was started in 1967. It was planned to be Digital Equipment Corps' next computer.

In 1968, after substantial design work, the project was cancelled. A group of disgruntled engineers from the PDPX project left deck and found a data general. There, they would make and sell their own system called the Data General Nova. This is where we enter the traditional tale. For years, it was believed that the Nova was just a recreation of the PDPX at a new company. The PDP 11 was Dex's next major machine, so it was also held by some that the 11 was a rehash of the PDPX, at least in some way. But that's simply not true. Here I'm working off of an article titled, What Was the PDPX by Bob Supnik, a former deckman himself?

Around 2004, a pile of documents from the PDPX project were donated to the Computer History Museum. then made their way online. These documents prove that, architecturally speaking, the Nova and the 11 had almost nothing to do with the PDPX. I'm starting here for two reasons. First, to refute a common claim that the X is the starting point for the PDP 11. But secondly, to highlight a connection, the PDPX project didn't lead directly to the 11, at least not technically. Rather, it set the stage for the development of the newer computer. It got some of the right people into some crucial positions, and it would inform how Deck planned for the PDP 11.

That's something that we'll touch on closer to the end of the episode. One of these crucial people was named Larry McGowan. He was hired to work on the ill-fated PDPX. He would also write about his experience decades later, which gives us a fantastic source for the early days of the 11. According to McGowan, the project started as a mandate from the co-founder of Deck himself. To quote, I was assigned to work for another person to investigate various real and proposed machine architectures to define Dex's future 8-bit machines.

That's what Ken Olson wanted after the PDPX failure. This was the start of the desk calculator project. We like desk calculator because the PDP 10 gurus would leave us alone, since a desk calculator was not very interesting, end quote. The desk calculator project was conceived of as a very small machine. If we just go off bit size, then it would have been tiny compared to the rest of Dex fleet. The PDP 10 was Dex big 36-bit mainframe. Their other machines were all 12 or 18-bit. So 8 was pretty darn small, hence the funny name and hence being left alone.

It's also worth noting that the PDPX itself was a 16-bit design. So desk calculator is already starting off in a different direction. That direction would quickly shift. As McGowan recalls, they decided to move from 8 to 16-bit because that was, was, quote, the way the world was going. This would have been in 1968. So what exactly led to that feeling? Well, it's hard to say.

The biggest computer of the period, the IBM System 360, was 32-bit. But it had really helped to solidify the 8-bit byte. Previously, bite size had fluctuated. You can see that weird bitedness in, X lineup. 12, 18, 36. Those aren't really multiples of eight. But with the 360, it became common to conform to powers of two, making 8, 16, and 32 common data sizes. This was partly because IBM was just such a powerful force in the market. The 360 was big enough that it was able to dictate that design choice for, well, for the rest of time. We don't have a

an exact list of comparative machines that made the desk calculator go 16 bit. But we do have something very close to that. Benchmarking was crucial during the development of the PDP 11 at all stages. One of the earliest documents from the project from early 1969 gives us a list of what the team was benchmarking against. Those comparative computers were the Data General Nova, the PDP8, and some HP-Varian and inter-data machines. Most of those computers, I think only with the exception of the PDP8, were 16-bit. So in that sense, the field was really moving in that direction. As a desk calculator project was ramping up, new staff was brought on.

This included a man named Harold McFarland. This immediately gets interesting, but in a twisty kind of way. Deck was founded in 1960. One of its first employees was an engineer named Gordon Bell. He would work on the PDP 1, PDP 4, and PDP 6. But in 1966, he left the company. So where did Gordon Bell go? He became a professor.

He spent the next six years teaching at Carnegie Mellon University in Pittsburgh. He was in their proto-computer science department, where he taught, amongst other things, computer architecture. He was a good man for the job, too, since he had been on the front lines of developing new machines in the early 60s. McFarland was one of Bell's students. He would work at deck for a summer before getting hired on as part of the desk calculator team.

At this point, design was well underway. Something interesting here is that the PDP 11 was designed in a sort of top-down man. The team at deck started by drafting up the instruction set and the overall architecture and then worked towards the hardware from there. There were two central goals in this design, speed and memory efficiency. I feel like a broken record saying that basically every new computer should promise it uses less memory and spins faster, right?

Well, for the desk calculator, those two goals were intertwined. The thinking, according to McGowan, was that memory access is always slower than the actual speed of your processing circuits. That forms a bottleneck. By limiting memory usage, you can avoid that bottleneck, which lets your software run faster. A big part of limiting memory usage was making your instructions smaller, so you can do more with fewer bytes of code. The reason for that is that the most common thing to load from memory is actually

your program. The computer has to load the next line of your program every step of the way. So that's an easy place to make some gains. This is a very solid place to work from, but initial designs proved, well, problematic.

As I said, benchmarking and comparisons were crucial. During the early stage of development and during later stages. The designs were being shopped around to anyone that may have a good idea. As Bell recalled in an oral history interview with the Smithsonian, quote, the team had put together a machine proposal and then came to Carnegie to have it reviewed by myself and Bill Wolfe,

a fellow professor who eventually became the president of the National Academy of Engineering. We looked at it and said, Yuck! We don't like it. And Harold sort of pulled out another, design from his notebook. It was basically a design that Harold and I had worked on while he was a student. End quote. That design, with a few tweaks, was the PDP 11 that would go into production. So, putting that together, the design of Deck's new computer was made by an ex-deck engineer

and one of his students. How's that for a bit of a strange start? Those designs were taken back, worked over and expanded. The next trick in the process was, in my opinion, pretty darn cool. And this is something that was going on below the surface during the whole design process. They wrote a PDP11 emulator. They wrote an emulator for a machine that didn't exist and then started developing software for the proposed computer. In fact, it is a little more complicated than that

because they already had an emulator for the pre-herald PDP-11 design. So at this point, they're up to two emulators for computers that have yet to exist. Why go to that trouble? Well, it let them actually try out the entire design and test changes to it. Deck had access to a machine faster than the proposed 11, the PDP 10, so they were able to make an emulator that was cycle-accurate. It would run software at the same speed as a real PDP-11, if only one existed. This was then used for that benchmarking.

A series of five benchmark programs were devised. The test programs ranged from string manipulation to multiplying to tabulating histograms. The overall gauntlet was designed to stretch out the circuits and cover a lot of different use cases. The result was that the new design came out on top. That was, of course, after iterations were made. This approach of design, emulate, test, iterate is so modern. It's also powerful. The result is that as the project rolled along, they had a good idea of what they were getting into.

The PDP 11 was a proven design before it was built, because they had made sure the design worked. They had proven the design themselves over and over. over again. This allowed software to be developed at the same time as hardware. While a prototype was being built, programmers could get code up and running. In fact, a symbolic assembler was already written entirely in the PDP11's emulator. That was ready to go before any hardware was up and running. The result was, according to some, the best designed computer ever, at least up to that point. There are many different ways to design a computer.

I've kind of been on an architecture tear recently, so if you've been keeping up with the show, then you've encountered a number of options. We have plenty of ways to differentiate all these designs. We can label them in terms of how they treat memory, their word size, how their math circuits are wired. But one aspect we haven't discussed on the show is the relationship between registers and memory.

In other words, how data moves around a computer. We touched on that a little last episode when we discussed Cizirac, but that's such a unique machine that I don't think we can really carry over a whole lot of that design. Short-term storage can be broken down into two categories, memory and registers. Traditionally, registers live closer to the actual computing circuits of a computer. It's often implemented using the same technology as the machines, logic circuits. A vacuum tube computer will have registers composed of vacuum tubes, for instance. This is where you do your immediate operations, and there are all kinds of things you can

only do in registers. Registers also tend to have the most turnover. It's the most short term of memory. RAM is less tightly coupled to the computer. It's often implemented using different technologies than the rest of the machine. You tend to have a lot of memory. It's accessible over some special bus, and its uses are more limited. But you have a lot of it, so it ends up being very important for computations. It also turns over slightly less often than registers. A neat secret that software developers don't want you to know is almost all of our code is just moving bits around in memory and in and out of registers. So how the machine connects those two stores of data is crucially important.

because that's what the computer is doing almost all of the time. One of the most venerable solutions to this problem and the most simplistic design is the so-called load store architecture. From the perspective of a programmer, this kind of machine only has one way to move data between a register and memory, the load and the store instruction. For once, this is actually a computer science concept that is very clearly named. The load instruction will load data from a location and memory into a register. Store does the opposite, storing data from a register into a location and memory. Crucially, many early load store computers only have a single register.

So, load just loads that one register, and store stores that one register. This makes the instruction set, the full scope of what, a computer can do, pretty simple. Load and store always take a single argument, which is always a memory address, and they always point at the same register. So, no need to specify that. For machines with multiple registers, you'll often see multiple load store instructions. For instance, the MOS 6502 has an X and a Y register. So it has a load X and a load Y instruction paired with a store X and store Y instruction. The rest of the instruction set follows that same pattern, an operation with a single argument.

That tends to be simple to implement. You can take the LGP30, my constant comparison as the perfect example. Each instruction, when you break it down to binary, follows the same format. That is really easy to decode, easy to encode, it's easy to slice, and also dice. To put this all as simply as possible, it's easy to make a load store computer, but the computer isn't necessarily the easiest to program. It's one of those balancing acts. You get more simple circuits in exchange for more complex software. That means that in theory, your software uses more memory, uses more instructions than it

could on a different type of computer. The simplicity of load store starts to break down as you add more registers. You need to have a load and store instruction for each register. With one register, that's two instructions. But with two, that becomes four. If you have six registers, you need 12, and it snowballs from there. The issue here is that registers are useful. The more registers you have, the more breathing room your programmers have to work with.

There's another force to balance here, and that's that you want to try and limit the number of operations your computer has to handle. Each operation has to be encoded as an operation code, an op code. That's just a number. But here's the issue. Each instruction, every command you issue to the computer, that has to have an op code and some argument. That all gets encoded as one big number. That number is stored in memory. When the computer goes to execute an instruction, it has to load that number from memory and figure out what it means. It has to decode the instruction, figure out what you're asking for. That process is faster when that number fits into a single byte or word or whatever size the computer is built to work with. If your

op code is too big, it can start eating into the space of your arguments. or it can force you to use a larger instruction size. That will, in turn, slow down the computer and make it more complex. All of this together means that Load Store is very useful, but only for simple machines, and only for smaller machines, really. As a computer becomes more complex, Load Store becomes more complicated. It becomes a hindrance. The PDP 11, on the other hand, offers an alternative that becomes pretty popular.

That's the register memory architecture. The key difference here is that instead of separate load and store operations and a set of those operations for each register, the PDP 11 just has one way to move data, and it can move data in any combination you want. The operation here is called move. It's usually just rendered as MOV. The move instruction is kind of like a superpowered load store. It takes two arguments, a source and a destination.

It moves the value of the source to, well, the destination. That's it. From the programmer's point of view, this is an immediate simplification. You don't need to load a value from memory into a register. You use move. If you want to store a register's value in memory, you move it. If you want to store the value of one register in another, you won't believe it. you move. You can even move the value of one location in memory into another location in memory

without first pulling it into a register and then storing it in a new address. On the surface, move is just replacing load and store with a single instruction. But going deeper, we get more features like register to register moves or memory to memory moves. That leads to some immediate gains. Take moving memory to memory to memory. as an example. Let's say you want to move an entire chunk of data from one region of RAM to another. In a pure load store machine, every byte of memory has to be loaded into a register and then store from that register back into memory. You also have to somehow manage a counter and track where things need to go. That ties up at least one register during the whole load

store dance. It sucks. It actually turns into kind of complicated code. With move, you just move. You don't have to use registers as intermediary storage. You can move memory directly from one address to another. We touched on a similar phenomenon during the Cizirac episode. What we're looking at isn't just slightly different software, but two fundamentally different approaches to programming. A load store and a register memory computer offer very different possibilities.

That will lead to different possibilities. code. In some cases, like this memory transfer example, a register memory computer will simply be more efficient and use a software to do the same task. So in the general case, this is an interesting discussion, but specifically when we're looking at the PDP 11, I think this is all the more interesting. The design of the 11 would shift radically during development. We'd see major changes all the way into 1969. Here, I'm working off a set of deck internal memos that were preserved at BitSavers. We know that the pivot point was pretty abrupt, but it's wild to see it happen in real time. So get this. In early 1969, around February, the PDP 11 was still

a load store computer. That was the original design, the one that Gordon Bell said yuck to. By the end of March, it's this new register memory thing. You can watch as the memos are working to refine the Load Store 11. And then on March 28th, we get a memo with the totally new design, and Load Store is gone for good. So why the switch? In short, moving to Register Memory architecture met design goals better than trying to soup up their earlier load store design. Move simplified things considerably. It meant you could do more with less code,

that you could use new methods to accomplish old tasks. It was a winner in that regard. That same design of move is seen in every operation on the PDP 11 that deals with memory. Add also allows you to specify any source and any destination. But it wasn't just as simple as adding move and moving on. The switch was backed up by a few other key features. One of those was the concept of a truly general-purpose register. The PDP 11 has eight registers, and they're all general purpose.

They're internally numbered zero through seven, and you can actually address them that way in your code if you want. Now, there are, of course, some special purposes for these registers. One register is an instruction pointer, one is a stack pointer. but those are just special uses. Those are applied above all the general circuitry that goes into each register. What does this mumbo-jumbo mean? Well, to put it simply, every register is wired into all of the PDP 11's math and logic circuits.

Any register is a valid source or destination for move or add or whatever you want to use. You can add or subtract any register from any other, for instance. This is in contrast to earlier machines and even to very early PDP 11 designs. It was common to assign each register some special purpose. You have an accumulator, and that's for doing math, and that's the only place that you can do math, because it's the only part of the computer connected to its math circuits. You have index registers that can be used to store memory addresses,

but you can't do math there, and you also can't index with the accumulator. Those are hooked into physically different parts of the computer. That older regime is simple. It's easier to build, but it's rigid. It leads to a very small set of possible programs. Whereas the openness of general purpose registers, well, that means you can do all sorts of wild and crazy things.

That, again, helped the PDP 11 do more with, less. How this is all done is actually pretty ingenious. This is going to be a little technical, so feel free to tune out for the next few minutes. So, each instruction has to be encoded as a set of numbers, right? That includes operation code and its arguments. On the 11, that could get a little hairy, since every instruction can accept all these different arguments. It's not just move, again. This is handled by making every argument follow the same format. It's a few bits for a mode and a few bits to select a register. You have eight registers, so you only need two bits there.

Then the rest of the bits are used to select an access mode. That's how you tell the computer that you're accessing the register itself, or an address that the register points to, or a number of other cool options. The result, besides slick code, is that the PDP11's instruction set is highly orthogonal. If you're a long-time listener, you've probably heard that word before. It's one of my favorites. It's a term used initially to describe programming languages. Well, actually, it's a math term, but it was adopted to describe programming languages in the 60s.

For a language to be orthogonal, all its operations need. need to work on all of its data types. The actual definition is much more mathematical, but this will function for today. Think of an addition operation. In an orthogonal language, that operation would have some defined behavior for every possible input.

You could use the plus sign on floating point numbers, integers, strings, everything. The defined outcome may be an error, but that would still be a defined outcome. This means that if you learn the rudiments of the language, you can piece everything else together. The overall language follows this self-consistent logic. You may not know that you can multiply two floating point numbers, but you know you can subtract integers, so you figure multiplication will work the same way.

What does that mean when it comes to a computer? Well, basically the same thing, that every operation can work with every kind of data the machine has access to. You can move a value from any type of storage to any other type of storage. The same goes for any instruction. If you know that you can move anything you want, it's easy to figure out that you can also add anything, or even compare anything. This design approach is very deliberate.

For one, this is super nice for the programmer. The instruction set is pretty slick and very logical. Plus, you can do more with less code. That part is one of the core benefits here, and everything revolves around it. Memory in this period is very expensive, so if your code can do more with less memory, well, then that's good code. That saves money. The actual bus, the connection between a processor and memory, tends to be slow.

That's the bottleneck we talked about earlier. So less code means less data has to be loaded from memory. so the machine can go faster. The other factor here comes as we move away from machine code. The PDP 11's instruction set has a lot of handy support for the features of higher-level languages. One example of this is how the 11 handles character data. This is technically a 16-bit machine, but it has a trick.

You can break each 16-bit number down into two 8-bit numbers. That's important because, according to the ASCII standard, which was very new at the time, characters were now encoded in 8 bits. The 11 had a set of instructions for both 16 and 8-bit operations. Those 8-bit operations were a boom to text processing programs, like compilers. This all sounds great, right? I can actually say that this is a fantastic environment for programmers. The Intel X-86 family, which I've written a lot of assembly language for, is based very

heavily off the PDP-11. As I've been reading through old docs, I've actually been realizing just how similar these machines are. If anything, X-86 is just a weaker rendition of the PDP-11. So, yeah, I'm speaking with derived experience here, but the 11 would have been a treat to program. Now, we actually have a specific name for this type of machine. The PDP 11 is what's known as a complex instruction set computer, aka SISC. Now, this is another one of those anachronisms.

Deck didn't call the PDP 11 a SISC machine, neither would anyone in the era. That's become a retroactive label as RISC, reduced instruction set computers have become a thing. Risk is a whole topic onto itself. I only bring this up because the PDP 11 is often used as a prime example of complex instruction set computer design. The distinction here comes down to how the 11 does a lot of things during each instruction. Move, again, is the perfect example. When you ask the PDP 11 to move data from one address in memory to another, it has to make a number

of transfers. It actually negotiates a series of steps, even though you... you only gave it one instruction. That's SISC. The result is you write less code and use less memory, but the computer itself is more complex. This gets even more complicated when you realize that the pre-herald PDP 11

would have actually been more like a risk machine, but let's not go there. Let's not think about that possible twist of history. The fact of the matter is that the PDP 11 project was transformed in March of 16. But that transformation wasn't total. There were some parts of the load store design that stuck around. One of those remnants is called the Unibus.

We can see this bus in a primordial state as early as January of 69. So, what exactly is the Unibus? Put simply, it's one bus to rule them all. Jokes aside, if the register memory machine is the brain, of the PDP 11, the unibus is its spine. What makes the unibus so special is that it's used for both internal and external communications. This one bus is used to connect the processor to RAM, but also out to things like disk drives and display units. And I'm not entirely sure exactly where it came from. So, dig this. In a 2005 oral history, Gorty

Gordon Bell has the following to say, quote, I had two big ideas. The other one was the unibus, and the unibus was extending the bus even further so that you have everything on a single bus, and that was, by the way, invented at Carnegie, end quote. That's pretty clear, right? The unibus was designed at Carnegie Mellon by C. Gordon Bell. But let me mess things up. We have a have an internal deck memo from January of 69 that describes something very similar to Unibus. The memo states, and I quote, the PDP11 IO bus is composed of 30 bidirectional signals. It is used for all communications and data transfers between system units. Program control, program transfer, direct memory transfer, interrupt, and priority determination are all done

via these 30 signals, end quote. In layman's terms, it's a bus that's used for everything, both internal and external. Now, the final unibus used a lot more than 30 wires, but the bones are here. A lot of the names on the pins of this early bus even line up with the final unibus.

So what's the deal? This report was written by one Roger Caddy. Now, this is where we get into murky territory. Caddy at this point was managing the PDP 11 project, so many of these memos are either from his desk or went across it. There's also a certain amount of bleed over between Bell's work at CMU and what was going on inside deck, so much so that when the PDP 11 was introduced in 1970, Bell is the first author on a major paper that describes its architecture. The second author is Roger Caddy.

So was Unibus a deck idea that was championed by Bell? Or was it a Bell idea that was adopted by deck? I do not have a good answer. Either way, it's the final piece that ties the PDP 11 together, literally. As I said, the unibus was both an internal and external-facing bus. For the time, that was a wild idea. It's normal for computers to have buses. That's how data physically travels from component to component.

It's more common to have multiple types of buses in a machine. You can usually spot buses for memory, for external data transfer, and even between registers and other deeper circuits. What made the unibus radical was that it exposed that internal bus to the outside world. If you wanted to hook up a tape drive to your 11, you had to do that via the unibus. that very same bus connected memory and even the processor itself together. And the unibus is an active thing. It's not just a pile of wires you hook into.

Rather, signals are sent as packets, and there's negotiations involved. A bus master manages who gets to talk when. This has some wacky implications. First of all, the processor actually has to talk over the bus to access memory. When you move data around, you're actually sending and receiving packets. But that's not the main point of the unibus. Where this really shines is when you connect up external devices. Let's say you have a tape drive.

Well, a tape drive is just a form of data, right? It's just data storage. So knowing what you do about the PDP 11, how would you expect that to work? Well, the 11 is a highly orthogonal machine after all, and data is just data after all, so it would only make sense if that data could be accessed the same as any other data. And that's approximately true. The PDP11 uses a technique called MemoryMapped I.O, and it's all possible because of how the unibus works. Basically, each device on the unibus can hook into a section of memory.

you can then read data directly from that device as if it were just another piece of memory. You even get to use move. Now, there are some more complications here. You usually end up with interrupts or something fancy, but at the end of the day, you're still using move to move data. Because really, a tape drive is just another place for data to live.

The effect of the unibus was that it was very easy to add new devices to the PDP 11. But more than that, the Unibus as a concept just jives so well with the rest of the 11's design. That's why it's so wild that the bus was designed and ready to go during the early days of the project. It just happened that the revamped Register Memory 11 worked perfectly with this earlier bus design. So we have this really cool computer. The next question is, how did the 11 do? once it came to market.

Was the 11 a marvel of design that was overlooked or misunderstood? I think we already know the answer to that question, right? A high-speed, bidirectional data path called a Unibus said to be immune to technological obsolescence is a main feature of the PDP 11 family of small 16-bit computers announced by Digital Equipment Corp, last week, end quote. That's the earliest article about the PDP 11 that I can find in computer world.

It came out in January 14th of 1970. It actually gives us some good detail on the new machine. It was 16-bit. There were two models with more planned in the larger PDP-11 family. It came at a reasonable cost, and, oddly enough, that it featured this new Unibus technology. The unibus actually takes center stage in early press. The spin is that the PDP 11 will never be obsolete as long as deck has the unibus on its side.

The Computer World article actually quotes one of the PDP 11's designers saying, quote, advances in technology will not affect the PDP 11. That's bold. The messaging carries over into ads for the new machine. An April print ad says the PDP 11 is, quote, the best small computer ever made, far none. It continues, PDP 11 is more than a new computer.

It's a new idea in computers. Its secret is an architecture which makes it more powerful than any other 16-bit computer. Everything is attached to a single high-speed, asynchronous unibus, are, the processor, the memory, the peripherals, everything! end quote. So, to start with, the PDP 11 is really being sold on the back of the unibus.

This new bus is future-proof. It makes swapping out components easy, and that will make the PDP-11 the eternal computer of the future. It's almost like Deck is selling the bus, and the computer is a secondary thing. What's interesting is that, in part, this is kind of true. Dex's marketing department is correct. The 11 is more than a new computer. Unibus is a pretty radical new idea.

Other machines were still using multiple types of buses and custom buses for everything. Unifying that down into one bus and making it both internal and external was a stroke of genius. It did make it possible to switch out components at will. It would change the face of computing. We end up seeing echoes of this in the last

half of the 70s. When the Altair 8800 hits the scene, it's built around this thing that is later called the S-100 bus. It's not nearly as complex or cool as Unibus. It really is just 100 wires and a power supply, but it still fills the same purpose. The Altair is a computer composed of a number of cards plugged into that bus, the same as the PDP-11. The S-100 Bus ends up outliving the Altair computer because it is, in part, in a weird way, future-proof. Companies and hobbyists started churning out all kinds of boards, including whole new processors. By the end of the 80s, you could still build an S-100 computer with everything from an Intel 80-80 up to a Motorola 68,000. You could run Unix quite literally and quite comfortably on a computer that would,

was constructed in the same way as the Altair 8800. But the unibus is a little different. Here, Deck isn't talking about establishing a standard that will live for the next million years. Instead, they're saying that with Unibus, you can always get a top-of-the-line PDP-11, supplied by Deck, at a reasonable fee. The 11 was, from the jump, modular. It's really just a unibus with an optional processor and memory card. The reason for that was simple.

Deck had always planned the 11 to be a family of computers, very similar to what IBM did with the System 360 machines. This was decided on all the way back with the PDPX. That cursed machine was planned to turn into a family of cursed machines. You could get a baseline PDPX with, one feature set, and then get more features and more power as you moved up to more expensive models in the family. The PDP 11, however, formed more of a true family of machines. Any PDP 11 could run software from any other PDP 11. What you get as you moved up was more memory and more processing

power, and often new processing technology. As such, the 11 was actually announced as a duo of machines. The 1110 and 1120. That's 11-slash-10 and 11-slash-20. The model names around the 11 have always confused me. The part of that comes down to, I think, the timeline of announcements first release and the real slash-canceled-slash-renamed models. So, get this. In January 1970, we're told the 11-10 and 11-20 are coming. That year, only the 1120 would ship. So, what's the difference between the models? The 1120 is the full machine.

You could order different configurations from deck, but memory started at 4 kilobytes. We're also finally in the era of the 8-bit byte, so we actually do mean 4 kilobytes here, just normal kilobytes, nothing weird. In 71 and 72, a number of other models would ship. The first is probably the 1115, which was sold to OEMs, and probably made its way into controller logic for machinery and that sort of thing. It was, from what I can tell,

basically the same as the 1120. Models really start to show some change in the next few years. The 1110, for instance, when it comes out, replaces discrete logic with microcode, which makes it smaller and cheaper. The 1145 adds a faster processor and has optional floating point cards. But all these models can still run the same code. They can do the same things just in different physical ways and at different speeds. This is all possible because of the unibus. That's why the claim that the PDP 11 was immune to technical obsolescence. Well, it's not that crazy. The machine is built for that. What ties it all together is how well the PDP11's overall architecture really fits the unibus. The orthogonality of it all, as pretentious as that sounds, just worked really well

when combined with the universe. The bus was only part of the message here, though. The PDP 11 was also sold as a small computer, so how did it stack up? Well, I'd like to start with price, but That gets tricky. The original base model, the 1120, was announced at $10,800. That inflates up to, get this, just under $100,000 in 2025. Now, what do we compare that to? My snap judgment was to look at the data general Nova. That is, after all, another child of the PDPX, at least in a roundabout way, the same way

that the 11 and the X are related. But there's an issue there. The Nova was advertised as, get this, the best small computer in the world. The Nova came out before the 11, so I'm pretty sure Deck was just poking fun at that in their own ads. A baseline Nova sold for just $4,000.

That's a much better deal than the PDP 11, right? Well, not so fast. The two aren't exactly comparable. That's a NOVA with just one kilobyte of memory. The NOVA was a load store machine with a few extra niceties. It actually does have an instruction called Move, but only for register-to-register transfers. It was positioned as a competitor to the PDP 8, which was a smaller machine. But luckily, we have some internal comparisons we can go off.

Recall all the benchmarking. the deck was doing? That gives us something of a touchstone here. One comparison was often made to the HP 2100 series, which was about the same size as the 1120. A 4-kilobite 2100 clocked in at $22,000, or twice as much as the 11. But even then, comparisons are kind of hard to make. The PDP 11 is just a very different computer. This is a period when that's still possible. Things like Instruction Set and Bus are actually differentiating factors. You don't just buy a computer based off rough size, but based on actual features set and instructions.

You actually care about the architecture. Richard Seltzer, a deck engineer, explained the early days of the 11 like this in an article from Deck World, quote, in those early days, engineers frequently went along to help on sales calls. Quote, some customers thought the PDP 1120 was slow because the instruction cycle time was slow, said Tom Stockbrand, an engineer or communications, quote, but the instructions were powerful enough that you needed lots fewer of them. You had to teach that to customers, end quote. The machine didn't fit into an understood mold. It was different enough that engineers had to, in some cases, help explain the machine during sales calls.

That kind of thing only happens when you're dealing with something very new. This difference made the PDP 11 stand out. It became something of a phenomenon. Julius Marcus, a marketer for the PDP 11 project, said this about sales. We thought 10,000 PDP 1120 handbooks would take care of us forever. In just two or three years, we distributed 300,000, end quote. It's an understatement to say the machine sold like hotcakes. The PDP 11 was killer in the market.

It took four days to sell 150 PDP 11s. That's four days after the initial announcement. Sales were also coming in batches. Customers would order 10 or even 100 machines at once. orders hit a million dollars by March. The effects were immediate. By February, Dex's earnings were up 72%. The planning, pivoting, and plotting had really paid off.

And this is a bit of an unusual place for us to land, right? We tend to talk about misunderstood or failed machines here on Avern of Computing. I prefer to shy away from the hits. But the PDP 11, that was a hit. It wasn't even a case of a paltry launch followed by incremental improvement and eventual acceptance by the market. Deck hit hard, they did very, very well for themselves, and they kind of won out. And remember, this thing is coming out with software ready to roll.

Because of extensive simulation work, there was already software. First party software released for the PDP 11. Better still, third party software was showing up as early as 1970. That's a sign of a very healthy and fast-moving ecosystem. Where does the 11 go from here? Well, it adapts. It's the machine that's immune to obsolescence after all. All right.

That is the start of our journey into the wild world of the PDP 11. I don't want to linger here too long because we're only at the beginning. Next time, we're going to see how the PDP 11 adapts to the world adapts to the biggest change in computing since sliced bread. That is, of course, the microprocessor. Thanks so much for listening to Avignon of Computing. Again, I'm just going to keep this short. You can find links to everything at advent ofcom.

I have some bonus episodes out on Patreon. I just posted a recording of my VCF West talk on the LGP30 over there. So if you want to get that, go to advent ofcomputing.com and find the link to my page Patreon within. And as always, have a great rest of your day.