flash (or ide) storage for unibus 11?

[Paul Koning]

> 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:
>>> 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.
> 
> 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.

> 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