On Thu, May 30, 2013 1:02 pm, email@example.com wrote: > > On 2013-05-30, at 18:48, Pete Rittwage wrote: > >>> "The most reliable way to read G64 track data is to read it as bits, >>> not >>> bytes as there is no way to be sure that all the data is byte-aligned." >>> >>> yet the above code seems to look always for the first 8bits being >>> byte-aligned. Why so? Or is is just completely unrelated to G64 and >>> works >>> with NIB files well? >> >> Yes, the 9-bit version was the best balance. Never any false-hits, and >> it >> still catches when we miss a bit now and then (V-MAX, for one) as sync >> is >> only measured by cycle-counting and and BIT/BVC is not perfect here. :) > > I see.. :-) > >> The 15x1 returns GCR data ALWAYS sync aligned, as long as a sync exists, >> so it never occurs that it's not aligned that way. > > Maybe we think of different things / use cases. I mean I am still > /looking/ for the SYNC mark here. Actually in a G64 file. And being > compliant with the said documentation caused me to write eight "else if" > blocks (which I am afraid may never be needed) rather than one or two > lines. > > P. S. Thanks for the latest update to nibtools. The G64 specification doesn't require it to be sync-aligned, but the 15x1 always returns data in this way at $1C01, so it has never been a concern unless there is no sync on the track. In this case, if you just "drop the needle down on the record" you will get what you get. It will be "right" 1/8 of the time. :) The KF software does not make byte-aligned G64's, so in that case every track or sector could be bitshifted, which is what the -$ routing tries to fix. -Pete Message was sent through the cbm-hackers mailing listReceived on 2013-05-30 18:02:12
Archive generated by hypermail 2.2.0.