Doug Jackson - pesonal email <doug at stillhq.com> wrote: People have already convered most of this, and essentially got all the details down. I'll just make a few comments, which relates to several answers. And maybe clarify things in a bit more technical detail. The PDP-11 CPU is a 16-bit machine, so all code will always just deal with 16-bit values. The PDP-11 can have different buses, with different behaviours, but basically we can divide them into three groups. 16-bit bus 18-bit bus 22-bit bus Machines with a simple 16-bit bus is almost nonexistant, but there was some early Q-bus CPUs with a pure 16-bit address range, I seem to remember. 18-bit means all Unibus machines, as well as some Q-bus machines. 22-bit means most Q-bus machines. When the PDP-11 sits on anything but a 16-bit bus, it must use tricks to somehow actually utilize the extra address bits. This is done at several places, and in several ways. The most important component here is the MMU. When you enable the MMU, you can select wether you want 18-bit or 22-bit addressing (assuming you have a 22-bit capable machine). With MMU turned off, addresses are directly physical. The MMU will simply just extend the physical address 160000-177777 to 760000-777777 if we have an 18-bit bus, and 17760000-17777777 of we have a 22-bit bus. If you enable the MMU in 18-bit mode, the MMU will start using the APR registers to relocate your addressing. All your addresses in the PDP-11 will be virtual addresses, which combined with the APR values will form physical addresses. If this is on a 22-bit capable machine, the MMU will now detect if you are addressing physical 760000-777777, and extend those addresses to physical 17760000-17777777, same as when you play in 16-bit mode, except for which physical addresses it remaps. In 22-bit mode, the MMU will use your virtual address in combination with the APR value to create a physical 22-bit address, and be happy. So, to answer another persons comment. A 11/70 can be run in either 18-bit addressing or 22-bit addressing. Also, since a Unibus is always 18-bit, any Unibus device will work fine in an 11/70, even though it has 22-bit addressing (the same is true of the 11/44, 11/24, 11/84 and 11/94, by the way). If the 11/70 is run in 18-bit mode, DMA from Unibus will directly address memory and everything will be just fine. Now, the really tricky part is how to deal with DMA on a Unibus machine, where devices doing DMA only can put out 18-bit addresses, while the MMU is using 22-bit addressing. When 22-bit addressing is enabled, there are two PDP-11 designs. From a normal users point of view, the difference is irrelevant. For OS programmers, it do make a difference, however. 11/70: all DMA addressing will actually be directed to a 124KW area addressed at 17000000-17760000. Notice how this is physically directly before the I/O page. These addresses cannot hold any memory. Instead, this area of memory is virtual, and subjected to a new remapping by the Unibus Map, if enabled. This remapped address in turn, is always on the memory bus. So the Unibus Map is only a mapping between 17000000-17760000 and the memory bus. This also means that on an 11/70, you can access addresses in the I/O page, on the memory bus, but you have to go through the Unibus Map. And this is needed, if you want to access the CSRs of the memory boxes, which don't sit on the Unibus at all. Note that the Unibus Map don't have anything to do with the I/O page addressing. That is done by the MMU as a part of forming the physical address. The MMU will then forward the address to either the memory, Unibus Map, or Unibus, depending on which physical address it is. The Unibus will, however, always forward DMA transfers to the Unibus map, which will convert it into a physical address, and always pass it on to the memory bus. (As a parethesis the RH70 massbus controllers in the 11/70 generate 22-bit addresses straight away, and sends them directly to the memory bus.) 11/84 and 11/94: With the 11/84 and 11/94, DEC removed the concept that the physical addresses 17000000-17760000 are remapped by the Unibus map. Instead they placed the Unibus map between the Unibus and the CPU bus. And all physical addresses on the CPU bus stay physical, and either address memory, or the I/O page. When the access is to the I/O page, the Unibus Map also relays the access back out on the Unibus, so both things on the CPU bus and the Unibus can respond. I haven't checked, but I believe that the 11/24 and 11/44 are a mix of the two above. They reserve the memory area like the 11/70, but the Unibus map works somewhat like the 11/84 and 11/94. But I/O page access don't do through it, and I think that the memory CSRs are visible on the Unibus instead. (Maybe this would be a third variation, but I'm a bit uncertain at this point on exactly how they work.) The only thing remaining are the pure 22-bit machines, which are most Q-bus machines. They don't have a Unibus map. Instead all devices can address the whole memory directly with DMA, and can run as is. This is where the RLV11 and similar devices runs into a small problem. These controllers are actually designed for 18-bit Q-bus machines. But the only thing that happens is that the high address bits are left cleared always when they do DMA, so they can do DMA just fine in 22-bit machines, with the limitation that they can only do DMA to the low 128KW of memory. That's why the bounce buffers are needed for these. Johnny