| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Fri, Apr 15th, 2011 @ 17:05 ( . ) |
From rotation.c: /* GCR=0 support. * * In the absence of 1-bits (magnetic flux changes), the drive * will use a timer counter to count how many 0s it has read. Every * 4 read bits, it will detect a 1-bit, because it doesn't * distinguish between reset occuring from magnetic flux or regular * wraparound. * * Random magnetic flux events can also occur after GCR data has been * quiet for a long time, for at least 4 bits. So the first value * read will always be 1. Afterwards, the 0-bit sequence lengths * vary randomly, but can never exceed 3. * * Each time a random event happens, it tends to advance the bit counter * by half a clock, because the random event can occur at any time * and thus the expectation value is that it occurs at 50 % point * within the bitcells. * * Additionally, the underlying disk rotation has no way to keep in sync * with the electronics, so the bitstream after a GCR=0 may or may not * be shifted with respect to the bit counter by the time drive * encounters it. This situation will persist until the next sync * sequence. There is no specific emulation for variable disk rotation, * this case is thought to be covered by the random event handling. * * Here's some genuine 1541 patterns for reference: * * 53 12 46 22 24 AA AA AA AA AA AA AA A8 AA AA AA * 53 11 11 11 14 AA AA AA AA AA AA AA A8 AA AA AA * 53 12 46 22 24 AA AA AA AA AA AA AA A8 AA AA AA * 53 12 22 24 45 2A AA AA AA AA AA AA AA 2A AA AA * 53 11 52 22 24 AA AA AA AA AA AA AA A8 AA AA AA */ And: /* * Simulate loss of sync against the underlying platter. * Whenever 1-bits occur, there's a chance that they occured * due to a random magnetic flux event, and can thus occur * at any phase of the bit-cell clock. * * It follows, therefore, that such events have a chance to * advance the bit_counter by about 0,5 clocks each time they * occur. Hence > 0 here, which filters out 50 % of events. */ Hm, in the images I converted from .nib to .g64, I used the -f option to not force the $00 bytes for invalid GCR. This may have been a mistake. I'll try it again later without that option and see if the framing eventually falls in line after a few rotations of the disk and allows the loader to continue. Also nice to see in the TODO list of drive.c: /* TODO: - more accurate emulation of disk rotation. - different speeds within one track. Would also be nice to see removal of hardcoded track sizes in G64. Should also be pretty straightforward to alter the bps speed of the track from the current hardcoded table, to a generated value based on how many bytes are on the track (bytes-in-track*8*RPM/60 would be close enough for a track that doesn't include speed zones). This would fix the V-Max density protection check. |
--- 0 Users Online --- 0 Recent Unique Posters |