On May 30, 2013, at 1:11 PM, silverdr@wfmh.org.pl wrote: > > On 2013-05-30, at 20:17, Nate Lawson wrote: > >> This happens when the track gap is at the end of the G64 track. You get 0x55 for the trailing region but sometimes 0xaa for the starting region until the first sync brings things back into alignment. > > Got it.. so if the "slicing" happens after "1" bit of the gap, then starting region continues with $55s but when the "slicing" happens right ofter "0" bit, then the starting region will continue with next "1" bit and that makes its bytes $aa worth. OK - so there is no data loss, just random possibility. Correct. It all depends on how the G64 was created. If the writer tried to align things on syncs and properly detected the track splice, then you'll always see 0x55 bytes in both head and tail. Because the G64 format counts byte lengths of GCR, there are between 0 and 7 extra bits present in a track that weren't there to begin with. However, I think both nibread and Kryoflux read more than a single track cycle so this doesn't matter in practice since the trailing part overlaps the head. On a related note, nibedit properly handles any number of bits between syncs, such as vmax which ends on a 4-bit boundary. Here is a dump of a sector header like this, ending in the bit pattern 1010b. SYNC:40 52 54 b5 29 4b 9a a6 a5 29 4a # 08 01 00 01 30 30 00 00 52 94 a5 29 4a 52 94 1010. # 00 00 00 00 00 SYNC:40 … sector body ... Since GCR is 5:4 encoding, the above is perfectly valid. I think my GCR decoding on the right is off by one byte though. There should be another 00 at the end. -Nate Message was sent through the cbm-hackers mailing listReceived on 2013-05-30 21:01:57
Archive generated by hypermail 2.2.0.