> On Mar 9, 2016, at 10:55 AM, Johnny Billquist <b...@softjar.se> wrote:
>
> On 2016-03-09 16:50, hb wrote:
>> On 03/09/2016 09:53 AM, Johnny Billquist wrote:
>>> Do VMS and ODS-2 really try to figure out a geometry per disk for MSCP
>>> disks???
>>
>> The ODS2 utility needs to "mount" the disk. I know nothing, but ODS-2 on
>> VMS probably only cares about LBNs and VBNs (and on on-disk data
>> structures). It is the mount utility which knows or needs to know the
>> geometry, to do the geometry based search for alternate home blocks
>> (there is also a non-geometry based search algorithm). And the mount
>> utility probably uses the same code as the init utility, which writes
>> the alternate home blocks. And both probably request the information
>> from some other (driver) code level.
>
> Right. But I would have assumed that VMS would just create some fake concept
> of what the geometry is for an MSCP disk, since it don't really make sense to
> try and figure out the geometry in the first place. Or at least that is my
> understanding.
>
> There is no guarantee that there even is any "sane" geometry.
I long ago forgot the details, but a look at the MSCP Basic Functions manual
(on Bitsavers in the uda50 directory) is helpful. See page 4-25 and the next
couple.
Yes, the basic addressing is LBA addressing. Some early MSCP drives exposed
bad sector handling to the host at least with the UDA, and I remember the large
amount of work that had to be done in RSTS for this. Soon that was moved into
the controllers.
Anyway, that section (starting at page 4-27) describes mapping the LBA into 4
values: sector, track, group, and cylinder -- as a way to expose the
performance aspects. It says that the Get Unit Status command fetches that
data. it also says (page 4-28) that "this is a model for logical geometry,
which may have only a tenuous relationship with the disks's actual physical
geometry" and that it's up to the designer to report a logical geometry that is
useful to the host. The idea is that it should let the host make performance
optimization choices, as described in that section.
And yes, some aspects of newer drives aren't handled well at all -- for
example, drives with varying number of sectors per track as you move from outer
to inner cylinders. When MSCP was designed I don't think those existed (at
least not in DEC; CDC did it way back in the early 1960s on the 6603 drive).
The first time I heard of variable sector counts at DEC was in CDROMs.
So as far as the question here is concerned, it sounds like ODS2 would base its
placement on the "logical" geometry reported by MSCP, and for a standalone ODS2
utility to get that right would require it to have a table of geometries
matching what MSCP controllers reported. And for that matter, for SimH device
formatting to be compatible with that of the real hardware, the geometries
reported in SimH would need to match the originals. I assume the tables in
pdp11_rq.c are based on the original numbers, but I can't confirm that. I
never ran into any of this; RSTS was quite happy with LBA addressing and left
"logical geometry" as an entertaining concept it could completely ignore.
paul
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
