Minimum sector gap

[Blueberry]

Hi!

I am looking into writing a floppy track loader with minimum CPU usage (for loading in the background of a demo). I have read this interesting track loader thread, which is focused on code size: http://eab.abime.net/showthread.php?t=45654

I also found this reference very useful: http://amigadev.elowar.com/read/ADCD.../node015B.html

The MFM decoding itself can be done very efficiently using the blitter. So the bottleneck then becomes traversing the sector gap to look for the first sector after the gap.

It occurred to me that maybe there is a minimum gap size that can always be skipped, so I can save some time by not traversing the whole gap.

The AHRM specifies 2 microseconds per MFM bit and a rotation speed of 300 RPM, corresponding to 6250 MFM words per revolution, i.e. a gap of 6250-(32+512)*11 = 266 words. Of course this can vary depending on the precise bit rate and motor speed of the disk drive that wrote the disk.

I performed some tests.

On my A600 disk drive, the gap was between 340 and 350 words for all the disks I tried.
Similar numbers were seen in WinUAE from an ADF floppy image.
The HxC on my A1200 showed a gap of 416 words. But I guess this depends on how the HFE file is formatted (the files I tried were created using the standard HFE utilities).

Based on the tests, it should be safe to skip the first 300 or so words. But is this too optimistic? Which gap sizes can occur in practice?

[hooverphonique]

what about writing the disk as whole tracks and use the hw sync detection when you read it.. wouldn't that give you all 11 sectors back to back? (provided you have only one sync word per track, of course)

edit: also provided that you don't need the format to be compatible to trackdisk.device..

[Blueberry]

Yes, it needs to be in standard format. Much easier to distribute that way, not to mention creating it in the first place.

[DanScott]

Originally Posted by Blueberry

Hi!
The MFM decoding itself can be done very efficiently using the blitter.

A little off topic, but how would you synchronize the blitter MFM decoding in the background, if the demo "effect" that is showing, is already thrashing the pants off the blitter?

[hooverphonique]

ok.. well, according to this info about the amiga bit length
PAL 506699.285714286Hz 1973.5571535103ns
NTSC 511363.636363636Hz 1955.5555555556ns
you would get a gap of around 348 words for a PAL amiga, which is closer to your empirical numbers. The gap gets even bigger for NTSC.

I guess this also relates to how many words to read to be sure to get the whole track, which was different for each trackloader I ever saw, back in the day ;-)

[Blueberry]

Originally Posted by DanScott

A little off topic, but how would you synchronize the blitter MFM decoding in the background, if the demo "effect" that is showing, is already thrashing the pants off the blitter?

My thought was that the blitter rarely needs to run across the start of the vblank, so I would decode one sector in each vblank interrupt (when data is available). It could fall back to CPU decoding if the blitter is active.

I think this would work well for most effects, but there will be exceptions of course.

[Blueberry]

Originally Posted by hooverphonique

ok.. well, according to this info about the amiga bit length
PAL 506699.285714286Hz 1973.5571535103ns
NTSC 511363.636363636Hz 1955.5555555556ns

Ah, interesting. I did think briefly that the actual 2us clock was probably some whole multiple of the base clock, but I never got around to doing the math.

The other question is then how precise the motor speed is. Even a 5% speed increase would stay within the gap, so one could imagine that some drives are pretty far off without anyone noticing.

[hooverphonique]

Originally Posted by Blueberry

The other question is then how precise the motor speed is. Even a 5% speed increase would stay within the gap, so one could imagine that some drives are pretty far off without anyone noticing.

The average speed will be close to spot on, but over a revolution, there will be speed variations in most cases..

If my amiga wasn't in bits atm, I would take a look at my different mfm decoders to see, what minimal gap I anticipated back in the early 90's - I probably just brute forced it, though ;-)

[nocash]

Originally Posted by Blueberry

On my A600 disk drive, the gap was between 340 and 350 words for all the disks I tried.
Similar numbers were seen in WinUAE from an ADF floppy image.
The HxC on my A1200 showed a gap of 416 words. But I guess this depends on how the HFE file is formatted (the files I tried were created using the standard HFE utilities).
Based on the tests, it should be safe to skip the first 300 or so words. But is this too optimistic? Which gap sizes can occur in practice?

Worst case timings would be probably found on discs written via parallel port: http://eab.abime.net/showthread.php?t=82282 My current utility is focusing on 2us timings (which means shorter gap as with 1.97us/1.95us timings; though I could fix that issue), and the PC hardware is producing some weird extra delays once and then, for example, causing 4us pulses to become around 4.5us long (works more or less stable, but makes the gap even shorter). I don't know if the ADTWin utility is more stable, but it might have to deal with similar issues. On the other hand, there's probably almost nobody using such parallel port tools.

In all other cases, the gap size should be more or less constant per disc, so you could probably detect if it's a disc with 416 word or 340 word gaps (or other size), and then subtract something like 30 from that value - and hope that it's working. There may be some fluctuation because floppy drives are probably permanently adjusting the rotation speed whenever they notice the motor being too fast/slow, the worst case would be if the disc was spinning too fast at time when writing a track, and spinning too slow at time when reading the same track (or vice-versa).

If you know that all sectors (or sector headers) contain continous non-zero bytes then you could also speedup searching by skipping each some bytes. I don't know if sync values are written to memory? If they are, then each sector would start with two sync words, plus one word containing odd bits of the format/track value, which should be all non-zero (aka non-AAAAh in MFM notation). The fourth word should contain odd bits of sector/remain values, usually either sector or remain should be odd, but I think that isn't 100% guaranteed, so better don't trust on that.

[Toni Wilen]

Just count length of one track/motor speed and use it calculate approximate safe gap skip value

[Blueberry]

Originally Posted by nocash

If you know that all sectors (or sector headers) contain continous non-zero bytes then you could also speedup searching by skipping each some bytes.

Yes, that was the plan. The sector header contains the sync words followed by four non-"zero" words. The first sync word will usually only be written partially, since the sector after the gap is most likely out of sync with the previous revolution. But the second sync word will be intact.

So the gap scanning can skip ahead at least 10 bytes at a time and test a word.

One caveat: the "zero" words in the gap might end up being read as either $AAAA or $5555, so it will need to sample one word from the gap and compare against that.

[Blueberry]

Originally Posted by nocash

In all other cases, the gap size should be more or less constant per disc, so you could probably detect if it's a disc with 416 word or 340 word gaps (or other size), and then subtract something like 30 from that value - and hope that it's working.

Originally Posted by Toni Wilen

Just count length of one track/motor speed and use it calculate approximate safe gap skip value

That's a really good idea. The first track is typically not performance critical, so it could just scan the entire gap. Each subsequent track could just skip ahead using the previous gap size minus some safety value.