24 Nov
2015
24 Nov
'15
7:43 a.m.
On Nov 24, 2015, at 2:46 AM, Johnny Billquist <bqt
at update.uu.se> wrote:
On 2015-11-23 20:30, David Bridgham wrote:
22-bit addressing is not possible on the Unibus.
To elaborate, since this seems to be an area where people get confused:
1. Unibus has 18 bit addresses, with the CSR addresses in the top 4k words and the
remaining 128 kW for memory.
2. In 22 bit PDP-11s with a Unibus, there is a Unibus Map between the CPU bus and the
Unibus, which maps Unibus references that ask for memory addresses (i.e., the bottom 31
pages) into 22 bit memory addresses. That allows Unibus DMA to any memory address.
3. The Q-bus comes in 2 (or 3?) flavors, the original with 18 bit addresses, and the Q22
bus with 22 bit addresses. If you have a 22 bit PDP-11 with Q-bus, you have a Q22 bus.
There is nothing analogous to the Unibus Map in the Qbus world; on the QBus, DMA is always
to the memory address specified.
For a
classic/straightforward programming interface, the Massbus disks (RP04 and successors) are
a good choice. That will take you just over 500 MB, if you emulate the layout of the
RP07.
Current thinking (at least my current thinking) is RK11 first then
probably RP11, both optionally extended to support Q22 addresses. Also
something we're calling the RQ11 which will be our "native" interface
with variable sized disks with a 32-bit linear block address giving 2TB
disks for those who are willing and able to write their own device
drivers. Finally, most likely the RH11 for some Massbus disks with
22-bit addressing. After that, I'm thinking to call it good and move on
to other projects though I'm certainly willing to talk to anyone who has
a particular disk controller they want to implement. The RH70, which is the massbus controller for the
11/70 do 22-bit addressing, but it manages that by not sitting on the Unibus.
It feels a bit like Q22 devices, in fact: the buffer memory address is a 22 bit value, not
an 18 bit value.
Your native interface have the additional problem that
in addition to requiring people to write their own device driver for any OS usage, it will
be rather difficult to get booting from it, since that require special support.
Not only that, but depending on the OS, there may be no feasible way to do that driver
work. For example, in RSTS you'd need to write both a boot driver and an OS driver,
both of which requires having the source kit, and none of which is documented anywhere.
paul