Re: [Simh] Disk info request

[Paul Koning]

> On Mar 10, 2016, at 1:31 PM, dun...@caltech.edu wrote:
> 
>> Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs  
> Delta
>> RL01   512 40 2   256   10485760  20480 10.000 MB  
> 121
>> RL02   512 40 2   512   20971520  40960 20.000 MB  
> 121
> 
> I believe the correct RL0x values should be:
> 
> RL01   256 40 2   2565242880  10240  5.000 MiB  ?
> RL02   256 40 2   512   10485760  20480 10.000 MiB  ?

That looks right.  In particular, yes, the sectors are 256 bytes. RSTS matches 
that (except that it does not use the last 20 512-byte blocks, presumably for 
the bad block table).

paul

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

Re: [Simh] Disk info request

[Henry Bent]

Here's /etc/disktab from Digital Unix 4.0D, which has info about many of
the RZ drives as well as some of the RA drives.

http://pastebin.com/XNcjEeR7

-Henry

On 10 March 2016 at 14:01, Clem Cole  wrote:

>
> On Thu, Mar 10, 2016 at 1:31 PM,  wrote:
>
>> The utility of such a list is great.  Various folks have tried to develop
>> such lists over the years, with varying success and degrees of fidelity
>> and accuracy.
>>
> ​Good point, but you might be able to start with something that has been
> around for a long time.
>
> 4.X BSD has the disktab db in section 5 of the man pages, check out:
> https://www.freebsd.org/cgi/man.cgi?query=disktab=5
>
> Seems like that data has been vetted a bit (at least for systems from the
> late '70-early 2000's)
> Source for NET2  on Warren's archives take a look for
> usr/src/etc/etc.*/*tab*
>
> The vax directory has: r[ab][68][01], rd53, rm[08][035], rp0[67] plus a
> few more. They also have a few more manufacturers in other directories. It 
> might
> be interesting to see simh use the same DB.
>
> Clem
>
> ​
>
>
>
> ___
> 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] Disk info request

[Clem Cole]

On Thu, Mar 10, 2016 at 1:31 PM,  wrote:

> The utility of such a list is great.  Various folks have tried to develop
> such lists over the years, with varying success and degrees of fidelity
> and accuracy.
>
​Good point, but you might be able to start with something that has been
around for a long time.

4.X BSD has the disktab db in section 5 of the man pages, check out:
https://www.freebsd.org/cgi/man.cgi?query=disktab=5

Seems like that data has been vetted a bit (at least for systems from the
late '70-early 2000's)
Source for NET2  on Warren's archives take a look for
usr/src/etc/etc.*/*tab*

The vax directory has: r[ab][68][01], rd53, rm[08][035], rp0[67] plus a few
more. They also have a few more manufacturers in other directories. It might
be interesting to see simh use the same DB.

Clem

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

Re: [Simh] Disk info request

[Paul Koning]

Some more notes...

> On Mar 8, 2016, at 8:47 PM, Timothe Litt  wrote:
> 
> Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs   Delta
> RK05   512 12 2   2032494464   4872  2.379 MB37

The book says "200 cylinders plus 3 spare".   I don't know what that spare 
stuff is all about.  RSTS treats it as a 200 cylinder device (4800 sectors).

> ...
> RK11   512 12 2   2032494464   4872  2.379 MB37

That's the RK05 ("RK11" designates the controller, not drive)

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

Re: [Simh] Disk info request

[dundas]

>  Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs  
Delta
>  RL01   512 40 2   256   10485760  20480 10.000 MB  
121
>  RL02   512 40 2   512   20971520  40960 20.000 MB  
121

I believe the correct RL0x values should be:

 RL01   256 40 2   2565242880  10240  5.000 MiB  ?
 RL02   256 40 2   512   10485760  20480 10.000 MiB  ?

The utility of such a list is great.  Various folks have tried to develop
such lists over the years, with varying success and degrees of fidelity
and accuracy.  Perhaps a document on the SIMH site or in a community
editable form (Wikipedia?) would be useful to coalesce and supersede the
individual efforts?

Since Delta is file-system specific, maybe a separate table for the
various DEC files systems that have device-specific parameters would be
appropriate?

John

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

Re: [Simh] Disk info request

[dundas]

Timothe,

