[Coco] Identification Sector (LSN 0)

Gene Heskett gheskett at wdtv.com
Sun Oct 20 23:53:45 EDT 2013


On Sunday 20 October 2013 22:49:17 Robert Gault did opine:

> Luis Fernلndez wrote:
> > I need a little help
> > Sector Identification in (LSN 0) in NitrOS-9.VHD
> > DD.OPT $ 3F Path descriptor options
> > I need to know that there are from $ 3F to $ FF
> > is supposed to be the The RBF Manager Definitions of the Path
> > Descriptor
> > 
> > 
> > 
> > 
> > I fail per $5A align with who I think are the 90 cylinders
> > since they are $ 5A * $ 40 Tracks * $ 40 Sectors = $5A000
> > Size of partition ? = $5A000 * 256 Bytes Per Sectors = $5A00000
> 
> "The RBF manager Option Section Definitions (PD.OPT Section)
> (copied fromm the device descriptor)
> PD.DTP  $20   1     1=RBF
> PD.DRV  $21   1     Drive # 0..n
> PD.STP  $22   1     Step rate
> PD.TYP  $23   1     Device type
> PD.DNS  $24   1     Density
> PD.CYL  $25   2     # of cylinders (tracks)
> PD.SID  $27   1     number of sides
> PD.VFY  $28   1     0=verify writes
> PD.SCT  $29   2     sectors per track
> PD.T0S  $2B   2     sectors per track0
> PD.ILV  $2D   1     sector interleave
> PD.SAS  $2E   1     segment allocation size
> PD.TFM  $2F   1     DMA transfer mode
> PD.EXTEN$30   2     path extension
> PD.STOFF$32   1     sector/track offsets
> PD.ATT  $33   1     file attributes
> PD.FD   $34   3     file descriptor PSN
> PD.DFD  $37   3     directory file descriptor PSN
> PD.DCP  $3A   4     file directory pointer
> PD.DVT  $3E   2     address of device table
> 
> The above are in the RBF Path descriptor but were taken from the drives
> LSN0 starting at $3F. That means in LSN0 the above runs from $3F to
> $5E.
> 
> Your math is correct. DD.TOT=$5A000 sector and in the DD.OPT section
> there are $5A cylinders(tracks), $40 "sides", and $40 sectors per
> track.
> $5A*$40*$40=$5A000 and at $100 bytes per sector $5A00000 bytes in the
> OS-9 section of the .vhd image.
> 
While such an explanation is mathematically correct, its also blowing off 
and ignoring the fact that modern drives are in fact variable length track 
drives, according to the physical length of the track, so the inner, 
shorter length tracks have fewer sectors.  This has been true for at least 
20 years now. The drive itself has no concept of track number, head number, 
or sector number in that track.  It does internal math, based on its 
internal knowledge of how the tracks are laid out on the platters to arrive 
at the correct track/head/sector that equals the LSN requested by the 
driver in the computer.

The net result is that at the data down the cable to the drive point, the 
drive is being asked for the contents of sector $1BB37.  The driver, 
running on the coco, will get the contents of that sector, and if dumb, 
will use only the first 256 bytes, but if smart, will ask for the contents 
of $DD9B instead, and hand os9 the contents of the top half of that 512 
byte sector as the data from $1BB37, effectively using all 512 bytes of the 
hard drives fixed 512 byte sector..

But lets get down to what the coco, running nitros9 today can do with that.
1. see, from your nitros9 hg pull, nitros9/level1/modules/superdesc.asm
scan down in this file to see this:
* Super Driver specific additions to the device descriptor go here
* NOTE: These do NOT get copied into the path descriptor; they
*       cannot due to the fact that there is simply NO ROOM in
*       the path descriptor to do so.  The driver must access
*       these values directly from the descriptor.
               FCB       ITSOFS1             (IT.WPC)
               FCB       ITSOFS2             (IT.OFS)
               FCB       ITSOFS3

