Re: [Simh] DZ11 vs DZV/DZQ11

[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

[Simh] Terminal mux structure(s) (was DZ vs DZV)

[Bob Supnik]

The original DZ emulator was originally written by a contributor. He 
chose a model whereby lines were not explicitly represented by units. In 
fact, even multiple controllers were not explicitly represented. This 
model was followed in some other emulators, such as the DHU/V11 and the 
NOVA QTY.


When I started writing terminal multiplexors, I was working with devices 
that were essentially multiple instances of the same simple interface, 
such as the LT15, DL11, and so on. I chose to have a unit per line, but 
still only one (SIMH-visible) controller. This allowed fine-grained 
granularity over the number of lines. I carried this model over to 
"real" terminal multiplexors on the IBM 7094, SDS systems, and so on.


Both models seem to work or can be made to work. Neither creates a 
SIMH-visible controller per real controller.


With respect to the DZ11/DZV11, I expect it would be possible to 
parameterize the "lines per controller" math and make it U/Q sensitive. 
If the CPU model is changed mid-simulation, there would be significant 
trauma to any running software, but users should realize there will 
trouble if they change a CPU on the fly.


Unless configuration limitations prevent some family of software from 
running, I don't regard the limitations as significant.


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

Re: [Simh] DZ11 vs DZV/DZQ11

[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

[Johnny Billquist]

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

[Johnny Billquist]

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

[Johnny Billquist]

On 2018-04-12 02:41, Mark Pizzolato wrote:

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

On 2018-04-10 10:26, Mark Pizzolato wrote:

On Monday, April 9, 2018 at 11:51 PM, Johnny Billquist wrote:

On 2018-04-10 00:25, Mark Pizzolato wrote:

[...]

Some OSes leverage the encoded value to correspond specifically with a
particular model of DEC disk and run from there potentially presuming details
about disk size or geometry.


I certainly hope not. Like I said, this is cosmetic. MSCP reports disk size 
directly,
and the id is just for information. Anything that is mad enough to assume size
based on the id instead of the size reported by the device would be some
seriously broken software.


Well, most of the third party MSCP controllers provided a constant Media ID that
identified the drive as an RA81.  In general, since that was really cosmetic it 
shouldn't
have mattered.  I vaguely recall that some Ultrix file system generation logic 
used
the drive type to determine presumed values for the disk geometry for cylinder
boundary alignment, but no matter what that choice really didn't matter.


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


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



The arbitrary sized disk actually uses the RA82 encoded value for its Media ID.
This is ONLY when the disk is created.  When a disk is subsequently attached,
whatever drive type is either default OR explicitly specified with a SET RQn
RA90 (or one of the many other choices in the list) is what the drive type ends
up as when the media id is passed to the OS.  Current Simh RQ devices autosize
and don't worry about the default size that a particular drive type originally
started as.


Like I said, this is cosmetic. It just looks very silly to have a disk reported 
as
being an RA81 (or whatever) when the disk is in fact no such thing. And since
the ID can contain any kind of name within the limitations on such names,
there isn't really a good reason why it would be limited to such a small set as 
it
currently is.


DEC controllers only connected DEC drives, so the current simulation behavior
is consistent with how things worked originally.  I don't recall any third party
MSCP controllers which let the user tweak what Media ID was reported for
each drive.


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


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



But my point was/is that MSCP was designed to explicitly avoid such
silly limitations. An MSCP controller can support any number of disks.
The actual UDA50 and KDA50 only had four connectors for disks, which is the
reason for that limit. Other controllers could just as well have a different
number. From a programming point of view, it would be no difference. That's
one of all the nice things about MSCP.


Absolutely, but the only DEC hardware which supported more than 4 disks
was HSC stuff and that is not what we're talking about here.


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



So we are artificially limiting ourself to four disks because some DEC 
controllers
only had four connectors. The MSCP protocol have no such limit, and neither
does the software.


Right, but we are simulating real hardware that existed.


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


You can without problem generate an RSX system where you have 16 disks
on one MSCP controller, if you want to.


Sure, you could SYSGEN that setup, but you couldn't buy hardware that worked
that way AND if you could you couldn't afford the electricity needed to run it. 
:-)


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



As it turns out, in the PDP11 simulator, device RQ has 4 units which start at 0.
Device RQB has 4 units (RQB0, RQB1, RQB2 and RQB3) which have unique
MSCP unit numbers (4, 5, 6 and 7). Device RQC has 4 units (RQC0, RQC1, RQC2
and RQC3) which have unique MSCP unit numbers (8, 9, 10 and 11). Device
RQD has 4 units (RQD0, RQD1, RQD2 and RQD3) 

Re: [Simh] DZ11 vs DZV/DZQ11

[Johnny Billquist]

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

[Simh] Configuration limitations

[Bob Supnik]

SimH's intended purpose was to run historical software in furtherance of 
computer education. It was not intended as a perfectly accurate 
emulation of every detail of every architecture. There are compromises 
in the design to simplify implementation.


One of those, dating back to its progenitor, MIMIC, is the use of PMS 
(processor-memory-switch) notation, which simplifies IO into controller 
and units. It doesn't really support the notion of nested controllers, 
which is what the Massbus actually requires: a Massbus controller (RH) 
connected up to a maximum of eight subcontrollers (for an RP06, the 
DCL), which is turn connected to one (or for tapes, more than one) unit.


Originally, the Massbus devices were modeled as a controller and units 
(the KS10 simulator still does that). That proved unsatisfactory, 
because it required extensive code duplication between the VAX and the 
PDP11, and between Massbus disks and Massbus tapes. So a while back, the 
RH controllers were split out, and a system-specific hack put in place 
to associate the "independent" RP controller with a Massbus channel. The 
RP controller was not restructured as eight independent controllers with 
one unit each. It remained a quasi-standard disk device, with one 
controller and eight units. As a result, the RP can only be associated 
with a single Massbus channel.


The software changes to get "accuracy" are fairly intrusive.

1. Change the RP to be 'n' separate controllers of one unit each.
2. Change the RH controller to allow a different device for each device ID.
3. Allow each separated controller to be assigned to a MB channel 
independently, based on device ID.


Enforcing configuration restrictions (for example, no mixing of disks 
and tapes on the same channel) is yet more work.


A simpler hack would be to replicate the RP controller, allowing for up 
to 16 drives in two strings. Each string could be associated with a 
different MB channel. The 'generalization' of a controller to support 
multiple instances is shown in the MSCP disks and in the RH controller 
itself.


/Bob

On 4/12/2018 4:34 PM, simh-requ...@trailing-edge.com wrote:

But we are far from being true to the original hardware, so trying to
use that as an argument I think is really weak. Or else we should really
allow me to set CSRs arbitrarily when I have several controllers, allow
me to setup two RP06 on different Massbus channels, and so on. That
would be true to the original hardware. And the same with claiming to
not want to do something because DEC didn't provide it, when obviously
3rd party manufacturers did.


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

Re: [Simh] DZ11 vs DZV/DZQ11

[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

[Johnny Billquist]

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] Configuration limitations

[Johnny Billquist]

On 2018-04-12 23:49, Bob Supnik wrote:
SimH's intended purpose was to run historical software in furtherance of 
computer education. It was not intended as a perfectly accurate 
emulation of every detail of every architecture. There are compromises 
in the design to simplify implementation.


Yeah. I noticed. :-)
And don't get me wrong. I don't mind simplifications and shortcuts in 
places. I'm not trying to blame or point fingers. I'm merely asking that 
we try to be pragmatic. So for MSCP, for example, since there is no good 
reason to limit the number of disks to four, why do that. Just because 
DEC didn't happen to make a controller with more than four connectors? 
That would appear to me to be a poor reason for such a limitation.


One of those, dating back to its progenitor, MIMIC, is the use of PMS 
(processor-memory-switch) notation, which simplifies IO into controller 
and units. It doesn't really support the notion of nested controllers, 
which is what the Massbus actually requires: a Massbus controller (RH) 
connected up to a maximum of eight subcontrollers (for an RP06, the 
DCL), which is turn connected to one (or for tapes, more than one) unit.


Right. And even more fun with tapes, who can have slave units...

Originally, the Massbus devices were modeled as a controller and units 
(the KS10 simulator still does that). That proved unsatisfactory, 
because it required extensive code duplication between the VAX and the 
PDP11, and between Massbus disks and Massbus tapes. So a while back, the 
RH controllers were split out, and a system-specific hack put in place 
to associate the "independent" RP controller with a Massbus channel. The 
RP controller was not restructured as eight independent controllers with 
one unit each. It remained a quasi-standard disk device, with one 
controller and eight units. As a result, the RP can only be associated 
with a single Massbus channel.


The software changes to get "accuracy" are fairly intrusive.

1. Change the RP to be 'n' separate controllers of one unit each.
2. Change the RH controller to allow a different device for each device ID.
3. Allow each separated controller to be assigned to a MB channel 
independently, based on device ID.


Yes. I expect it would be some significant amount of work. In this case, 
I think that could be useful, but I'm not going to hold my breath for 
this to happen.


Enforcing configuration restrictions (for example, no mixing of disks 
and tapes on the same channel) is yet more work.


Uh... Which should not be done to start with. From a hardware point of 
view it is perfectly legal to mix tapes and disks on the same massbus. 
Most OSes did not support that, but RSX-11M-PLUS actually do. It's 
called a mixed massbus.


A simpler hack would be to replicate the RP controller, allowing for up 
to 16 drives in two strings. Each string could be associated with a 
different MB channel. The 'generalization' of a controller to support 
multiple instances is shown in the MSCP disks and in the RH controller 
itself.


Not sure what the point would be though. If you'd redesign devices, 
including massbuses, to work the same way as actual hardware, that would 
be a good thing. Replacing one specialized solution with a different one 
just moves us from one set of restrictions to another.


Actually, nesting devices would be really nice. It would also allow us 
to properly do such things as bus adapters, with other bus adapters 
inside, and then controllers inside that, such as you actually will find 
on VAXens, for example.


But, as noted, this would be a rather big change.

  Johnny



/Bob

On 4/12/2018 4:34 PM, simh-requ...@trailing-edge.com wrote:

But we are far from being true to the original hardware, so trying to
use that as an argument I think is really weak. Or else we should really
allow me to set CSRs arbitrarily when I have several controllers, allow
me to setup two RP06 on different Massbus channels, and so on. That
would be true to the original hardware. And the same with claiming to
not want to do something because DEC didn't provide it, when obviously
3rd party manufacturers did.


___
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