subject:"Re\: \[Simh\] DZ11 vs DZV\/DZQ11"


On 2018-04-12 23:05, Mark Pizzolato wrote:


I've added this to the pdp11_rq.c to describe these values:

/*

MediaId

Is defined in the MSCP Basic Disk Functions Manual, page 4-37 to 4-38:

The media type identifier is a 32-bit number, and it's coded like this:
The high 25 bits are 5 characters, each coded with 5 bits. The low 7
bits is a binary coded 2 digits.

Looking at it, you have:
D0,D1,A0,A1,A2,N

For an RA81, it would be:

D0,D1 is the preferred device type name for the unit. In our case,
that would be "DU".
A0,A1,A2 is the name of the media used on the unit. In our case "RA".
N is the value of the two decimal digits, so 81 for this example.

And for letters, the coding is that A=1, B=2 and so on. 0 means the
character is not used.

So, again, for an RA81, we would get:

Decimal Values:4,21,18, 1, 0,  81
Hex Values:4,15,12, 1, 0,  51
Binary Values: 00100, 10101, 10010, 1, 0, 1010001
Hex 4 bit Nibbles:2 5 6 4   1 0 5   1

The 32bit value of RA81_MED is 0x25641051

  */

Thanks.


No problem. And thanks for clearing up my scribblings. I feared that it 
might have been a bit too cryptic.



I'm wondering if the leading first two characters (DU) of the ID is used when a device is 
"MSCP Served" by one system out to a cluster at large.  This might facilitate 
connecting the serving system's local driver to the remote requests.


No idea, but it's definitely possible.

  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-12 Thread Mark Pizzolato

On Thursday, April 12, 2018 at 12:25 PM, Johnny Billquist wrote:
> 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:
[...]
> > 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.

Well, it wasn't initially and it now is.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-12 Thread Mark Pizzolato

On Thursday, April 12, 2018 at 1:35 PM, Johnny Billquist wrote:
> On 2018-04-12 22:31, Johnny Billquist wrote:
> > On 2018-04-12 21:24, Johnny Billquist wrote:
> >> 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.
> >
> > Ok, I decided to locate the documentation on how this value/string is
> > encoded, since Mark said he'd not seen it.
> > It's in the MSCP Basic Disk Functions Manual, page 4-37 to 4-38.
> > The media type identifier is a 32-bit number, and it's coded like this:
> > The high 25 bits are 5 characters, each coded with 5 bits. The low 7
> > bits is a binary coded 2 digits.
> >
> > Looking at it, you have:
> > D0,D1,A0,A1,A2,N
> >
> > For an RA81, it would be:
> >
> > D0,D1 is the preferred device type name for the unit. In our case,
> > that would be "DU".
> > A0,A1,A2 is the name of the media used on the unit. In our case "RA".
> > N is the value of the two decimal digits, so 81 for this example.
> >
> > And for letters, the coding is that A=1, B=2 and so on. 0 means the
> > character is not used.
> >
> > So, again, for an RA81, we would get:
> > 4,15,12,1,0,81
> >
> > That's all in decimal, and you have the size of each bitfield.
> 
> And I'm an idiot. For the letters, that actually turned out to be hex, and not
> decimal...

I've added this to the pdp11_rq.c to describe these values:

/*

MediaId

Is defined in the MSCP Basic Disk Functions Manual, page 4-37 to 4-38:

The media type identifier is a 32-bit number, and it's coded like this:
The high 25 bits are 5 characters, each coded with 5 bits. The low 7 
bits is a binary coded 2 digits.

Looking at it, you have:
D0,D1,A0,A1,A2,N

For an RA81, it would be:

D0,D1 is the preferred device type name for the unit. In our case, 
that would be "DU".
A0,A1,A2 is the name of the media used on the unit. In our case "RA".
N is the value of the two decimal digits, so 81 for this example.

And for letters, the coding is that A=1, B=2 and so on. 0 means the 
character is not used.

So, again, for an RA81, we would get:

Decimal Values:4,21,18, 1, 0,  81
Hex Values:4,15,12, 1, 0,  51
Binary Values: 00100, 10101, 10010, 1, 0, 1010001
Hex 4 bit Nibbles:2 5 6 4   1 0 5   1

The 32bit value of RA81_MED is 0x25641051

 */

Thanks.

I'm wondering if the leading first two characters (DU) of the ID is used when a 
device is "MSCP Served" by one system out to a cluster at large.  This might 
facilitate connecting the serving system's local driver to the remote requests.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-12 22:31, Johnny Billquist wrote:

On 2018-04-12 21:24, Johnny Billquist wrote:

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.


Ok, I decided to locate the documentation on how this value/string is 
encoded, since Mark said he'd not seen it.

It's in the MSCP Basic Disk Functions Manual, page 4-37 to 4-38.
The media type identifier is a 32-bit number, and it's coded like this:
The high 25 bits are 5 characters, each coded with 5 bits. The low 7 
bits is a binary coded 2 digits.


Looking at it, you have:
D0,D1,A0,A1,A2,N

For an RA81, it would be:

D0,D1 is the preferred device type name for the unit. In our case, that 
would be "DU".

A0,A1,A2 is the name of the media used on the unit. In our case "RA".
N is the value of the two decimal digits, so 81 for this example.

