[Simh] DZ11 vs DZV/DZQ11

[Johnny Billquist]

On 2018-04-12 02:41, Mark Pizzolato wrote:
> On Tuesday, April 10, 2018 at 10:15 AM, Johnny Billquist wrote:
>> On 2018-04-10 10:26, Mark Pizzolato wrote:
>>> On Monday, April 9, 2018 at 11:51 PM, Johnny Billquist wrote:
>>>> On 2018-04-10 00:25, Mark Pizzolato wrote:
> [...]
>>> Some OSes leverage the encoded value to correspond specifically with a
>>> particular model of DEC disk and run from there potentially presuming details
>>> about disk size or geometry.
>>
>> I certainly hope not. Like I said, this is cosmetic. MSCP reports disk size directly,
>> and the id is just for information. Anything that is mad enough to assume size
>> based on the id instead of the size reported by the device would be some
>> seriously broken software.
> 
> Well, most of the third party MSCP controllers provided a constant Media ID that
> identified the drive as an RA81.  In general, since that was really cosmetic it shouldn't
> have mattered.  I vaguely recall that some Ultrix file system generation logic used
> the drive type to determine presumed values for the disk geometry for cylinder
> boundary alignment, but no matter what that choice really didn't matter.

Some definitely allowed you to select it to some degree, and some might 
have been even more clever.

The Ultrix/Unix thingy was ugly in general, and that was back in the day 
when they also had hardcoded partition tables in the device drivers. 
MSCP more or less forced them to abandon that whole design (it would 
probably have been abandoned anyway), because with MSCP this did not 
make sense anyway.

>>> The arbitrary sized disk actually uses the RA82 encoded value for its Media ID.
>>> This is ONLY when the disk is created.  When a disk is subsequently attached,
>>> whatever drive type is either default OR explicitly specified with a SET RQn
>>> RA90 (or one of the many other choices in the list) is what the drive type ends
>>> up as when the media id is passed to the OS.  Current Simh RQ devices autosize
>>> and don't worry about the default size that a particular drive type originally
>>> started as.
>>
>> Like I said, this is cosmetic. It just looks very silly to have a disk reported as
>> being an RA81 (or whatever) when the disk is in fact no such thing. And since
>> the ID can contain any kind of name within the limitations on such names,
>> there isn't really a good reason why it would be limited to such a small set as it
>> currently is.
> 
> DEC controllers only connected DEC drives, so the current simulation behavior
> is consistent with how things worked originally.  I don't recall any third party
> MSCP controllers which let the user tweak what Media ID was reported for
> each drive.

No. DEC controllers could connect to other drives as well, as long as 
they had the same interface. I had a bunch of System Industries SDI 
disks, which connected to UDA50, or HSC, or whatever you happened to 
have around.

And CMD SCSI controllers definitely have some tweaking, however, it is 
that you can either set the ID that all devices report as, or you can 
ask that it's done dynamically, and it will try to match against known 
device ids and capacity, selecting id that are for a disk of a capacity 
that closest match that actual disk capacity.

>> But my point was/is that MSCP was designed to explicitly avoid such
>> silly limitations. An MSCP controller can support any number of disks.
>> The actual UDA50 and KDA50 only had four connectors for disks, which is the
>> reason for that limit. Other controllers could just as well have a different
>> number. From a programming point of view, it would be no difference. That's
>> one of all the nice things about MSCP.
> 
> Absolutely, but the only DEC hardware which supported more than 4 disks
> was HSC stuff and that is not what we're talking about here.

Right in that we're not talking HSC. But HSC is just yet another MSCP 
controller. It works the same way from a host point of view. However, it 
is different than for example an UDA50 in that the transport layer for 
the MSCP packets differs.

>> So we are artificially limiting ourself to four disks because some DEC controllers
>> only had four connectors. The MSCP protocol have no such limit, and neither
>> does the software.
> 
> Right, but we are simulating real hardware that existed.

Except that we choose to not simulate some real hardware that exists.

>> You can without problem generate an RSX system where you have 16 disks
>> on one MSCP controller, if you want to.
> 
> Sure, you could SYSGEN that setup, but you couldn't buy hardware that worked
> that way AND if you could you couldn't afford the electricity needed to run it. :-)

SCSI disks was never big power consumers. A single RP06 would draw more 
than 16 SCSI disks, I think...

>>> As it turns out, in the PDP11 simulator, device RQ has 4 units which start at 0.
>>> Device RQB has 4 units (RQB0, RQB1, RQB2 and RQB3) which have unique
>>> MSCP unit numbers (4, 5, 6 and 7). Device RQC has 4 units (RQC0, RQC1, RQC2
>>> and RQC3) which have unique MSCP unit numbers (8, 9, 10 and 11). Device
>>> RQD has 4 units (RQD0, RQD1, RQD2 and RQD3) which have unique MSCP unit
>>> numbers (12, 13, 14 and 15).
>>>
>>> So, you've already got up to 16 MSCP disks each with unique unit numbers.
>>
>> Right. But there is a difference between having one controller, and having four.
>> In RSX it makes an important difference in that each controller configured
>> takes pool space, of which there is a limited amount. So there is a real, tangible
>> benefit in having more disks on the same controller here.
> 
> Absolutely, but since the 8GB file system size limit FAR exceeds any disks that
> were available when the systems were sold AND you can have 4 of these
> disks on a single controller, you are still way beyond what could have existed
> in real hardware with minimal OS memory impact using a single controller.

Back in the day, yes. Today no. I have real 8GB disks on my real PDP-11/93.

> Meanwhile, getting back to the tangential part of this discussion (unique
> UNIT ID plugs for each drive), the latest RQ code will now allow you to set
> Unit plug values for each drive on the controller.  Unit values can range from
> 0 thru 65534.  The 65534 value was chosen since the MicroVAX 3900 boot
> ROM device scan logic (engaged with >>> SHOW DEVICE) will scan for up to
> 65535 devices (with a Get Unit Status) until the requested answer changes
> the unit number to 0 in the requested MSCP packet.  If the request packet
> value isn't changed the user SHOW DEVICE command never completes.
> 
>       sim> SET RQn UNIT=value
> 
> Default unit plug values are unchanged from how they existed previously
> (0 thru 3 on VAX for each controller, and 0 thru 15 across all controllers on
> PDP11).

Nice. I hope that is also possible with TMSCP.

>>> If you really need more than that you can use up to 8 RP07's and all the other
>>> supported disk types as well.
>>
>> It's not so much about disk size. We can obviously fit more than enough disk
>> space on a simulated system to go far beyond what anyone ever used in real
>> life.
>> However, there are more aspects that can be relevant here, such as my point
>> about memory usage inside the simulated system. Others might have other
>> ideas or reasons...
> 
> My resistance here is about 1) being true to the original hardware we are simulating
> and 2) avoiding changes that affect the internal data structures in ways which
> impact the structure and version compatibility of the simulation code and the
> functionality of parts of the simh framework which either be broken or significantly
> restructured (arbitrarily variable number of units would impact this).

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.

Avoid changes to internal simh structures I can buy. However much I 
think that this means there are issues with the design of the 
structures, we have to live with what we have. And that's the way of life.

>> And the limitation in this case do not seem to make much sense. Just as it
>> don't make much sense that we have a limit of 8 RP07 drives. A
>> PDP-11/70 can have four RH70 controllers, and each one of them could have 8
>> RP07 disks.
> 
> The RP emulation isn't written that way.  Once again feel free to rewrite it in
> your spare time to support all of the potential RH70 controllers...  :-)

One of these days when I suddenly have lots of free time. :-)
I think it's unfortunate that there are so many implied things in simh, 
in the whole design. It would have been nice if it had been more 
flexible and open ended.

   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