On Nov 23, 2015, at 1:00 PM, Johnny Billquist
<bqt at Update.UU.SE> wrote:
On 2015-11-23 18:17, Guy Sotomayor wrote:
On 11/23/15 9:11 AM, Paul Koning wrote:
> On Nov 23, 2015, at 10:10 AM, David Bridgham
<dab at froghouse.org> wrote:
>
> ...
> However, once we get a prototype doing something interesting, we were
> talking about looking around for people interested in helping out.
> We'll do a couple disk controllers but if someone wants to add others,
> great. Especially if someone wants to add MSCP. We're happy to skip
> that one ourselves.
I can imagine. MSCP is a large effort.
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.
That's per-drive. Massbus allows for 8 drives per controller.
Right. But then you also need to remember that there are some slight differences between
different type of disks, meaning that in DEC parlance, if you have both an RP06 and an
RP07 (for example) on the same massbus, it's called a mixed massbus, which not all
OSes supported.
As far as I can tell, disks fall into two groups, as far as massbus control is concerned.
The RM02, RM03, RM05, RM80 and RP07 is one group.
The RP04, RP05, RP06 is another. A few register addresses between the groups are the
same, but the actual register at that address is different. But if I remember right,
it's registers that have to do with error recovery, so potentially not something
people would care about in emulation anyway. But it still means there are different
drivers in the OS for them.
That sounds right.
RSTS/E supports mixed massbus, and supports RP07. At least in the sense of "it
definitely works". I don't think it shows up as supported in the documentation,
because as far as I remember the RP07 was not actually ever sold as a PDP11 option. But
it works just fine on a fast Massbus (one capable of supporting an RM03 rather than just
an RM02). In the RSTS/E development group, there was an RP07 which I think was used to
hold all the .LST files produced during system build.