English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 02 May 2016, 22:46   #1
Blueberry
Registered User
 
Join Date: Dec 2007
Location: Aarhus / Denmark
Posts: 33
Minimum sector gap

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?

Last edited by Blueberry; 03 May 2016 at 00:48.
Blueberry is offline  
Old 02 May 2016, 22:55   #2
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 818
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..

Last edited by hooverphonique; 02 May 2016 at 23:13.
hooverphonique is offline  
Old 02 May 2016, 23:26   #3
Blueberry
Registered User
 
Join Date: Dec 2007
Location: Aarhus / Denmark
Posts: 33
Yes, it needs to be in standard format. Much easier to distribute that way, not to mention creating it in the first place.
Blueberry is offline  
Old 02 May 2016, 23:38   #4
DanScott
Lemon. / Core Design

DanScott's Avatar
 
Join Date: Mar 2016
Location: Belgrade, Serbia
Posts: 319
Quote:
Originally Posted by Blueberry View Post
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?
DanScott is offline  
Old 02 May 2016, 23:40   #5
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 818
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 ;-)
hooverphonique is offline  
Old 03 May 2016, 00:04   #6
Blueberry
Registered User
 
Join Date: Dec 2007
Location: Aarhus / Denmark
Posts: 33
Quote:
Originally Posted by DanScott View Post
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.

Last edited by Blueberry; 03 May 2016 at 00:39.
Blueberry is offline  
Old 03 May 2016, 00:15   #7
Blueberry
Registered User
 
Join Date: Dec 2007
Location: Aarhus / Denmark
Posts: 33
Quote:
Originally Posted by hooverphonique View Post
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.
Blueberry is offline  
Old 03 May 2016, 00:36   #8
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 818
Quote:
Originally Posted by Blueberry View Post
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 ;-)
hooverphonique is offline  
Old 03 May 2016, 02:21   #9
nocash
Registered User
 
Join Date: Feb 2016
Location: Town/Country
Posts: 32
Quote:
Originally Posted by Blueberry View Post
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.
nocash is offline  
Old 03 May 2016, 11:16   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,109
Just count length of one track/motor speed and use it calculate approximate safe gap skip value
Toni Wilen is offline  
Old 03 May 2016, 12:07   #11
Blueberry
Registered User
 
Join Date: Dec 2007
Location: Aarhus / Denmark
Posts: 33
Quote:
Originally Posted by nocash View Post
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 is offline  
Old 03 May 2016, 12:23   #12
Blueberry
Registered User
 
Join Date: Dec 2007
Location: Aarhus / Denmark
Posts: 33
Quote:
Originally Posted by nocash View Post
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.
Quote:
Originally Posted by Toni Wilen View Post
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.
Blueberry is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Minimum Utilities to get up and running allanmb Amiga scene 3 30 September 2015 17:08
minimum requirents for whdload... gntavelis support.Hardware 13 10 March 2014 16:10
Minimum Bootable Workbench Disk atrionfo New to Emulation or Amiga scene 10 07 January 2007 22:04
Minimum requirements for MFMWarp? andreas project.WHDLoad 4 29 October 2005 00:18
WinUAE Minimum System Req's? Unregistered New to Emulation or Amiga scene 10 15 December 2004 18:15

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.12788 seconds with 13 queries