|Author:||Lord Crass (guest: search)|
|Date:||Wed, Mar 28th, 2012 @ 21:03 ( . )|
The timing's pretty loose, actually. The loader simply steps the half-track and waits forever for a sync mark followed by a series of 5 repeating GCR bytes ($75 for normal tracks, $77 for half-tracks), reads $280 GCR bytes and sending them to the host. It does this 4 times, re-finding the sector header (which only appears once on the track) and skipping X bytes each time to pick up the next part of the sector, for a total sector size of about $A10 bytes including sync mark and the $75/$77 header. GCR decode is all done on the host.
Tracks in this range (1-17) can hold 7692 bytes under normal circumstances. Writing a 2576 byte sector so that it doesn't overlap the neighbouring tracks shouldn't require any special timing other than stepping the head after the end of the previous track's sector and then writing out the next track's sector. Obviously, this does require 8k RAM or a parallel cable due to the sector length.
Of course, it's still quite a bit of work to program and test a completely custom write routine for a single game. I don't think it'd be worth it.