> In the process of debugging the ODS2 utility, it became clear that the
> disk geometry really does matter.
> And it's not available in simulator images -- or even for physical
> devices -- at runtime.

I've done quite a bit of hacking with ods2, at least enough to get it to
do what I want.  What do you want it do to?

Disk geometry isn't needed to read files on an ODS-2 volume IFF the first
home block is intact.  Indeed, if the first home block is damaged and you
need to find another, you need to initialize a disk, you want to read an
ODS-5 volume, or some other operations, you may need the geometry.  If the
home block is good, it points to everything else needed to read a
non-corrupted image.  If you can get that far, the SCB in the BITMAP.SYS
file does contain the geometry (at least the parameters VMS initialized
the volume with).

John

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

Re: [Simh] Disk info request

[Ethan Dicks]

On Wed, Mar 9, 2016 at 3:02 PM, Rich Alderson
 wrote:
> Shugart Associates introduced Shugart Associates System Interface ("SASI")
> privately in 1978, publicly in 1981.  This was standardized by ANSI as the
> Small Computer System Interface in 1982; doesn't anyone else here remember the
> "sassy/sexy" vs. "scuzzy" mini-war?

I do.

Apple products were "sexy" not "scuzzy"... for a while.  Then they
gave up trying to control the word.

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

Re: [Simh] Disk info request

[Rich Alderson]

> From: Timothe Litt 
> Date: Tue, 8 Mar 2016 20:47:45 -0500

> Below is a list of all the disks that have been used with FILES-11 (ODS2) for
> which I have reliable (I think) data.

> The list has blank spots for a lot of disks that I know exist, but for which I
> don't have reliable data.

> Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs   Delta
> *RA80 - -- - - -- -- --
> *RA81 - -- - - -- -- --
>  RA82   512 5715  1435  6281856001226925599.084 MB   913

I can provide some information about the hardware values, based on the table at
Phil Budne's site (http://www.ultimate.com/phil/pdp10/dec.disks).

The RA80 has 31 sectors/track, 14 tracks/cylinder, and 546 cylinders.  On the
PDP-10, this gets you 124MB in 576-byte sectors.

The RA81 has 51 sectors/track, 14 tracks/cylinder, and 1248 cylinders.  This
gets you 446MB.

For comparison, the RA82 is listed as providing 608MB in 1423 cylinders, so the
PDP-10 habit of not using all the cylinders on a pack or HDA appears to hold
true for the MSCP disks as well.

Not exactly what Tim was looking for, but useful for comparison, I should think.

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

Re: [Simh] Disk info request

[Rich Alderson]

> From: Clem Cole 
> Date: Wed, 9 Mar 2016 12:04:30 -0500

> On Wed, Mar 9, 2016 at 11:16 AM, Johnny Billquist  wrote:

>> I suspect MSCP came before SCSI.

> I agree.   In DEC's case, support for MSCP certainly was first, but I
> believe the protocols are contemporaries. NCR was a very early SCSI player,
> but Western Digital, Shugart or someone like that might have driven it
> originally (I've forgotten - I have some early SCSI docs at home, I
> think).  I forget when I first saw it.

Shugart Associates introduced Shugart Associates System Interface ("SASI")
privately in 1978, publicly in 1981.  This was standardized by ANSI as the
Small Computer System Interface in 1982; doesn't anyone else here remember the
"sassy/sexy" vs. "scuzzy" mini-war?

The date on the UDA50 manual appears to be 1982, so yes, contemporaneous.

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

Re: [Simh] Disk info request

[Johnny Billquist]

On 2016-03-09 17:12, Paul Koning wrote:



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


Yes, some controllers require the host to be involved in the bad block 
replacement process. But the blocks are still addressed just as LBNs. No 
proper exposure to the geometry... Well, it's complicated by the fact 
that there are primary and secondary replacement blocks, and the primary 
replacement block is on the same track, which means when you want to 
find a block to use as replacement, you need to find out if the primary 
is unallocated or not. But apart from that RBNs are numbered 
sequentially, just like the normal blocks. And you don't properly care 
about geometry as such.



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.


Thanks for reminding me. Yes, MSCP can give you a geometry information 
for the disk. Note that the information might not reflect reality. The 
controller and disk is free to lie or make things up, if it thinks it is 
better.


