23 Nov
2015
23 Nov
'15
11:30 a.m.
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.
23 Nov
23 Nov
4:11 p.m.
From: David Bridgham
Sent: Monday, November 23, 2015 11:30 AM
> 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.
Why bother with the RP11? The RP03 gives you a maximum of 40MB (20MW) per disk.
Finally, most likely the RH11 for some Massbus disks
with 22-bit addressing.
Be careful with the RH11 (and other Massbus interfaces): DEC lied in their
published descriptions of the signals. In particular, 2 important ones are
interchanged in the tables.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
4:23 p.m.
On Tue, Nov 24, 2015 at 1:11 PM, Rich Alderson
<RichA at livingcomputermuseum.org> wrote:
I seem to remember Massbus wars, and DEC having a strategy to use IP
to lock out plug-compatible competition... was unpublished or
inaccurate information part of that, I wonder?
Mike
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
From: David Bridgham
Sent: Monday, November 23, 2015 11:30 AM
Because, blinkenlights! :-)
There was an RP11, an RP15, and an... RP10? Lots of blinkelights,
covers 3 of the 4 main architectures.
There IS something neat about retaining enough of the physical side of
things to be recognizable in emulation... having a controller box with
blinkenlights, and ports into which you plug your RP03s... even if the
RP03s are memory sticks and the physical interface is USB...
> 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.
Why bother with the RP11? The RP03 gives you a maximum of 40MB (20MW) per disk. Finally, most
likely the RH11 for some Massbus disks with 22-bit addressing.
Be careful with the RH11 (and other Massbus interfaces): DEC lied in their
published descriptions of the signals. In particular, 2 important ones are
interchanged in the tables.
4:47 p.m.
On 11/23/2015 07:11 PM, Rich Alderson wrote:
Be careful with the RH11 (and other Massbus
interfaces): DEC lied in their
published descriptions of the signals. In particular, 2 important ones are
interchanged in the tables.
Ugh. No doubt I'll learn far more of these sorts of little tidbits than
I wish by the end of the project. When I get to the RH11, I'll try to
remember this and come asking for details.
Thanks,
Dave
11:46 p.m.
On 2015-11-23 20:30, David Bridgham wrote:
22-bit addressing is not possible on the Unibus.
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.
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.
RK11 and RP11, while fairly simple, are also very small devices. Is that
useful for anything beyond it being a fun exercise? Massbus is a bit
more useful, as it at least gives some larger devices, but you need to
implement each device. Each has its own device identity, with its own
geometry, which you need to support. There is some rather non-generic
things around massbus.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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. 
24 Nov
24 Nov
1:01 a.m.
On 11/24/2015 12:46 AM, Johnny Billquist wrote:
On 2015-11-23 20:30, David Bridgham wrote:
22-bit addressing is not possible on the Unibus. 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.
The RH11 has 'paging' on the controller. It can translate between Unibus
addresses and memory addresses.
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. 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.
RK11 and RP11, while fairly simple, are also very small devices. Is
that useful for anything beyond it being a fun exercise? Massbus is a
bit more useful, as it at least gives some larger devices, but you
need to implement each device. Each has its own device identity, with
its own geometry, which you need to support. There is some rather
non-generic things around massbus.
Johnny
Rob.
2:13 a.m.
On 2015-11-24 10:01, Rob Doyle wrote:
On 11/24/2015 12:46 AM, Johnny Billquist wrote:
I don't understand what you mean by that.
The RH11 do DMA, just like all other disk controllers I know of.
The Unibus only have 18 address bits. Thus, it is impossible to do
22-bit addressing for any controller on the Unibus. No matter what the
controller do internally.
Unibus machines with a 22-bit memory address use soemthing called a
Unibus map to translate the 18-bit Unibus address into a 22-bit memory
address when you perform DMA.
The Unibus map is a part of the computer, and the controller on the
Unibus do not even know it exists.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2015-11-23 20:30, David Bridgham wrote:
22-bit addressing is not possible on the Unibus. 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.
The RH11 has 'paging' on the controller. It can translate between Unibus
addresses and memory addresses. 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. 
26 Nov
26 Nov
3:03 a.m.
On 2015-11-26 07:08, tony duell wrote:
The RX11/RXV11 don't do DMA, but the RX211 and RXV21 do, I think
Right. And the RXV21 only have 18-bit addressing for DMA.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The RH11 do DMA, just like all other disk controllers
I know of.
IIRC, the RX11/RX211 (Unibus) and RXV11/RXV21 (Qbus) don't do DMA. 
3:07 a.m.
tony duell wrote:
The RH11 do DMA, just like all other disk controllers I
know of.
IIRC, the RX11/RX211 (Unibus) and RXV11/RXV21 (Qbus) don't do DMA.
24 Nov
24 Nov
7:35 a.m.
On 11/23/15 11:46 PM, Johnny Billquist wrote:
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.
There is no reason you can't have two simulated controllers, one small enough and
early enough to boot a range of operating systems (RL02?), then
another which exports a simple block-level interface which would be simple enough to
easily write drivers against.
RL02 is also interesting because there was a 22 bit version for qbus.
I'm trying to remember if DSD had extended block length or partioning for their
controllers.
2:02 p.m.
On 2015-11-24 16:35, Al Kossow wrote:
On 11/23/15 11:46 PM, Johnny Billquist wrote:
True. But having your system on an RL02 is still no fun. It's a rather
small disk, which cause some headache for larger systems.
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.
There is no reason you can't have two simulated controllers, one small
enough and early enough to boot a range of operating systems (RL02?), then
another which exports a simple block-level interface which would be
simple enough to easily write drivers against. RL02 is also interesting because there was a 22 bit
version for qbus.
That's one definition of "interesting". :-)
I'm trying to remember if DSD had extended block
length or partioning
for their controllers.
Not sure about it, but what I normally observed was that 3rd party
controllers using large disks for some DEC disk usually put several
logical disks on one physical disk. You could call that partitioning.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
25 Nov
25 Nov
8:41 p.m.
Johnny Billquist wrote:
On 2015-11-24
16:35, Al Kossow wrote:
On
11/23/15 11:46 PM, Johnny Billquist wrote:
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.
There is no reason you can't have two simulated controllers, one small
enough and early enough to boot a range of operating systems (RL02?),
then
another which exports a simple block-level interface which would be
simple enough to easily write drivers against. RL02 is also
interesting because there was a 22 bit version for qbus.
That's one definition of "interesting". :-)
I'm trying to remember if DSD had extended
block length or partioning
for their controllers
Not sure about it, but what I normally observed was that 3rd party
controllers using large disks for some DEC disk usually put several
logical disks on one physical disk. You could call that partitioning. 
11:27 p.m.
On Nov 25, 2015, at 10:41 PM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
Confirming that the original DSD 880 only had support for 18 bits DMA. There are only 2
bits
in the CS register for extended addressing. I doubled checked the RT-11 handlers I had.
There was a Unibus controller for the original 7.8Mbyte RL02 reduced drive.
Google 040018-01 DSD 880 Users Manual May81
The Sigma SDC RXV31 controller supported 22 bit DMA.
See 400255-C SDC-RXV31 Floppy Ctrl Man Aug86
I used both, but double sided compatibility between the two products was
occasionally spotty. Never did determine if it was a controller, floppy drive or media
issue.
Johnny Billquist wrote:
??
For example, the DSD 880/30 (from Data Systems Design of course) emulates
3 RL02 disk drives using a single internal (non-removable) hard drive. The box
also holds a single RX03 floppy disk drive (8" floppy disk drive which supports
using single-sided media specified by DEC as an RX02 floppy in addition to
media which have the same physical interface, but which are double-sided).
For a Qbus system, the dual module controller was the interface to both the
three RL02 hard drives and the single RX03 floppy drive. I don't know if
DSD also made a separate controller for the Unibus for the DSD 880/30.
With regard to the address support by the controller for the Qbus, the floppy
drive definitely supported only an 18-bit address. That 18-bit ONLY support
by DSD was identical to the 18-bit support that DEC provided for its Qbus
controller for the RX02, so both DEC and DSD needed a bounce buffer
managed by software to support the RX02 floppy disk for systems with more
than 256 KB of physical memory.
As for DSD support for the RL02 for a 22-bit buffer address, a quick look
at the DSD manual was not able to say one way or the other. However,
it seems more likely the the DSD controller for the RL02 supported ONLY
an 18-bit address. I have all the DSD hardware, but it is not operational
at this point. If anyone else has experience with the DSD controller for
the emulated RL02, let us know if there was 22-bit address support for
its emulated RL02 drive.
Jerome Fine 
24 Nov
24 Nov
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
7:55 a.m.
On 2015-11-24 16:43, Paul Koning wrote:
Thanks. Yes, people do seem to be confused.
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.
Yeah.
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.
Johnny
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: 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. 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. 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.
9:39 a.m.
On Nov 24, 2015, at 10:55 AM, Johnny Billquist <bqt
at Update.UU.SE> wrote:
On 2015-11-24 16:43, Paul Koning wrote:
Oops.
...
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. 
7:55 a.m.
3. The Q-bus comes in 2 (or 3?) flavors, the original
with 18 bit addresses,$
I wouldn't go that far. I would say the MicroVAX-II counts as "in the
Qbus world", and it has hardware to map Qbus memory space accesses to
memory accesses, rather like the Unibus Map you sketch. DMA is "always
to the memory address specified" only if you never look past the Qbus
view of the world; from the CPU's point of view, Qbus DMA addresses get
remapped before hitting memory.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
9:47 a.m.
On 2015-11-24 16:55, Mouse wrote:
Right.
Well, Paul did talk about the PDP-11 and the Qbus in it's "normal" form.
All VAXen (beyond the uVAX I) use the Qbus only as an I/O bus, while
memory sits on PMI. So then we're back to the same thing as with the
Unibus thingy, where DMA have to go through a remapping, since the
system actually have more address bits than the I/O bus.
Johnny
3. The Q-bus
comes in 2 (or 3?) flavors, the original with 18 bit addresses,$
I wouldn't go that far. I would say the MicroVAX-II counts as "in the
Qbus world", and it has hardware to map Qbus memory space accesses to
memory accesses, rather like the Unibus Map you sketch. DMA is "always
to the memory address specified" only if you never look past the Qbus
view of the world; from the CPU's point of view, Qbus DMA addresses get
remapped before hitting memory.
3314
days inactive
3317
days old
19 comments
12 participants
participants (12)
-
aek＠bitsavers.org -
ard＠p850ug1.demon.co.uk -
bqt＠update.uu.se -
dab＠froghouse.org -
jhfinedp3k＠compsys.to -
jsw＠ieee.org -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
radioengr＠gmail.com -
RichA＠LivingComputerMuseum.org -
spacewar＠gmail.com -
tmfdmike＠gmail.com