FDC Gap Length?

[Allison]

>
>Subject: Re: FDC Gap Length?
>   From: Dave Dunfield <dave04a at dunfield.com>
>   Date: Sun, 17 Jul 2005 11:10:39 -0400
>     To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Hi Jules,
>
>>On Sun, 2005-07-17 at 07:28 -0400, Dave Dunfield wrote:
>>> 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.
>>
>>In case it's useful, I've got the following in the Torch Manta SCSI-
>>floppy controller documentation (amongst others):
>>
>>512 byte sectors (5.25" or 3.5" media):
>>
>>  FM recording, 4 sectors/track, gap3 size is 175 bytes of FFh.
>>  FM recording, 5 sectors/track, gap3 size is 31 bytes of FFh.
>>  MFM recording, 9 sectors/track, gap3 size is 66 bytes of 4Eh.
>>
>>1024 byte sectors (5.25" or 3.5" media):
>>
>>  FM recording, 2 sectors/track, gap3 size is 255 bytes of FFh.
>>  MFM recording, 4 sectors/track, gap3 size is 255 bytes of 4Eh.
>>  MFM recording, 5 sectors/track, gap3 size is 66 bytes of 4Eh.
>>
>>512 byte sectors (8" media):
>>
>>  FM recording, 7 sectors/track, gap3 size is 149 bytes of FFh.
>>  FM recording, 8 sectors/track, gap3 size is 62 bytes of FFh.
>>  MFM recording, 14 sectors/track, gap3 size is 120 bytes of 4Eh.
>>  MFM recording, 15 sectors/track, gap3 size is 73 bytes of 4Eh.
>>  MFM recording, 16 sectors/track, gap3 size is 33 bytes of 4Eh.
>>
>>1024 byte sectors (8" media):
>>
>>  FM recording, 3 sectors/track, gap3 size is 255 bytes of FFh.
>>  FM recording, 4 sectors/track, gap3 size is 157 bytes of FFh.
>>  MFM recording, 7 sectors/track, gap3 size is 255 bytes of 4Eh.
>>  MFM recording, 8 sectors/track, gap3 size is 128 bytes of 4Eh.
>>
>>
>>can't remember what controller IC the board uses now though - I'm
>>reasonably sure it's not a 765. 
>
>Thanks - I'm not sure this helps me, as the numbers given are different
>than the NEC table. Here's what I have:

The numbers you program into the 765 are not in bytes.  Those are counter 
values (usually a up counter) so that putting in 255 means 1, the however
the count values are prescaled such that in some cases putting in 254 does 
not yeild 2 of something but 4 or even 8 [(0-n) * base].  Example are HLT
(head load time) and HUT (head unload time) and even they are affected by
what the 8/4 mhz clock supplied. Byte counts like the gaps are similar.
So a gap length if FBh might really be 4*16 gap bytes. One note: those 
counters have different prescale values for FM then MFM.   Hope this helps
and I'm really testing 25 year old memory from my NEC apps engineeing 
days.


>Clearly the 200/255 are the maximum values. I have tried working the numbers
>without these entries, and still cannot come up with a calculation.
>
>As you can see the gap sizes differ quite a bit from the ones that you have
>documented - with the 765, this is only one of several gaps, and the controller
>does not provide complete access to the raw format like a 179x controller
>would.

No it does not in the fullest sense.  The WD and NEC designs are programtically
as different as night and day. The level of internal automation is higher for
the NEC but doing that takes control from the programmer.  NEC used to have
a part (upD371) that was like the 1771 in that it required a fair amount
of processer attention at the per byte level to affect transfers especially 
formatting.  Where the 765 family all the programmer supplies for formatting
is the initial command and then the sector header info (CHRN) on a per sector
IO. The result is smaller format buffer at the expense of limited format 
options. IE:the general layout of a track is allways the same save for gaps and 
sector lengths.

>I assume the gap sizes need to decrease for formats which have an extra
>sector (or two) over the NEC table, however I do not know by how much ...
>Any additional table entries, or information on how to calculate this would
>be much appreciated.

Correct and the information provided may help in deciding what those counters
corospond to. 


>>The Manta docs only talk about gaps 1-4, however I know some of my Acorn
>>docs reference a gap5 which sits between the gap4 at the end of the last
>>sector on the track and the index marker - I have no idea what that's
>>supposed to do as it's listed as being 0 bytes long in the Acorn
>>examples!
>
>Normally the last gap is filled from the end of the last sector until
>the physical index mark occurs. The 765 appears to do this automatically
>as part of the "Format Track" command. For a controller like the 179x,
>you need to keep providing filler bytes until the physical end of track.

There are two cases of gap 4, gap 4A(index mark) and gap 4B(EOT to index).
I've seen gap 4b refered to as gap 5.  In the nominal IBM gap 4A is index
gap and 4B is the end of track filler gap.

FYI: gap 4 it not optional on 765 and excluded in 7265.  Functionally
its use is been abused and sometimes not included (1771/1791 it's optional).

Yes for the fill to EOT. The INDEX signal is important to the 765 for 
start of track, end of track and read fail.


Allison