17 Jul
2005
17 Jul
'05
3:53 p.m.
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,
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.
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. 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