However, you should always get the same values for the same hardware. 
And, this is where it gets tricky, I would expect VMS to actually figure 
out the replacement home block locations based on the geometry reported 
by the MSCP controller, which means that what Timothy Litt really wants 
is this information, and not the actual disk geometry.



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.


It appears pretty clear in the UDA50 documentation that DEC did 
provision for the possibility in MSCP, even if no disks they made at 
that point had this property.



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.


Right. Totally in agreement.
And, as touched on before, RSX do not care about geometry either.

Johnny

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

Re: [Simh] Disk info request

[Johnny Billquist]

On 2016-03-09 18:04, Clem Cole wrote:


On Wed, Mar 9, 2016 at 11:16 AM, Johnny Billquist > wrote:

I suspect MSCP came before SCSI.


I agree.   In DEC's case, support for MSCP certainly was first, but I
believe the protocols are contemporaries. NCR was a very early SCSI
player, but Western Digital, Shugart or someone like that might have
driven it originally (I've forgotten - I have some early SCSI docs at
home, I think).  I forget when I first saw it.


Whoa, Clem! Careful with those quotes, please...
The full text was: "That is also the case with MSCP... Not sure if it 
predated SCSI, but for Unix systems, I suspect MSCP came before SCSI. "


In short - I said I don't know which of MSCP and SCSI was first, but I 
believe that for *Unix* systems, MSCP was seen first, based on the fact 
that Unix was running on DEC systems, which had MSCP before SCSI.


Johnny

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

Re: [Simh] Disk info request

[Clem Cole]

On Wed, Mar 9, 2016 at 11:16 AM, Johnny Billquist  wrote:

> I suspect MSCP came before SCSI.


I agree.   In DEC's case, support for MSCP certainly was first, but I
believe the protocols are contemporaries. NCR was a very early SCSI player,
but Western Digital, Shugart or someone like that might have driven it
originally (I've forgotten - I have some early SCSI docs at home, I
think).  I forget when I first saw it.


I do know NCR's SCSI 54C30 (and later the *C700) chip set became the de
facto standard  and they were early UNIX adopters.  Plus the aftermarket
folks were using "industry standard" interfaces on the drive side and just
replicating the Massbus or whatever on the host side for SW compliance.
 BSD Unix in particular was birthed using aftermarket I/O for cost reasons
 - i.e. most of the system we had a Berkeley (and other University sites)
had SI or Emulex controllers, not real DEC ones. Ultrix inherited all
of the support from BSD, but the code was written by the CSRG folks in the
late 70's early 80's.

While using when DEC supported a technology works as a good first order
system and certainly for DEC developed ones, the bottom line is that SCSI
was on other systems that came from the rest of industry long before DEC
picked it up.  Thus we have to be careful dating things by using when DEC
brought out support.

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

Re: [Simh] Disk info request

[Bill Cunningham]

  - Original Message - 
  From: Paul Koning 
  To: Johnny Billquist 
  Cc: simh@trailing-edge.com 
  Sent: Wednesday, March 09, 2016 11:12 AM
  Subject: Re: [Simh] Disk info request


  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.  

  Ok well sorry to interrupt, but where is a "UDA50" directory on bitsavers. I 
am not finding it.

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

Re: [Simh] Disk info request

[Johnny Billquist]

On 2016-03-09 17:10, Clem Cole wrote:


Anyway, a few things changed... local caches were introduced on the
drive, which mitigated a lot of what UNIX was doing because they did
their own arm scheduling.   Plus drive manufacturing got better at
packing sectors, so when before the max number of sec/cyl was a fixed
amount, the larger drives now sec/cyl changed depending on the drive.
  Much less the whole bad block stuff would screw up all the OS work.
Finally,  SCSI introduce the idea of a single Logical disk block (i.e.
the disk was just a linear array of blocks) and all the scheduling was
left to the controller microcode (i.e. a dumb OS was better than one
that tried to out smart the controller).


That is also the case with MSCP... Not sure if it predated SCSI, but for 
Unix systems, I suspect MSCP came before SCSI.
(And is the reason why I ask if VMS really try to figure out geometry 
for MSCP, since it don't really make much sense, or even can be done 
accurately, depending on the disk.)


Johnny

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

Re: [Simh] Disk info request

