[Simh] Configuration limitations

[Bob Supnik]

SimH's intended purpose was to run historical software in furtherance of
computer education. It was not intended as a perfectly accurate
emulation of every detail of every architecture. There are compromises
in the design to simplify implementation.

One of those, dating back to its progenitor, MIMIC, is the use of PMS
(processor-memory-switch) notation, which simplifies IO into controller
and units. It doesn't really support the notion of nested controllers,
which is what the Massbus actually requires: a Massbus controller (RH)
connected up to a maximum of eight subcontrollers (for an RP06, the
DCL), which is turn connected to one (or for tapes, more than one) unit.

Originally, the Massbus devices were modeled as a controller and units
(the KS10 simulator still does that). That proved unsatisfactory,
because it required extensive code duplication between the VAX and the
PDP11, and between Massbus disks and Massbus tapes. So a while back, the
RH controllers were split out, and a system-specific hack put in place
to associate the "independent" RP controller with a Massbus channel. The
RP controller was not restructured as eight independent controllers with
one unit each. It remained a quasi-standard disk device, with one
controller and eight units. As a result, the RP can only be associated
with a single Massbus channel.

The software changes to get "accuracy" are fairly intrusive.

1. Change the RP to be 'n' separate controllers of one unit each.
2. Change the RH controller to allow a different device for each device ID.
3. Allow each separated controller to be assigned to a MB channel
independently, based on device ID.

Enforcing configuration restrictions (for example, no mixing of disks
and tapes on the same channel) is yet more work.

A simpler hack would be to replicate the RP controller, allowing for up
to 16 drives in two strings. Each string could be associated with a
different MB channel. The 'generalization' of a controller to support
multiple instances is shown in the MSCP disks and in the RH controller
itself.

/Bob

But we are far from being true to the original hardware, so trying to
use that as an argument I think is really weak. Or else we should really
allow me to set CSRs arbitrarily when I have several controllers, allow
me to setup two RP06 on different Massbus channels, and so on. That
would be true to the original hardware. And the same with claiming to
not want to do something because DEC didn't provide it, when obviously
3rd party manufacturers did.

[Johnny Billquist]

Post by Bob Supnik
SimH's intended purpose was to run historical software in furtherance of
computer education. It was not intended as a perfectly accurate
emulation of every detail of every architecture. There are compromises
in the design to simplify implementation.

Yeah. I noticed. :-)
And don't get me wrong. I don't mind simplifications and shortcuts in
places. I'm not trying to blame or point fingers. I'm merely asking that
we try to be pragmatic. So for MSCP, for example, since there is no good
reason to limit the number of disks to four, why do that. Just because
DEC didn't happen to make a controller with more than four connectors?
That would appear to me to be a poor reason for such a limitation.

Post by Bob Supnik
One of those, dating back to its progenitor, MIMIC, is the use of PMS
(processor-memory-switch) notation, which simplifies IO into controller
and units. It doesn't really support the notion of nested controllers,
which is what the Massbus actually requires: a Massbus controller (RH)
connected up to a maximum of eight subcontrollers (for an RP06, the
DCL), which is turn connected to one (or for tapes, more than one) unit.

Right. And even more fun with tapes, who can have slave units...

Post by Bob Supnik
Originally, the Massbus devices were modeled as a controller and units
(the KS10 simulator still does that). That proved unsatisfactory,
because it required extensive code duplication between the VAX and the
PDP11, and between Massbus disks and Massbus tapes. So a while back, the
RH controllers were split out, and a system-specific hack put in place
to associate the "independent" RP controller with a Massbus channel. The
RP controller was not restructured as eight independent controllers with
one unit each. It remained a quasi-standard disk device, with one
controller and eight units. As a result, the RP can only be associated
with a single Massbus channel.
The software changes to get "accuracy" are fairly intrusive.
1. Change the RP to be 'n' separate controllers of one unit each.
2. Change the RH controller to allow a different device for each device ID.
3. Allow each separated controller to be assigned to a MB channel
independently, based on device ID.

Yes. I expect it would be some significant amount of work. In this case,
I think that could be useful, but I'm not going to hold my breath for
this to happen.

Post by Bob Supnik
Enforcing configuration restrictions (for example, no mixing of disks
and tapes on the same channel) is yet more work.

Uh... Which should not be done to start with. From a hardware point of
view it is perfectly legal to mix tapes and disks on the same massbus.
Most OSes did not support that, but RSX-11M-PLUS actually do. It's
called a mixed massbus.

Post by Bob Supnik
A simpler hack would be to replicate the RP controller, allowing for up
to 16 drives in two strings. Each string could be associated with a
different MB channel. The 'generalization' of a controller to support
multiple instances is shown in the MSCP disks and in the RH controller
itself.

Not sure what the point would be though. If you'd redesign devices,
including massbuses, to work the same way as actual hardware, that would
be a good thing. Replacing one specialized solution with a different one
just moves us from one set of restrictions to another.

Actually, nesting devices would be really nice. It would also allow us
to properly do such things as bus adapters, with other bus adapters
inside, and then controllers inside that, such as you actually will find
on VAXens, for example.

But, as noted, this would be a rather big change.

Johnny

Post by Bob Supnik
/Bob

But we are far from being true to the original hardware, so trying to
use that as an argument I think is really weak. Or else we should really
allow me to set CSRs arbitrarily when I have several controllers, allow
me to setup two RP06 on different Massbus channels, and so on. That
would be true to the original hardware. And the same with claiming to
not want to do something because DEC didn't provide it, when obviously
3rd party manufacturers did.

_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Anders Magnusson]

Date: Fri, 13 Apr 2018 02:24:41 +0200

Post by Bob Supnik
Enforcing configuration restrictions (for example, no mixing of disks
and tapes on the same channel) is yet more work.

Uh... Which should not be done to start with. From a hardware point of
view it is perfectly legal to mix tapes and disks on the same massbus.
Most OSes did not support that, but RSX-11M-PLUS actually do. It's
called a mixed massbus.

Similarly for TOPS-20, although Tops-10 does have such a restriction.

Note that the Unix systems never had any problem with this.  In fact, it was
quite common to mix in on VAXen running 4BSD (no reason to get an extra
massbus adapter).

-- Ragge