And for letters, the coding is that A=1, B=2 and so on. 0 means the 
character is not used.


So, again, for an RA81, we would get:
4,15,12,1,0,81

That's all in decimal, and you have the size of each bitfield.


And I'm an idiot. For the letters, that actually turned out to be hex, 
and not decimal...


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-12 21:24, Johnny Billquist wrote:

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.


Ok, I decided to locate the documentation on how this value/string is 
encoded, since Mark said he'd not seen it.

It's in the MSCP Basic Disk Functions Manual, page 4-37 to 4-38.
The media type identifier is a 32-bit number, and it's coded like this:
The high 25 bits are 5 characters, each coded with 5 bits. The low 7 
bits is a binary coded 2 digits.


Looking at it, you have:
D0,D1,A0,A1,A2,N

For an RA81, it would be:

D0,D1 is the preferred device type name for the unit. In our case, that 
would be "DU".

A0,A1,A2 is the name of the media used on the unit. In our case "RA".
N is the value of the two decimal digits, so 81 for this example.

And for letters, the coding is that A=1, B=2 and so on. 0 means the 
character is not used.


So, again, for an RA81, we would get:
4,15,12,1,0,81

That's all in decimal, and you have the size of each bitfield.
So then it becomes are rather easy task to compute what the 32-bit value 
is for this.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

On 2018-04-12 16:06, Paul Koning wrote:

On Apr 11, 2018, at 8:41 PM, Mark Pizzolato wrote:

On Tuesday, April 10, 2018 at 10:15 AM, Johnny Billquist wrote:

...

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 ID string is just a string, for display. RSTS displays it (in the "hardware list" command in
the boot program "init"). But there is also in MSCP a way to ask for geometry, which MSCP views as
sectors, tracks, cylinders, and "groups". That too is informational since addressing is by LBA,
but the intent was to allow an OS to do geometry-aware optimization if it wanted to. Deriving geometry from
the device ID would be wrong, but asking for it explicitly would be valid.

Right. Same story in RSX. It's purely cosmetic.

And I don't think anyone really tried to do something based on geometry,
since it's mostly bogus anyway. MSCP address by LBA in the end, as you
say, and newer disks did not have the same number of sectors per track
anyway, so the geometry became just an approximation. Not to mention
that replacement blocks could mean that you were not even close to the
right place anyway.

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.

I thought it was 15 devices -- 4 bit LUN number with the value 7 reserved for
the controller.

The LUN in SCSI is for something that looks like subunits or partitions.
The SCSI ID, which is the primary identifier, is a 3 bit number, giving
you a max of 8 devices on narrow SCSI, and it's a 4 bit number on wide
SCSI. You often had three jumpers on the devices, to select the ID, in
the old days.

Wide SCSI came pretty late in relation to PDP-11s, so there are very few
wide SCSI controllers for PDP-11. Almost all that exists are narrow SCSI.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


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

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-12 Thread Paul Koning



> On Apr 11, 2018, at 8:41 PM, Mark Pizzolato  wrote:
> 
> On Tuesday, April 10, 2018 at 10:15 AM, Johnny Billquist wrote:
>>> 
>>> ...
>> 
>> 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 ID string is just a string, for display.  RSTS displays it (in the 
"hardware list" command in the boot program "init").  But there is also in MSCP 
a way to ask for geometry, which MSCP views as sectors, tracks, cylinders, and 
"groups".  That too is informational since addressing is by LBA, but the intent 
was to allow an OS to do geometry-aware optimization if it wanted to.  Deriving 
geometry from the device ID would be wrong, but asking for it explicitly would 
be valid.

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

I thought it was 15 devices -- 4 bit LUN number with the value 7 reserved for 
the controller.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-11 Thread 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

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-10 15:19, Paul Koning wrote:




On Apr 10, 2018, at 3:02 AM, Johnny Billquist  wrote:

On 2018-04-10 01:55, Paul Koning wrote:

On Apr 9, 2018, at 6:25 PM, Mark Pizzolato  wrote:

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

That conforms to the float rules, so it seems like a reasonable restriction.  
It's theoretically possible to configure real hardware differently, and in some 
OS you can then still talk to the devices (by setting addresses manually) but 
it would not be a standard config and probably not supported.


While RSX certainly tries to probe CSRs and vectors according to the 
configuration rules DEC defined, in my experience, most machines never followed 
those rules. People just did not understand them enough, nor did they ever go 
and change a bunch of controllers whenever some device was added or removed.
So in real life, I'd say almost every machine always had other layouts of CSRs 
and vectors than the recommended one, and atleast with RSX, you always run a 
SYSGEN, and have to at put in the CSR and vector manually anyhow. The only time 
autoconfiguration was done was at the initial install of the system. And later 
reconfiguration was totally manual.


RSTS does it differently (starting with V6B).  There, the hardware layout is probed at 
each boot.  Devices are identified by their CSR address according to the float rules.  
Then they are "poked" to force an interrupt, and the interrupt vector address 
is determined from that.  Exceptions include the card readers (no way to poke them), the 
KG11 (no interrupt).  Programmable interrupt devices like MSCP controllers would still be 
poked, but then given a free vector address.  So RSTS requires float CSR conformance but 
doesn't care about float vectors, so long as the vectors assigned to the devices are all 
distinct.


Ah. Interesting. Yes, definitely differently than RSX then. RSX is 
specifically tailored to your hardware. So the system already knows what 
hardware exist, and at what CSRs and vectors. There is probing at boot 
time, but only to confirm that the configured hardware actually is 
there. Otherwise those devices will be marked offline. So, adding or 
removing hardware do not affect how the detection happen. No scan 
according to the floating space specs are done in RSX, except at the 
original SYSGEN run, where SYSGEN offers to try and detect what hardware 
you actually have. With the explicit warning that this might hang your 
system, in which case you should reboot and run SYSGEN again, but not do 
the autoconfiguration step.


And if you reconfigure the hardware, such as change the CSR address of a 
device, you either need to rerun the SYSGEN (a long and annoying process 
in -11M), or reconfigure the system (only possible in M+). So people 
tended to not change the CSR addresses, even if they added another 
device. Adding a device in RSX is a simple thing, since you can load 
device drivers on the fly in the running system anyway.



Any non-standard addresses could be manually configured and RSTS would then 
"poke" that address instead to find the vector.

Given that RSTS supported autoconfiguration like this, I would expect RSTS 
systems generally to conform to the float CSR rules because that made the job a 
whole lot easier for customers.  But it would work either way.


Sounds like RSTS/E customers would have more reason to follow the 
floating CSR rules, yes. In RSX, you almost get punished if you do. :-)


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-10 15:13, Paul Koning wrote:




On Apr 9, 2018, at 9:28 PM, Mark Pizzolato  wrote:

On Monday, April 9, 2018 at 4:56 PM, Paul Koning wrote:

...


I don't remember controllers with more than 4 units per device, but MSCP unit
numbers are arbitrary 8 bit values.  So a limit of 4 units is proper, but a
limitation on those unit numbers being 0..3 is not accurate.  It matters in some
OS.  For example, VMS has type/controller/unit addressing (DUA3 etc.) but
RSTS does not.  So on RSTS, if you have more than one MSCP controller, they
must have disjoint unit numbers.  Since the unit numbers are 8 bits, that's easy
to do.  But I don't see how I can do that in SIMH.


I see 2 approaches to adding support for different unit numbers:
1) A unit number is settable uniquely for each of the 4 drives that can be
attached to any of these controllers.  This would map to a conceptual Drive Unit
Plug.  Did these exist on DEC MSCP drives?
2) A 'base' unit number can be set on a controller and each drive on that 
controller
would then have unit numbers equal to the base plus their existing internal unit
numbers.  This may have been how third party MSCP controllers worked.

Which of these best reflects how the real hardware worked?


Option 1.  Drives like the RA80 had a unit number cap covering the select lamp. 
 It looked similar to the unit number light on older drives like the RL01, but 
it was built differently.  If you pulled off the cap, you'd see 8 plastic 
prongs extending from the back rim, which you could cut to make the binary 
encoding of the desired unit number.  You'd then mark the plug with the number 
(with stick-on numbers perhaps).  I think some pre-made number plugs for the 
small numbers were available, but you could make your own and that's how you'd 
get a unit number 142 or the like.


You always got a blank plug with all pins in place. Then you'd cut off 
whatever pins you wanted. Along with the plug you also got a sheet with 
transparent stickers with different numbers. All the numbers from 0 to 
255 were provided on the sheet.


I don't think I ever saw any "premade" unit number plugs for the RA disks.

  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


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
identif

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-10 Thread Paul Koning

> On Apr 10, 2018, at 3:02 AM, Johnny Billquist  wrote:
> 
> On 2018-04-10 01:55, Paul Koning wrote:
>>> On Apr 9, 2018, at 6:25 PM, Mark Pizzolato  wrote:
>>> 
>>> ...
>>> 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.
>> That conforms to the float rules, so it seems like a reasonable restriction. 
>>  It's theoretically possible to configure real hardware differently, and in 
>> some OS you can then still talk to the devices (by setting addresses 
>> manually) but it would not be a standard config and probably not supported.
> 
> While RSX certainly tries to probe CSRs and vectors according to the 
> configuration rules DEC defined, in my experience, most machines never 
> followed those rules. People just did not understand them enough, nor did 
> they ever go and change a bunch of controllers whenever some device was added 
> or removed.
> So in real life, I'd say almost every machine always had other layouts of 
> CSRs and vectors than the recommended one, and atleast with RSX, you always 
> run a SYSGEN, and have to at put in the CSR and vector manually anyhow. The 
> only time autoconfiguration was done was at the initial install of the 
> system. And later reconfiguration was totally manual.

RSTS does it differently (starting with V6B).  There, the hardware layout is 
probed at each boot.  Devices are identified by their CSR address according to 
the float rules.  Then they are "poked" to force an interrupt, and the 
interrupt vector address is determined from that.  Exceptions include the card 
readers (no way to poke them), the KG11 (no interrupt).  Programmable interrupt 
devices like MSCP controllers would still be poked, but then given a free 
vector address.  So RSTS requires float CSR conformance but doesn't care about 
float vectors, so long as the vectors assigned to the devices are all distinct.

Any non-standard addresses could be manually configured and RSTS would then 
"poke" that address instead to find the vector.

Given that RSTS supported autoconfiguration like this, I would expect RSTS 
systems generally to conform to the float CSR rules because that made the job a 
whole lot easier for customers.  But it would work either way.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-10 Thread Paul Koning



> On Apr 9, 2018, at 9:28 PM, Mark Pizzolato  wrote:
> 
> On Monday, April 9, 2018 at 4:56 PM, Paul Koning wrote:
>>> ...
>> 
>> I don't remember controllers with more than 4 units per device, but MSCP unit
>> numbers are arbitrary 8 bit values.  So a limit of 4 units is proper, but a
>> limitation on those unit numbers being 0..3 is not accurate.  It matters in 
>> some
>> OS.  For example, VMS has type/controller/unit addressing (DUA3 etc.) but
>> RSTS does not.  So on RSTS, if you have more than one MSCP controller, they
>> must have disjoint unit numbers.  Since the unit numbers are 8 bits, that's 
>> easy
>> to do.  But I don't see how I can do that in SIMH.
> 
> I see 2 approaches to adding support for different unit numbers:
> 1) A unit number is settable uniquely for each of the 4 drives that can be 
> attached to any of these controllers.  This would map to a conceptual Drive 
> Unit 
> Plug.  Did these exist on DEC MSCP drives?
> 2) A 'base' unit number can be set on a controller and each drive on that 
> controller 
> would then have unit numbers equal to the base plus their existing internal 
> unit 
> numbers.  This may have been how third party MSCP controllers worked.
> 
> Which of these best reflects how the real hardware worked?

Option 1.  Drives like the RA80 had a unit number cap covering the select lamp. 
 It looked similar to the unit number light on older drives like the RL01, but 
it was built differently.  If you pulled off the cap, you'd see 8 plastic 
prongs extending from the back rim, which you could cut to make the binary 
encoding of the desired unit number.  You'd then mark the plug with the number 
(with stick-on numbers perhaps).  I think some pre-made number plugs for the 
small numbers were available, but you could make your own and that's how you'd 
get a unit number 142 or the like.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-10 Thread Mark Pizzolato

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.

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.

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

> The MSCP was designed to explicitly not
> have such l

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-10 09:12, Johnny Billquist wrote:

On 2018-04-10 03:28, Mark Pizzolato wrote:

I see 2 approaches to adding support for different unit numbers:
1) A unit number is settable uniquely for each of the 4 drives that 
can be
attached to any of these controllers.  This would map to a conceptual 
Drive Unit

Plug.  Did these exist on DEC MSCP drives?


Yes they did.


I should actually add that for the RA60, RA80, RA81 and RA82, this plug 
is binary coded with 8 tabs that you can cut off, and allows you to 
select a unit number between 0 and 255. On the RA90 and RA92. The front 
panel of the disk has a display and buttons, and you can select the unit 
number from there, and it goes between 0 and 4095.
The RA70 disk has dip 8 dip switches where you can select the unit 
number. The RA70, RA71, RA72 and RA73 can also be placed in a larger box 
called the SA7x (I think, can't remember if the x was supposed to be 
replaced with some number depending on configuration), where you then 
have a display that control up to four disks in the container. Each disk 
can then be managed by a front panel on the SA. And each disk has its 
own unit number selectable on the front panel, and the unit number goes 
from 0 to 255 (not 4095 as I said in a previous post). Or at least my 
memory right now is 0..255 for the RA7x drives, but I could be 
remembering wrong.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-10 03:28, Mark Pizzolato wrote:

On Monday, April 9, 2018 at 4:56 PM, Paul Koning wrote:

On Apr 9, 2018, at 6:25 PM, Mark Pizzolato  wrote:

...

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


I don't remember controllers with more than 4 units per device, but MSCP unit
numbers are arbitrary 8 bit values.  So a limit of 4 units is proper, but a
limitation on those unit numbers being 0..3 is not accurate.  It matters in some
OS.  For example, VMS has type/controller/unit addressing (DUA3 etc.) but
RSTS does not.  So on RSTS, if you have more than one MSCP controller, they
must have disjoint unit numbers.  Since the unit numbers are 8 bits, that's easy
to do.  But I don't see how I can do that in SIMH.


I see 2 approaches to adding support for different unit numbers:
1) A unit number is settable uniquely for each of the 4 drives that can be
attached to any of these controllers.  This would map to a conceptual Drive Unit
Plug.  Did these exist on DEC MSCP drives?


Yes they did.


2) A 'base' unit number can be set on a controller and each drive on that 
controller
would then have unit numbers equal to the base plus their existing internal unit
numbers.  This may have been how third party MSCP controllers worked.


I've never seen any controller doing this approach.
The SCSI controllers I've seen and used have a configuration tool built 
in, which allows me to map the SCSI unit number to an arbitrary MSCP 
unit number for each unit.



Which of these best reflects how the real hardware worked?


I'd say option 1.

  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-10 01:55, Paul Koning wrote:




On Apr 9, 2018, at 6:25 PM, Mark Pizzolato  wrote:

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


That conforms to the float rules, so it seems like a reasonable restriction.  
It's theoretically possible to configure real hardware differently, and in some 
OS you can then still talk to the devices (by setting addresses manually) but 
it would not be a standard config and probably not supported.


While RSX certainly tries to probe CSRs and vectors according to the 
configuration rules DEC defined, in my experience, most machines never 
followed those rules. People just did not understand them enough, nor 
did they ever go and change a bunch of controllers whenever some device 
was added or removed.
So in real life, I'd say almost every machine always had other layouts 
of CSRs and vectors than the recommended one, and atleast with RSX, you 
always run a SYSGEN, and have to at put in the CSR and vector manually 
anyhow. The only time autoconfiguration was done was at the initial 
install of the system. And later reconfiguration was totally manual.



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


I don't remember controllers with more than 4 units per device, but MSCP unit 
numbers are arbitrary 8 bit values.  So a limit of 4 units is proper, but a 
limitation on those unit numbers being 0..3 is not accurate.  It matters in 
some OS.  For example, VMS has type/controller/unit addressing (DUA3 etc.) but 
RSTS does not.  So on RSTS, if you have more than one MSCP controller, they 
must have disjoint unit numbers.  Since the unit numbers are 8 bits, that's 
easy to do.  But I don't see how I can do that in SIMH.


It's actually 12 bits for unit numbers. Early disks with plugs could 
only code 8 bits, but later ones, like the RA7x series use all 12, and 
have a small display where you can set the unit number.


And yes, you bring up another good point here. Forcing the unit numbers 
to be 0..3 on each controller is also a bit confusing compared to real 
life. In RSX, the unit numbers on the devices are disjunct from the unit 
numbers in the system, but it usually was good practice to keep them the 
same, otherwise it can be a bit of an hassle to figure out which disk is 
DU0: (having three disks all with unit #0 makes it really hard).
Even in VMS, it does become tricky, since there is no obvious way to 
tell on which controller the disk is, so DUA0:, DUB0: or DUC0: will all 
look the same until you've traced all the cables and controllers... Ugh!


As for more than 4 disks on a controller, I already answered that one, 
but the SCSI controllers I know will allow more than 4 disks, for example.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


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?


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.


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


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.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

On Monday, April 9, 2018 at 9:00 PM, Robert Armstrong wrote:
> >distinguish between [CXA16] controller and a CXY08,  ...
> 
>   Short answer is that I don't know, but the RSX SYSGEN (for example) allows
> you to specify the number of lines per controller independently of the
> controller type.  So for the CXA16 you'd just tell it that you had a DHU or 
> DHV
> (depending on how you set the switch on the CXA16 card) with 16 lines per
> controller.  For the CXY08 you'd do the same thing, but 8 lines per control.  
> It
> doesn't need to know the actual hardware configuration.

I'm sure that these devices were far more common on VMS system.

I'm certain that VMS managed to distinguish how many lines there are on 
the board without some external user input.  I only have driver listings for
VMS V5.5 which is more than likely before these devices existed so that 
isn't a good place to look.  If someone can come up with a technical or
user manual for this board, or specific info from an OS driver we can 
readily add it.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

>That should be done now.  Please confirm you're happy with the result.

  Thanks, I'll pull that down tomorrow and try it.

>distinguish between [CXA16] controller and a CXY08,  ...

  Short answer is that I don't know, but the RSX SYSGEN (for example) allows 
you to specify the number of lines per controller independently of the 
controller type.  So for the CXA16 you'd just tell it that you had a DHU or DHV 
(depending on how you set the switch on the CXA16 card) with 16 lines per 
controller.  For the CXY08 you'd do the same thing, but 8 lines per control.  
It doesn't need to know the actual hardware configuration.

Bob

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

On Monday, April 9, 2018 at 4:56 PM, Paul Koning wrote:
> > On Apr 9, 2018, at 6:25 PM, Mark Pizzolato  wrote:
> >
> > ...
> >> ...
> >> 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.
> 
> I don't remember controllers with more than 4 units per device, but MSCP unit
> numbers are arbitrary 8 bit values.  So a limit of 4 units is proper, but a
> limitation on those unit numbers being 0..3 is not accurate.  It matters in 
> some
> OS.  For example, VMS has type/controller/unit addressing (DUA3 etc.) but
> RSTS does not.  So on RSTS, if you have more than one MSCP controller, they
> must have disjoint unit numbers.  Since the unit numbers are 8 bits, that's 
> easy
> to do.  But I don't see how I can do that in SIMH.

I see 2 approaches to adding support for different unit numbers:
1) A unit number is settable uniquely for each of the 4 drives that can be 
attached to any of these controllers.  This would map to a conceptual Drive 
Unit 
Plug.  Did these exist on DEC MSCP drives?
2) A 'base' unit number can be set on a controller and each drive on that 
controller 
would then have unit numbers equal to the base plus their existing internal 
unit 
numbers.  This may have been how third party MSCP controllers worked.

Which of these best reflects how the real hardware worked?

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

On Monday, April 9, 2018 at 2:23 PM, Robert Armstrong wrote:
> >Do you see a down side to the rounding up so the number of lines fits?
> 
>For the DZ/DZV/DZQ case I think that will solve the problem.

That should be done now.  Please confirm you're happy with the result.

>However, I think the VH case is a little more complicated -
> 
>   * The UNIBUS DH11 and DHU11 had 16 lines per interface
>   * The QBUS DHV11 had 8 lines per interface
>   * The QBUS CXY08 was DHU/DHV compatible and had 8 lines
>   * The QBUS CXA16  ""   ""   ""   "  16 lines

Well, we don't specifically claim to emulate a CXA16.  If you can find 
documentation which describes how Qbus PDP11 or VAX can distinguish 
between this controller and a CXY08, then we can add support and thus
have to solve the problem of how many lines.  Otherwise, the existing
expression (Unibus ? 16 : 8) is sufficient in the current VH simulator.

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-09 Thread Paul Koning

> On Apr 9, 2018, at 6:25 PM, Mark Pizzolato  wrote:
> 
> ...
> 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.

That conforms to the float rules, so it seems like a reasonable restriction.  
It's theoretically possible to configure real hardware differently, and in some 
OS you can then still talk to the devices (by setting addresses manually) but 
it would not be a standard config and probably not supported.

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

I don't remember controllers with more than 4 units per device, but MSCP unit 
numbers are arbitrary 8 bit values.  So a limit of 4 units is proper, but a 
limitation on those unit numbers being 0..3 is not accurate.  It matters in 
some OS.  For example, VMS has type/controller/unit addressing (DUA3 etc.) but 
RSTS does not.  So on RSTS, if you have more than one MSCP controller, they 
must have disjoint unit numbers.  Since the unit numbers are 8 bits, that's 
easy to do.  But I don't see how I can do that in SIMH.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

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.

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.

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

Thanks.

- Mark

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-09 22:16, Mark Pizzolato wrote:

On Monday, April 9, 2018 at 11:57 AM, Johnny Billquist wrote:

I think the whole concept of deriving the number of controllers based on units
in simh is wrong.
I think one should configure each controller separately, including being able to
tell what CSR and vector it has, and how many units should be connected one
way or another, and any other relevant information.


Well, that was not how these things were written long ago.   What you're
suggesting would require a rather dramatic rewrite of essentially all of the
Unibus and Qbus devices.  If you've got the time, please go head.  :-)


I know. I still consider it a design flaw. And no, I do not have the 
time. :-)



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.



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.

  Johnny



- Mark




--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11


On 2018-04-09 21:12, Robert Armstrong wrote:

*>….*single PDP11 simulator can simulate different PDP11 models …

   Yes, and the UNIBUS and QBUS peripherals don’t always map exactly in 
functionality.  Actually I’m surprised this situation hasn’t come up 
before with other devices.


Depends on how you look at it. I've certainly had issues in the past 
because I tried to do things like in the real hardware, which simh just 
couldn't deal with. But you often adopt to what simh actually can do...



Feel free not to use the extra ports that are provided free of charge. J


   You’re right – for the most part it doesn’t matter.   But, … if 
you’re using the DZV/DZQ simulation with a TELNET port (which I imagine 
is what most people do) then I don’t think you can stop simh from 
accepting a connection for lines 4..7 if the first four lines are 
already busy.  And if you want to simulate a QBUS machine with 8 lines 
and two DVZ/DZQ cards, then what the OS actually sees is all eight 
connections coming in on the first card and none on the second card.  I 
haven’t tried it yet, but I don’t know what the various -11 OSes will do 
when they get activity on lines that can’t physically exist.  Probably 
they use the same driver for both the DZ and DZV so they won’t care, but 
I don’t know that.


Of course they care! When a character is received on a DZ line, the 
driver have to map that into a device. Which, in this case, will be a 
device that does not exist.
It will not be mapping them to the devices configured for the second 
controller.

Or at least RSX certainly won't.

 What should happen when an odd number of DZV11’s are configured and 

the CPU type is changed…

Well, ideally there should be an error or warning message, but I imagine 
that’s difficult to implement.


   For me, I’d be happy if simh was changed to accept “SET LINES=…” in 
multiples of 4 rather than multiples of 8.  It’s true that this would 
possibly allow you to create invalid DZ configurations, but in my mind 
the possibility of deliberately defining an invalid configuration is 
less annoying than the impossibility of defining a valid configuration.


It's hardly invalid to have a controller where not all lines are 
connected to anything, and are not actually configured in the OS to map 
to any device. You can configure RSX to have two DZ controllers, and 
only two terminal lines, one on each controller. Any characters on any 
other lines than the ones you have configured will be dropped by the 
driver. And there can actually be good reasons for such configurations. 
Each device takes up memory. So don't configure in devices you'll never 
use, including extra terminal lines. But RSX can also talk DECnet over 
serial lines. But DECnet requires its own controller, and cannot share 
it with the normal terminal driver. So, if you want one serial line, and 
one DECnet asynch DDCMP connection, you will need to configure two DZ 
controllers, but you might very well only be interested in one line on 
each controller.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

>it seems like a lot of work to address the theoretical flexibility you're 
>asking for.  :-)

  It's worth pointing out that there's a use case for simh where somebody uses 
the simulator to install software on, and build a disk image for, a real 
machine.  Once all the software is installed and configured on the simulation, 
you can transfer the disk image file to a real disk drive and plug it into a 
real machine.  Boot it up and away you go...

  There are lots of advantages to doing this - simh is way faster than a real 
machine when it comes to configuring, compiling and linking operating systems.  
It's way easier to copy of a simh disk image file to create a backup or check 
point.  If your software distros are already in the form of tap files or 
diskette images online, then it's way easier to connect them to simh then to 
write them to real media.  And so on...

  In this use case it's advantageous to be able to reproduce the exact target 
hardware configuration in simh.  This is especially true for most PDP-11 OSes, 
which require that CSRs and vectors be defined when the system is generated and 
don't autoconfigure for hardware changes (or at least they don't autoconfigure 
very well).

  There are obviously a lot of hardware combinations and the amount of effort 
that should be put into simulating all of them is debatable, but if there are 
simple fixes that can be made which would expand the range of configurations 
that can be simulated correctly then that's probably worthwhile.

Bob

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

>Do you see a down side to the rounding up so the number of lines fits?

   For the DZ/DZV/DZQ case I think that will solve the problem.

   However, I think the VH case is a little more complicated -

  * The UNIBUS DH11 and DHU11 had 16 lines per interface
  * The QBUS DHV11 had 8 lines per interface
  * The QBUS CXY08 was DHU/DHV compatible and had 8 lines
  * The QBUS CXA16  ""   ""   ""   "  16 lines

  Maybe it would be easier to implement a simh command "SET [DZ|VH] 
LINES_PER_INTERFACE=..." and push the problem off on the user.  This would 
allow you to reproduce all legal hardware configurations, and create a few that 
never existed in real life.  I suppose the latter is undesirable, but there are 
several other cases in which simh can create hardware configurations that never 
actually existed.

Bob

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

2018-04-09 Thread Paul Koning

Perhaps the DHV/DHU code has a solution that can be adapted, since it does seem 
to cover the case.  

paul

> On Apr 9, 2018, at 2:47 PM, Mark Pizzolato  wrote:
> 
> Hmmm..
>  
> This is indeed true.  The problem comes from the fact that the single PDP11 
> simulator can simulate different PDP11 models some of which are Unibus while 
> others are Qbus systems.  On the various VAX simulators, each simulator only 
> simulates either a Unibus or a Qbus machine and thus things are simpler to 
> align and thus things appear as you would expect.
>  
> Feel free not to use the extra ports that are provided free of charge.  J
>  
> Seriously, I’ll look into addressing this.  The number of DZ11/DZV11 devices 
> that are simulated is derived from the number of lines which are configured.  
> A problem arises when the CPU type changes between a Unibus and Qbus types.  
> What should happen when an odd number of DZV11’s are configured and the CPU 
> type is changed from a Qbus type to a Unibus type?   
>   <>
> From: Simh [mailto:simh-boun...@trailing-edge.com 
> ] On Behalf Of Robert Armstrong
> Sent: Monday, April 9, 2018 7:35 AM
> To: simh@trailing-edge.com 
> Subject: [Simh] DZ11 vs DZV/DZQ11
>  
>   It appears that if you want to simulate a DZV or DZQ11 on a QBUS PDP11, 
> then you have to use the UNIBUS DZ11 instead.  That’s OK, except that a DZ11 
> has 8 lines per card where as the DZV and DZQ are only 4 lines per card.  
> Simh won’t let you say “SET DZ LINES=4”.  This is something of an issue 
> because I want to set up my simh environment to exactly mimic my real 
> hardware, and it appears that’s not possible as far as the DZ goes.
>  
>   Or am I missing something??
>  
>   BTW, it’s funny that “HELP DZ” in simh talks exclusively about the DZV11 
> and even says things like 
>  
> … The DZV11 is a 8 line terminal multiplexor. …
>  
> That’s totally wrong…
>  
> Bob Armstrong
>  
> ___
> Simh mailing list
> Simh@trailing-edge.com 
> http://mailman.trailing-edge.com/mailman/listinfo/simh 
> 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

On Monday, April 9, 2018 at 12:13 PM, Robert Armstrong wrote:
> >…. single PDP11 simulator can simulate different PDP11 models …
>
>  Yes, and the UNIBUS and QBUS peripherals don’t always map 
> exactly in functionality.  Actually I’m surprised this situation 
> hasn’t come up before with other devices.

The only other device which I can think of that has a different 
number of ports/units on the Qbus version vs Unibus is the VH
and indeed this bus change problem will also exist there for the 
PDP11 simulator.

> >Feel free not to use the extra ports that are provided free of charge.  ☺
>
>  You’re right – for the most part it doesn’t matter.   But, … if 
> you’re using the DZV/DZQ simulation with a TELNET port (which 
> I imagine is what most people do) then I don’t think you can 
> stop simh from accepting a connection for lines 4..7 if the first 
> four lines are already busy.  

True, and I see that as the problem/bug you are reporting and 
which needs fixing.

> And if you want to simulate a QBUS machine with 8 lines and 
> two DVZ/DZQ cards, then what the OS actually sees is all eight 
> connections coming in on the first card and none on the second 
> card.  I haven’t tried it yet, but I don’t know what the various -11 
> OSes will do when they get activity on lines that can’t physically 
> exist.  Probably they use the same driver for both the DZ and 
> DZV so they won’t care, but I don’t know that.

Well, since the drivers are common, and the driver knows that 
it is on a Qbus machine, it will only respond to and/or use 4 lines
per controller.  Lines 4-7, 12-15, etc. won't be recognized by the 
OS.  Incoming telnet connections won't behave reasonably since 
the OS won't see them properly.