[Paul Koning]

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

Re: [Simh] Disk info request

[Clem Cole]

On Wed, Mar 9, 2016 at 10:46 AM, Mark Pizzolato  wrote:

> I explicitly recall on Ultrix contriving entries in
> /etc/disktab to describe arbitrarily sized disks connected to 3rd party
> MSCP controllers.  The info in /etc/disktab is used by the file system
> creation code to lay down the file system data structures scattered
> around the disk surface based on some relationship of the presumed
> geometry that was described.
>

​right -- when Leffler wrote "newfs" which was the front end replacement
for mkfs and bunch of other utilities, disks were still "geometry
oriented"​ and a lot of work in FFT (aka UFS) had gone into trying let the
kernel know about the actual geometry being used, so better seek scheduling
could be done.At the time there was ton of research being done in the
area (if you look at the USENIX papers - you find a couple including one or
two with my name of them).

Anyway, a few things changed... local caches were introduced on the drive,
which mitigated a lot of what UNIX was doing because they did their own arm
scheduling.   Plus drive manufacturing got better at packing sectors, so
when before the max number of sec/cyl was a fixed amount, the larger drives
now sec/cyl changed depending on the drive.Much less the whole bad
block stuff would screw up all the OS work. Finally,  SCSI introduce the
idea of a single Logical disk block (i.e. the disk was just a linear array
of blocks) and all the scheduling was left to the controller microcode
(i.e. a dumb OS was better than one that tried to out smart the controller).

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

Re: [Simh] Disk info request

[Johnny Billquist]

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.

Johnny


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

Re: [Simh] Disk info request

[hb]

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.


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

Re: [Simh] Disk info request

[Mark Pizzolato]

On Wednesday, March 9, 2016 at 7:39 AM, Paul Koning wrote:
> > On Mar 8, 2016, at 8:47 PM, Timothe Litt  wrote:
> >
> > In the process of debugging the ODS2 utility, it became clear that the
> > disk geometry really does matter.
> > And it's not available in simulator images -- or even for physical
> > devices -- at runtime.
> >
> > Below is a list of all the disks that have been used with FILES-11
> > (ODS2) for which I have reliable (I think) data.
> 
> I see a list in PDP11/pdp11_rq.c showing geometry information for a large
> number of MSCP drives.
> 
> One puzzle is the RD52.  In the PRO at least, there are several different 
> drives
> (different manufacturers with different numbers of heads.  The entry you
> have seems to be the one for the Quantum (8 head) variant rather than Atasi
> (7 head).
> 
> > RD52   512 17 8   512   35651584  69632 34.000 MB   154

Well, there are many definitions for various MSCP drive types, but looking 
through the code shows that the only place the geometry info is actually 
referenced is in error paths which presumably don't normally happen.  The 
drive type and total size (in sectors) is passed into the simulated system 
when devices are probed for, but it seems that the OS gets to leverage 
that info by some programmatic or manual means as it sees fit.  I say 
'manual' here since I explicitly recall on Ultrix contriving entries in 
/etc/disktab to describe arbitrarily sized disks connected to 3rd party 
MSCP controllers.  The info in /etc/disktab is used by the file system 
creation code to lay down the file system data structures scattered 
around the disk surface based on some relationship of the presumed 
geometry that was described.

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

Re: [Simh] Disk info request

[Paul Koning]

> On Mar 8, 2016, at 8:47 PM, Timothe Litt  wrote:
> 
> In the process of debugging the ODS2 utility, it became clear that the
> disk geometry really does matter.
> And it's not available in simulator images -- or even for physical
> devices -- at runtime.
> 
> Below is a list of all the disks that have been used with FILES-11
> (ODS2) for which I have reliable (I think) data.

I see a list in PDP11/pdp11_rq.c showing geometry information for a large 
number of MSCP drives.  

One puzzle is the RD52.  In the PRO at least, there are several different 
drives (different manufacturers with different numbers of heads.  The entry you 
have seems to be the one for the Quantum (8 head) variant rather than Atasi (7 
head).

> RD52   512 17 8   512   35651584  69632 34.000 MB   154

paul


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

[Simh] Disk info request

[Timothe Litt]

In the process of debugging the ODS2 utility, it became clear that the
disk geometry really does matter.
And it's not available in simulator images -- or even for physical
devices -- at runtime.

Below is a list of all the disks that have been used with FILES-11
(ODS2) for which I have reliable (I think) data.
The list has blank spots for a lot of disks that I know exist, but for
which I don't have reliable data.

What matters are the sector size (usually 512), sectors/track, tracks
(surfaces)/cylinder, and number of
cylinders.  The other columns are computed (and informational).

I have two requests:

1) If you see any errors, please let me know.  Gathering this was a
manual process.
2) If you have data for other disks **USED FOR FILES-11 ODS-2**, please
let me know.
I know there were 3rd-party disks that weren't exact clones of the
DEC disks

