I may be jumping in the middle of something here all out of tune, but I can help
explain the comment about hardware versus software addressing.

Hardware addresses have always been above 160000 octal, no matter whether you
are using a 16-bit, 18-bit, or 22-bit addressing  processor on the Q-Bus.  If
you access above 160000 on a 16-bit processor, you get hardware because 16-bit
processors don't know about any memory  above 124kbytes.

On an 18- or 22-bit addressing processor, if you access above 160000 in kernel
or supervisor mode, you get a memory address because it knows about memory
management.  To get hardware you have to add 600000 for 18 bit and 1760000 for
22-bit.  If you access above 160000 in user mode (if MMU allows you) you will
get hardware, i.e. a CSR address.

This magic is all done by courtesy of a little signal called BBS7 on the Q-bus,
which is just anded with bits 15,14,and 13 on 16-bit processors and is
controlled by the MMU.

In other words, no piece of hardware actually fully decodes the 22 bits of
addressing that the Qbus on the VAX provides.  The VAX processor puts out BBS7
whenever it decides that the context requires a hardware address.  Then the
hardware device decodes the lower 16 bits.

The buffer address register in a DMA (or NPR as DEC calls it) transfer is an
entirely different kettle of fish. It is accessed itself by the above means, but
when you transfer data to it the bit positions can be anywhere that the board
manufacturer wishes.  Yes, the actual register that auto-increements during a
DMA transfer is the right number of bits for the bus, but you load it as data in
whatever manner the mfr decided, so your example below is, just that... an
example and not a paradigm for all implementations.  Usually you could load the
bottom sixteen bits in one transfer (big endian) and the leftover bits were
loaded into a register at another hardware address.

BTW the price of tea in Canada is five bucks a quarter!   :-)

Hope it helps,
Nigel Johnson




Andrew Phillips wrote:

> Hi,
>
> >However, for whatever reason, the most significant word of a longword
> >was stored first in memory; I don't remember if that was a software
> >convention, or a hardware thing.
>
>     Funnily enough, I happen to have the RSX-11M 4.1 vol 5
>     i/o drivers development and ref manual on my desk. (Nov 1981)
>
>     A rather superficial skim of this yields,
>
>     Appendix A (development of the address double word) says;
>
>     "The addressing in a mapped system uses virtual addresses
>     and memory mapping hardware. I/O transfers, however, use
>     physical addresses 18 bits in length. Since a PDP word size
>     is 16 bits, some scheme is needed to represent an address
>     internally...
>
>      Section 4.1.4.1 (4-32) says
>      For NPR device drivers the layout is as follows.
>
>      Word 1
>       bit  0    Go bit
>       bits 1-2  function code
>       bits 4-5  Memory extension bits
>       bits 6    interrupt enable
>       bits 7-15 MBZ
>
>      Word 2
>       bits 0-15 The lower 16 bits of the address.
>
>      So, i/o hardware. Probably what happened is that they stuffed
>      the extra 2 address bits into the "setup word" that preceded it,
>      as a wild guess.
>
>      Don't know if that has anything to do with the price of tea in
>      china, but hope it helps :-).
>
>                 Andy
>
> --
> atp@nojunk-mssl.ucl.ac.uk             |        Dr. Andy Phillips
> phillips@nojnk-isass1.solar.isas.ac.jp| Mullard Space Science Laboratory
> a.phillips@nojunk-ucl.ac.uk           | "It's the late 1990s, This is a spam
> atp@nojunk-coralcay.demon.co.uk       | protected .sig. You know what to do"