[Simh] Disk info request

[Paul Koning]

> On Mar 9, 2016, at 10:55 AM, Johnny Billquist <bqt at 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