FDC Gap Length?

[Allison]

>
>Subject: Re: FDC Gap Length?
>   From: Dave Dunfield <dave04a at dunfield.com>
>   Date: Sun, 17 Jul 2005 07:28:45 -0400
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi Allison,
>
>>Is there a calculation, NO. Unless your formatting your own, then 
>>it's use biggest gaps that allow sector data and a resonable end gap
>>on off speed drives.   Most of the time you have to know how 
>>that disk was formatted originally to arrive at the correct values.
>>Fortunatly there is a fair amount of wiggle room if you do not run
>>too close (too close is below) to minimums.
>
>I know how the disk was originally formatted to the extent that I know
>the sector size and the number of sectors on the track.
>
>I had assumed that it worked the way you described ... my problem is that
>I cannot make sense of the values in the NEC supplied table.

Effectively there are two sets.  FM and MFM and the chip works differently 
for both.  It's tied to FM allowing for gaps as short as 8bytes and MFM 
16bytes. The length of gaps are related to mode FM having more flux 
transistions than MFM per bit and that most analog PLLs have a minimum
number of transistions (time) they need to aquire.  Obviously the gaps
are made as long as possible allowing for the sectors containing data.
Since sector length is variable gaps will be.  FYI: due to waste longer 
sectors can end up with very long gaps.

>Using the IBM System 3740 (FM) and System 34 (MFM) disk format specifications,
>I tried working the NEC tables backward to get the "number of available bytes
>on a track" which they started with. I worked it through for both 8" and 5.25"
>drives in each format type, and the problem is that the results are not
>consistant. Using a given drive type and encoding method, for each sector size,
>number of sectors/track, and format GPL values in the NEC table, I get a "total
>bytes on track" values which are quite different - within a few 100 bytes, but
>you can make them all come out much closer by adjusting the gap length.
>
>In other words, I want to do a calculation something like:
>
> Total number of bytes assumed to be available on the track
> - track overhead
> - (#sectors * per-sector overhead) [not including gap]
> - (#sectors * data bytes/sector)
> / #sectors
> = actual sector gap length (for format)
>
>However the values from the NEC table do not fit such a calculation, because
>for each sector-size/number-of-sectors in the NEC table, you work out a "total
>number of bytes assumbed to be available on the track" which is only within a
>few 100 of the value worked out for other sector-size/number-of-sectors
>combinations at the same drive type and encoding method.

Yep thats true.

>For example, if you begin with a "total number of bytes assumed to be available
>on the track" which you worked out from 512 byte sectors, and reverse the
>calculation for 1024 byte sectors, the gap length you arrive at is different
>from the one in the NEC table. Another way to look at it is that by tweaking the
>sector GPL, you can always get a "total number of bytes" which is within
>number-of-sectors/track" of the "optimim value" you were aiming for, however the
>values in the NEC table often result in "total number of bytes" values which are
>a couple of 100 away from each other.

Also you need the ECMA/ISO {ECMA-70} spec for formatting. They are somewhat 
different.

The problem is that somewher in the gap there will be a splice point and
there need to be enough gap bytes written after write is enabled to insure
the new sector is roughly in the smae place as the old one.  


>Unfortunately the 765 based FDC in the PC is very limiting, and does not allow me
>to read the raw format information, nor can I determine the GPL that was used on
>the original disk - the only other option is to calculate a suitable GPL based on
>the format information.

The 765 does have a read diagnostic but it's not like the 1771/1791 read track
that tried to read every byte including gaps.

>If no calculation is possible, can anyone point me at a more complete table of
>suggested GPLs?  The NEC table has some large holes, for example 9x512 and 10x512
>are missing.

They are missing because the table was written before the advent of 5.25 1.2 mb
and 3.5" floppies and the 765A really doesn't do the 10x512 (it will read but 
format is not possible).   The latter if done with 765A ends up truncating 
the gap4 badly if the drive is 2% fast.  The later 7265 chip does it and 
you need the spc for that.

The PC varient of the FDC is a cell based on the 765/7265 so unless there's 
a raw 765 on the board you can see you need to read between the line of the 
spec for THAT chip. There are subtle variations in the 765 look alikes and
Tim and I encounted some of them while doing Fcopy.  The test for 765/7265
is can it recalibrate more than 77 tracks.  The 765 will only recalibate a 
maximum of 77 tracks, the 7265 can do up to 255.  The other differnce is 
the 7265 does not write gap 4a/4b at all. Gap 4a coincides with index and gap
4b is the gap written after all sectors are formatted to the end of the track
(index). 



Allison