Re: [Simh] Configuration limitations

[Anders Magnusson]

Den 2018-04-13 kl. 21:55, skrev Rich Alderson:

From: Johnny Billquist 
Date: Fri, 13 Apr 2018 02:24:41 +0200
On 2018-04-12 23:49, Bob Supnik wrote:

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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuration limitations

[Rich Alderson]

> From: Johnny Billquist 
> Date: Fri, 13 Apr 2018 02:24:41 +0200

> On 2018-04-12 23:49, Bob Supnik wrote:

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

Rich
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Configuration limitations

[Johnny Billquist]

On 2018-04-12 23:49, Bob Supnik wrote:
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.


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

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.


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.


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



/Bob

On 4/12/2018 4:34 PM, simh-requ...@trailing-edge.com wrote:

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh



--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[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

On 4/12/2018 4:34 PM, simh-requ...@trailing-edge.com wrote:

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
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh