[Simh] DZ11 vs DZV/DZQ11

[Mark Pizzolato]

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:
[...]
> >>>>>> And exactly
> >>>>>> how many units/lines the controller have should also be a factor
> >>>>>> here then.
> >>>>>>
> >>>>>> This also comes back to disks, where I might not want to
> >>>>>> configure four disks on one controller, but maybe one controller per
> >>>>>>  disk.
> >>>>>
> >>>>> The device simulation for DEC's disk controllers usually default
> >>>>> to the maximum number of disk devices each controller was capable
> >>>>> of supporting.
> >>>>> Each of those device units can be disabled so if you want one
> >>>>> controller per disk, you absolutely can.
> >>>>>
> >>>>> Up to 4 separate MSCP controllers can be configured today (with up
> >>>>> to
> >>>>> 16 separate drives).  A single RP controller with up to 8 drives is
> >>>>> available.
> >>>>>
> >>>>> This functionality has solved most user problems without issue.
> >>>>> If you've got a simulation need for more than this, you can extend
> >>>>> or rewrite what's there now.  Since configurations that can be
> >>>>> simulated today can far exceed what was ever possible on any real
> >>>>> system, it seems like a lot of work to address the theoretical
> >>>>> flexibility you're asking for.  :-)
> >>>>
> >>>> I'd like to have more than 4 disks on one MSCP controller. There is
> >> absolutely
> >>>> no reason for the limit of 4. That's just an implementation detail
> >>>> on some of the existing MSCP controllers, but there are MSCP
> >>>> controllers who also take more than 4 disks.
> >>>>
> >>>> And that exists in real life, and I cannot do that (and a bunch of
> >>>> other
> >>>> setups) in simh, so I'd say that simh is rather more limited than
> >>>> real life. :-)
> >>>>
> >>>> Same story for TMSCP.
> >>>
> >>> Please identify Qbus or Unibus controllers that had hardware support
> >>> for connection of more than 4 units and I'll include those
> >>> controllers (with their limits) in the simulator.  A pointer to the
> >>> documentation for these devices would be helpful.
> >>
> >> The CMD SCSI controller, for example. I can have as much as 7 disks
> >> on one controller there. Or 7 tapes. And that exists for both Unibus
> >> and Qbus, and I happen to have both. But why do you want to have a
> >> limitation in simh at all here?
> >
> > It isn't a design to be limiting.  We've merely got simulations of
> > real DEC hardware connected to simulated DEC systems.  I don't think we've
> > got any Unibus, Qbus or Massbus device simulations which simulate other that
> > DEC built hardware.
> 
> That might be, but you also impose some artificial limitations...
> 
> >> The MSCP was designed to explicitly not have such limitations in the
> >> architecture. And while I'm at it, it would be nice (although this is
> >> just cosmetic) to be able to set the disk identifier to any string,
> >> and not have my arbitrary sized disk always be identified as an RA81.
> >
> > The disk Media ID is encoded in a 32bit value.  I'm not sure what the
> > encoding is.
> 
> That's been documented in some manual. I know I've seen it, and I can dig it
> up for you. But essentially, it codes in (I think) up to three letters, followed by
> a number.
> 
> > 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.

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

> >> And that limitation of 7 is obviously because of limitations on SCSI,
> >> which can only have 8 devices on the bus, and the controller is one.
> >
> > Well, DEC never made an MSCP disk controller which connected SCSI disks,
> > so even though as you point out there being 12bit values for unit settings in
> > some drives and the MSCP protocol could clearly handle relatively arbitrary
> > unit numbers, you couldn't buy a DEC controller with more than 4 drives.
> 
> Of course DEC did. It's called the RQZX1. Qbus MSCP controller using SCSI.
> However, I can't remember offhand if that model supported more than four
> disks. I have one of them somewhere, along with the manual. But not near at
> hand.  

I found the manual for that controller and the RQZX1 is a pretty cool device.  
It could be the interface for SCSI devices (disk and tape) AND for floppy devices.  
When configured to support disk and tape concurrently it provides a MSCP 
controller on the Qbus AND a TMSCP controller at the same time.  However, 
it only supports a max of 4 disk devices and a max of one tape.  So, the existing 
simh RQ (and TQ simulation) can continue to correctly emulate hardware that 
DEC sold.

I guess that I never encountered this device since by the time it shipped, all 
the systems I worked with had native/direct SCSI support and MSCP/TMSCP 
wasn't part of that solution.

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

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

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

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

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

> > Each of these disks can be up to just under 2TB in size.
> 
> More than enough for RSX, where the current limit is 8G for one disk. :-)
> 
> > 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).
 
> 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...  :-)

- Mark