Re: nibtools, GCR, G64

From: Pete Rittwage <peter_at_rittwage.com>
Date: Thu, 30 May 2013 21:16:24 -0400 (EDT)
Message-ID: <4913.75.76.203.106.1369962984.squirrel@rittwage.com>
On Thu, May 30, 2013 7:34 pm, silverdr@wfmh.org.pl wrote:
>
> On 2013-05-30, at 23:54, Peter Rittwage wrote:
>
>> Look closer at the code- those are bit comparisons,  not byte.
>
> I am not sure if I understand what you mean but I understand this code
> like:
>
> if((buffer[i] == 0xff)		// IF current BYTE from the buffer is 0xff
> &&				// AND
> (buffer[i+1] != 0xff)		// the next BYTE one is not (we are getting out of
> SYNC mark)
> &&				// AND
> ((buffer[i+1] & 0x80) == 0x80))	// that same next BYTE has at least MSB
> set
> { i++; 				// THEN "set first BYTE to shift" (and do the shifting)
>
> meaning we do the shifting ONLY if at least one byte in the SYNC mark has
> all bits set, right?
>
> The question is what if we have something like:
>
> buffer[i] = 0x1f;
> buffer[i+1] = 0xf8;
>
> or any of other possible two-byte combinations [*] that still constitute a
> valid SYNC mark (10 consecutive bits set) but the first one is not equal
> to 0xff?
>
> * - 0x7f/0xfe, 0x07/0xfe, ... and so on.

I see what you are asking now, and you are absolutely correct.  There is a
flaw here that I overlooked when I quickly hacked that routine together. 
It can miss up to a perfectly constructed 14 bit sync.  :)

I believe there is a flaw where the bits on the boundaries of the sync
area are corrupted slightly also... not sure.  It only was made to compare
the data in G64's from Kryoflux to NIBs in my database.

Extra credit for whomever on the list can fix it up nicely.  The code is
open source, although only a couple people have ever stepped up with any
help in 10 years.  :<

-Pete Rittwage



       Message was sent through the cbm-hackers mailing list
Received on 2013-05-31 02:00:16

Archive generated by hypermail 2.2.0.