[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-request at 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 at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh


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