FYI: (and to avoid the inevitable questions)
 * I do know about the pdp-10 format for Massbus disks shared with the
front end. ODS-1.
 * Delta is the distance between HOM blocks for the given geometry
 * Capacity is in bytes.
  * For this exercise, I need the geometry as presented to the OS, not
the internal organization
E.g. some DSA disks have spare sectors, but (as far as I know),
these aren't accounted for
when a volume is initialized.  If you have a physical disk (or image
of one), it's possible
to resolve ambiguities by dumping block 1.  (e.g. on VMS,
dump /block=(start=1,count=1) dka100:)
 * Most "modern" OSs lie about geometry - to fit into small fields in
the BIOS reports, or
because it just doesn't matter to them.  There's no
reliable/portable way to "just ask the
host OS" - or even the hardware.

Thanks.

 Name SecSiz Sec/Tk Tk/Cy Cyls   Capacity   LBNs   Delta
 RK05   512 12 2   2032494464   4872  2.379 MB37
 RK06   512 22 3   411   13888512  27126 13.245 MB89
 RK07   512 22 3   815   27540480  53790 26.265 MB89
 RK11   512 12 2   2032494464   4872  2.379 MB37
 RL01   512 40 2   256   10485760  20480 10.000 MB   121
 RL02   512 40 2   512   20971520  40960 20.000 MB   121
 RM02   512 32 5   823   67420160 131680 64.297 MB   193
 RM03   512 32 5   823   67420160 131680 64.297 MB   193
 RP04   512 2219   411   87960576 171798 83.886 MB   441
 RP05   512 2219   411   87960576 171798 83.886 MB   441
 RM80   512 3114   559  124214272 242606118.460 MB   466
 RP06   512 2219   815  174423040 340670166.343 MB   441
 RM05   512 3219   823  256196608 500384244.328 MB   641
 RP07   512 5032   630  5160960001008000492.188 MB  1651
 RX50   512 10 180 409600800  0.391 MB11
 RX33   512 15 2801228800   2400  1.172 MB46
*RD50 - -- - - -- -- --
 RD51   512 18 4   306   11280384  22032 10.758 MB91
 RD31   512 17 4   615   21411840  41820 20.420 MB86
 RD52   512 17 8   512   35651584  69632 34.000 MB   154
 RD53   512 17 7  1024   62390272 121856 59.500 MB   137
 RD54   512 1715  1225  159936000 312375152.527 MB   273
 RA82   512 5715  1423  6229324801216665594.075 MB   913
 RA72   512 5120  1921 10032230401959420956.748 MB  1072
*RA80 - -- - - -- -- --
*RA81 - -- - - -- -- --
 RA82   512 5715  1435  6281856001226925599.084 MB   913
 RA90   512 6913  2649 12165903362376153   1160.231 MB   967
 RA92   512 7313  3099 15057669122940951   1436.011 MB  1023
 RRD40  512128 1 10400  6815744001331200650.000 MB   129
 RRD50  512128 1 10400  6815744001331200650.000 MB   129
 RX01   128 26 177 256256500  0.244 MB 7
 RX02   256 26 177 512512   1001  0.489 MB14
*RX23-SD  - -- - - -- -- --
*RX23-DD  - -- - - -- -- --
 RX33-SD512 10 180 409600800  0.391 MB11
*RX33-DD  - -- - - -- -- --
 RX50   512 10 180 409600800  0.391 MB11
*RC25 - -- - - -- -- --
*RF30 - -- - - -- -- --
*RF31 - -- - - -- -- --
*RF35 - -- - - -- -- --
*RF36 - -- - - -- --