[sebhc] h17 and h8d disk images
ddl-cctech at danlan.com
Wed Sep 1 15:31:35 CDT 2004
"Dwight K. Elvey" <dwight.elvey at amd.com> wrote:
| I don't know if Dan is extracting the sector header information
|and using that to determine the order of the sector blocks
|or just reading the disk order.
I'm using the headers. Doing it any other way would make retries very
difficult. More specifically, I read an entire track (actually a track
and a half), separate the data bits from the clock bits, and begin hunting
for sectors which I scatter into a track image buffer. For each sector that
I validate I set a bit in a mask. When I finish with the raw track I check
the mask to see if I have found all 10 sectors. If I have not I re-read the
track and repeat.
|It is true that all original
|HDOS distribution disk have the natural order. This may not
|always be the case. Dan mentions in a previous mail that the
|only staggering he knew of was skewing but it was quite common
|to use a 2:1 or 3:1 interleaving on HDOS disk ( you'll note that
|my transfer program even has this option for creating disk ).
Which H17 driver supported creating interleaved formats?
| I guess the question for Dan is, do you assume that the physical
|sector order matches the logical sector order when creating
|your image files or do you map the logical sector order into
|the order used in the images?
I take the sectors as I find them but then (unless a special switch is
given to the image command) I require that the next sector header found
in the raw track image is for the current sector + 1 (mod 10) and that it
is located less than 64 bytes from the end of the previous data area. This
is a reliability measure since it is possible with these old disks for big
chunks of data to be missed as the VCO wanders out of sync. In theory
you could drop a data area and the next sector header (or more) leaving
you with the wrong data area for a given header. (When the controller
gets out of sync it usually generates long runs of 0 and I compress out
anything less than 85 before I do the FM decoding since such bytes cannot
contain valid FM data.) So if a disk were actually interleaved I would
know about as the imaging process would fail.
None of the disks I read used a physical interleave.
ddl at danlan.*com
Delivered by the SEBHC Mailing List
More information about the Sebhc