[...]
Post by Johnny BillquistPost by Mark PizzolatoPost by Mark PizzolatoPost by Mark PizzolatoPost by Johnny BillquistPost by Mark PizzolatoPost by Johnny BillquistAnd 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
Post by Mark PizzolatoPost by Johnny Billquistno 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...
Post by Mark PizzolatoPost by Mark PizzolatoThe 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.
Post by Mark PizzolatoSome 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.
Post by Johnny BillquistPost by Mark PizzolatoThe 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.
Post by Johnny BillquistPost by Mark PizzolatoPost by Mark PizzolatoAnd 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.
Post by Johnny BillquistBut 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.
Post by Johnny BillquistSo 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.
Post by Johnny BillquistYou 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. :-)
Post by Johnny BillquistPost by Mark PizzolatoAs 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).
Post by Johnny BillquistPost by Mark PizzolatoEach 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. :-)
Post by Mark PizzolatoIf 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).
Post by Johnny BillquistAnd 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