flash (or ide) storage for unibus 11?
bqt at update.uu.se
Tue Nov 24 09:55:10 CST 2015
On 2015-11-24 16:43, Paul Koning wrote:
>> 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:
Thanks. Yes, people do seem to be confused.
> 1. Unibus has 18 bit addresses, with the CSR addresses in the top 4k words and the remaining 128 kW for memory.
124 kw, but I would hope that everyone guessed that. :-)
> 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.
Or between the memory bus and the Unibus, if we talk 11/70.
(I wouldn't actually know the proper name for whatever it is on an 11/24
or 11/44, but CPU bus would suffice, I'd say. On the 11/84 and 11/94
it's the PMI bus, which I'm fine with calling the CPU bus here.)
The Unibus map actually covers all 32 address areas, but noone normally
do DMA to the top "page", which would be the I/O page on an 18-bit
system. And it can become even more weird on an 11/70 system, since
there is actually also an I/O space on the memory bus. So better just
use the 31 first mappings, and ignore the 32nd, unless you are looking
to do very specific odd things.
> 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.
I think the orignial original was 16 bits, but you then had the brief
18-bit version before the 22-bit final iteration.
>> 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.
It is actually also a bit weird, since the RH70 presents both the
A16,A17 in the RH11 compatible form, and A16-A21, at the same time, in a
different register which only exists on the RH70.
>> 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.
On RSX, writing devices drivers is well documented. However, if you want
to write a device driver for a device you want to boot from, you need to
modify SAV as well, which is *not* documented, and very non-trivial. Not
recommended for the faint of heart.
More information about the cctech