Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amiga ADF "Ziriax 100%" fails to load #58

Closed
keirf opened this issue Feb 23, 2018 · 4 comments
Closed

Amiga ADF "Ziriax 100%" fails to load #58

keirf opened this issue Feb 23, 2018 · 4 comments
Labels

Comments

@keirf
Copy link
Owner

keirf commented Feb 23, 2018

See EAB forum thread for details:
http://eab.abime.net/showthread.php?p=1221573

The ADF itself:
Ziriax (1990)(The Whiz Kidz)[cr ross][t +6 ross].zip

@keirf keirf added the bug label Feb 23, 2018
@keirf
Copy link
Owner Author

keirf commented Feb 23, 2018

Quick read of the trackloader indicates a 33ms max latency from read-start to sync-found. This is in addition to a 15ms settle delay if any head-step occurred.

Worst-case to find a sync should be sector-latency + track-gap = (544*16 + 4256) * 2us ~= 26ms.

So there should be plenty to play with here. I will debug on real hardware next week.

@keirf
Copy link
Owner Author

keirf commented Feb 27, 2018

LA trace shows 200ms+ between retries (seek to track 0 and back) so this is not the 33ms disk-sync timeout. Consistent number of steps to and from track 0 so not missing step pulses.

@keirf
Copy link
Owner Author

keirf commented Feb 27, 2018

Bug in Ziriax track loader: skips 300*2 bytes of MFM at the track gap.
This assumes track is at least (544*11 + 300)*2*8 = 100544 bitcells long.
However a DD track is 100000 bitcells +/- perhaps 2%. Usually drives run a bit slow and you end up with a long enough track, but this is certainly not guaranteed.

@keirf keirf closed this as completed Feb 27, 2018
@keirf
Copy link
Owner Author

keirf commented Feb 27, 2018

It has been pointed out that an Amiga generates long tracks because bitcell timing is derived from CCK and thus is a little faster than 2us (precisely 14/7093790 us on PAL Amiga). And some loaders depend on this (Ziriax is an existence proof). Hence it makes sense to make FlashFloppy generate longer ADF tracks.

keirf added a commit that referenced this issue Feb 27, 2018
track length generated by the Amiga itself with its shorter bitcell
timing derived from CCK.
Fixes #58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant