> On Apr 11, 2018, at 8:41 PM, Mark Pizzolato <m...@infocomm.com> 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