> >  What should happen when an odd number of DZV11’s are 
> > configured and the CPU type is changed …
>
> Well, ideally there should be an error or warning message, but 
> I imagine that’s difficult to implement.

Difficult or not, when someone changes the CPU type all devices 
get to see that this has happened and some devices are 
automatically disabled if a variant they support isn't available on 
the new bus type.

I'm going to have the number of available lines round up to the
appropriate number that fits.  So, if lines is 4 and a switch is 
made from Qbus to Unibus, then the DZ will be enhanced to 
have 8 lines.

>  For me, I’d be happy if simh was changed to accept 
> “SET LINES=…” in multiples of 4 rather than multiples of 8.  
> It’s true that this would possibly allow you to create invalid 
> DZ configurations, but in my mind the possibility of deliberately 
> defining an invalid configuration is less annoying than the 
> impossibility of defining a valid configuration.

Do you see a down side to the rounding up so the number of 
lines fits?

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

On Monday, April 9, 2018 at 11:57 AM, Johnny Billquist wrote:
> I think the whole concept of deriving the number of controllers based on units
> in simh is wrong.
> I think one should configure each controller separately, including being able 
> to
> tell what CSR and vector it has, and how many units should be connected one
> way or another, and any other relevant information. 

Well, that was not how these things were written long ago.   What you're 
suggesting would require a rather dramatic rewrite of essentially all of the 
Unibus and Qbus devices.  If you've got the time, please go head.  :-)

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

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

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

> accept "SET LINES=." in multiples of 4 rather than multiples of 8

 

  Actually I guess you're still going to need to know whether it's a QBUS or
UNIBUS machine so you can figure out how many DZ/DZV/DZQ cards to emulate.
It seems like there's no way out of that.

 

  BTW, I haven't looked at it, but doesn't the VH device (DH/DHQ/DHV) have
the same problem?

 

Bob

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

>.. single PDP11 simulator can simulate different PDP11 models .

 

  Yes, and the UNIBUS and QBUS peripherals don't always map exactly in
functionality.  Actually I'm surprised this situation hasn't come up before
with other devices.

 

>Feel free not to use the extra ports that are provided free of charge.  J

 

  You're right - for the most part it doesn't matter.   But, . if you're
using the DZV/DZQ simulation with a TELNET port (which I imagine is what
most people do) then I don't think you can stop simh from accepting a
connection for lines 4..7 if the first four lines are already busy.  And if
you want to simulate a QBUS machine with 8 lines and two DVZ/DZQ cards, then
what the OS actually sees is all eight connections coming in on the first
card and none on the second card.  I haven't tried it yet, but I don't know
what the various -11 OSes will do when they get activity on lines that can't
physically exist.  Probably they use the same driver for both the DZ and DZV
so they won't care, but I don't know that.

 

>  What should happen when an odd number of DZV11's are configured and the
CPU type is changed .

 

Well, ideally there should be an error or warning message, but I imagine
that's difficult to implement.

 

  For me, I'd be happy if simh was changed to accept "SET LINES=." in
multiples of 4 rather than multiples of 8.  It's true that this would
possibly allow you to create invalid DZ configurations, but in my mind the
possibility of deliberately defining an invalid configuration is less
annoying than the impossibility of defining a valid configuration.

 

Bob

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11

I think the whole concept of deriving the number of controllers based on 
units in simh is wrong.
I think one should configure each controller separately, including being 
able to tell what CSR and vector it has, and how many units should be 
connected one way or another, and any other relevant information. 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. 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 list goes on...

  Johnny


On 2018-04-09 20:47, Mark Pizzolato wrote:

Hmmm..

This is indeed true.  The problem comes from the fact that the single 
PDP11 simulator can simulate different PDP11 models some of which are 
Unibus while others are Qbus systems.  On the various VAX simulators, 
each simulator only simulates either a Unibus or a Qbus machine and thus 
things are simpler to align and thus things appear as you would expect.


Feel free not to use the extra ports that are provided free of charge. J

Seriously, I’ll look into addressing this.  The number of DZ11/DZV11 
devices that are simulated is derived from the number of lines which are 
configured.  A problem arises when the CPU type changes between a Unibus 
and Qbus types.  What should happen when an odd number of DZV11’s are 
configured and the CPU type is changed from a Qbus type to a Unibus type?


*From:* Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of 
*Robert Armstrong

*Sent:* Monday, April 9, 2018 7:35 AM
*To:* simh@trailing-edge.com
*Subject:* [Simh] DZ11 vs DZV/DZQ11

   It appears that if you want to simulate a DZV or DZQ11 on a QBUS 
PDP11, then you have to use the UNIBUS DZ11 instead.  That’s OK, except 
that a DZ11 has 8 lines per card where as the DZV and DZQ are only 4 
lines per card.  Simh won’t let you say “SET DZ LINES=4”.  This is 
something of an issue because I want to set up my simh environment to 
exactly mimic my real hardware, and it appears that’s not possible as 
far as the DZ goes.


   Or am I missing something??

   BTW, it’s funny that “HELP DZ” in simh talks exclusively about the 
DZV11 and even says things like


… The DZV11 is a 8 line terminal multiplexor. …

That’s totally wrong…

Bob Armstrong



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh




--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DZ11 vs DZV/DZQ11