[sebhc] h17 and h8d disk images

[Dan Lanciani]

"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.

				Dan Lanciani
				ddl at danlan.*com
--
Delivered by the SEBHC Mailing List