Doug Jackson - pesonal email <doug at stillhq.com> wrote:
I was reading some doco last night (specifically the DEC RL11/01 Disk
Subsystem Training Handout), and I am confused.
(That is nothing new...)
In the "Subsystem commands section", the addresses specified for DAR and
CSR are 774404, and 774400 respectively, but in the back of the
document, under the 'toggle in programs' section, the DAR and CSR are
shown as being at 174404 and 174400 respectively.
Hmmm. I see three possibilities:
1. I have (re) discovered a documentation error - I wonder if DEC, no,
HP, no Compaq, would be happy for me to submit an amendment :-)
2. The hardware throws away the upper bits so both references are
correct. Hmmm Possibly not :-)
3. There is some other stuff happening that I missed...
If anybody could shed some light on this I would appreciate it. The
background to the problem is that I can not convince my shiny,
wonderful, (and noisy) DL01 to perform the seek test - Me thinks there
is a problem....
People have already convered most of this, and essentially got all the
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.
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.