Note that as you see it in the dmode output, wpc is a single byte, and that 
ofs is actually an integer.
For all actual floppies, these 3 bytes are zero'd.

But, back up in that file a bit to IT.STP and see
* IT.STP (offset $14)
*  Bit Meaning
*  --- ---------------------------------------------------------------
*  7-0 HDB-DOS Drive Number (useful only if HDB-DOS bit set in IT.DNS)
*
* IT.TYP (offset $15)
*  Bit Meaning
*  --- ---------------------------------------------------------------
*  7   Hard Disk:  1 = hard disk
*  6   Fudge LSN0: 0 = OS-9 disk, 1 = non-OS-9 disk
*  5   Undefined
*  4   Drive Size Query (1 = yes, 0 = no)
*  2-3 Undefined
*  0-1 Sector Size (0 = 256, 1 = 512, 2 = 1024, 3 = 2048)
*
* IT.DNS (offset $16) for SCSI Low Level Driver
*  Bit Meaning
*  --- ---------------------------------------------------------------
*  5-7 SCSI Logical Unit Number of drive (0-7) (ignored if bit 3 is 1)
*  4   Turbo Mode:  1 = use accelerated handshaking, 0 = standard
*  3   HDB-DOS Partition Flag
*  0-2 SCSI ID of the drive or controller (0-7)
*
* IT.DNS (offset $16) for IDE Low Level Driver
*  Bit Meaning
*  --- ---------------------------------------------------------------
*  4-7 Undefined
*  3   HDB-DOS Partition Flag
*  1-2 Undefined
*  0   IDE ID (0 = master, 1 = slave)

Where a whole bunch of potentially confusing bits manage to switch what 
other bits mean around, such that the stp value, which means nothing to a 
hard drive, is cleverly reassigned to be the number, $00/$FF (0/255) of the 
virtual floppy to be accessed on that hard drive.

Taking my own 1Gb seagate scsi drive (ide works the same but with a 2 drive 
limit where I could go to 7, but I only have 2 hooked up) the size of the 
os9 partition on this drive is (IIRC) $1DDB90, or in bytes 500,928,512.
Because that is a base 0 number, the size (DD.SIZ) in lsn0 of THAT drive is 
actually $1DDB8F.

But, now using the /sh.dd descriptor, I use dmode to set wpc to $1D, and 
ofs to $DB90, which tells the driver the address of first sector of the 
HDB-DOS partition ON THIS DRIVE!

Now, assume that stp is set to $80, and that bit 3 of dns is set to one.
The driver will now do 2 things, first being that it will add the wpc-ofs 
values to the calculated or read from the directory entry of the file 
wanted, then multiply the stp=$80 by 630 sectors to obtain the actual 
Logical Sector Number address on the drive of the file you want from the 
HDB-DOS virtual drive 128 or $80.

You can change the virtual drive to any HDB-DOS virtual drive using only 
the dmode /sh stp=hex value command, and if ded was used to make a copy of 
sh.dd named si.dd both as the file, and internally, and that descriptor was 
then built into an os9boot file, you just made the slickest yet way to 
backup any drive to any drive.  Set the stp's to the drives you want to 
backup, and "backup /sh /si #40k"

No magic, no holding a chaw of kentucky twist just so, or anything but pure 
integer math.  It works a treat.  I can mount, in the drivewire server, one 
of the images (.dsk's) from my nitros9 build, run a script that customizes 
3 descriptors in that image by overwriting them with my own and copies my 
bootlists etc to that image, and run the customized mb, directing it to the 
/sh descriptor, and have a new boot made & ready to type reboot so it does 
a cold boot from vdisk 128, all in about a minute 30.

Now, does that help, or am I still gonna have to write the book? ;-)


> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)

I just got my PRINCE bumper sticker ... But now I can't remember WHO he is 
...
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.



More information about the Coco mailing list