[Simh] DZ11 vs DZV/DZQ11

[Johnny Billquist]

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:
>>> On Monday, April 9, 2018 at 3:08 PM, Johnny Billquist wrote:
>>>> On 2018-04-09 22:16, Mark Pizzolato wrote:
>>>>> On Monday, April 9, 2018 at 11:57 AM, Johnny Billquist wrote:
>>>>>> For serial ports, that
>>>>>> obviously means that you might connect one line to a physical line,
>>>>>> another to a telnet listener, and another one not connected to anything
>>>>>> at all.
>>>>>
>>>>> You can actually do that right now.  Each line on any multiplexer
>>>>> device can have a separate TCP listener or be connected to a remote
>>>>> TCP port or to a local serial port, or be part of the pool of ports
>>>>> which may optionally be configured to listen for the mux device.
>>>>
>>>> Right. But I cannot skip a few lines. And simh really dislikes me if the
>>>> number is
>>>> not a multiple of 8.
>>>
>>> Once the Qbus 4 vs 8 ports for the Qbus DZV11 bug that Bob pointed
>>> out is fixed, you certainly can skip as many lines as you want.  Simh
>>> is simulating the hardware.  You couldn't buy a 2 port DZ11.  They all
>>> had 8 ports.  You can choose to connect as many or as few of these
>>> lines to wherever you want with the current implementation and
>>> have the others either be completely disconnected/unused or
>>> generically listening on a specific TCP port.
>>
>> So how do I disable (not connect) some lines in simh?
> 
> You don't disable lines.  You merely describe which ports you want to connect to where and leave the others alone.  Check:
> 
>      sim> HELP DZ ATTACH
> 
> and look for how you might explicitly configure one line separately and keep on going for each line you want to connect somewhere.  Lines you don't describe connections for won't be used unless you give the whole mux a listen port (like things worked in the original simh mux behaviors).  The whole mux listen port is optional.

Ok. So if I were just to leave them alone, I'd be good. Excellent.

> FYI, you can now configure the DZ device on Qbus PDP11's with any multiple of 4 lines and get the correct number of controllers with all of the specified lines potentially connected in the various allowed ways.  Changing the CPU type from a Qbus one to a Unibus one might add 4 additional lines to the setup if (lines % 8) isn't 0.

Yeah, that make sense.

>>> With simh as it is currently written, all of your DZ devices do need to
>>> be configured to have adjacent CSR address blocks and Vectors.
>>> They can't separately be scattered around the I/O space.
>>
>> ...which I can with real hardware.
> 
> See prior message about rewriting many things in your spare time.

:-)

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

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

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

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. You can without problem generate 
an RSX system where you have 16 disks on one MSCP controller, if you 
want to.

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

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

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.

> Have fun.

Always. :-)

   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