Date : Wed, 25 Oct 2006 13:38:23
From : John Kortink <kortink@...>
Subject: Re: ADFS sector checksums
On Wed, 25 Oct 2006 11:56:02 +0100, "Steve O'Leary" wrote:
>> On 25 Oct 2006 11:58:54 +0200, John Kortink wrote:> > On 25 Oct 2006
01:28:49 +0100, Jonathan Graham Harston wrote:> > >[...]> >> >For instance:>
>Sector 0: 07 00 00 00 00 .... 00 00 00 00 20 xx> >FNsum returns &27, actual
checksum is &27> > Yes.> > >Sector 1: F9 FF 1F 00 00 .... 00 27 E6 00 03 xx>
>FNsum returns &2A, but actual checksum is &2B.> > No, the actual checksum is
&29.> > The proof of the pudding : putting the relevant harddisc> images on
GoMMC : &2B for sector 1, as expected, gives a> 'Bad FS map' error. &29, as
expected, doesn't.
>Mmmm... Ignoring the code snippets, doing this on paper gives me 2A if I add
with Carry and 27 if I don't, unless I've added up wrong; Here's my working,
converting the values to decimal;
>
>sum = $FF (255), carry is zero
>
>add in $F9 (249) = 504 (carry set)
No, you start at index 254, not index 0.
Adding the F9 generates a carry in both cases, which you
add into your sum if you do it from 0 to 254, but not if
you do it from 254 to 0 (it is discarded). Hence &29 not
&2A.
>[...]
>
>Now I know I'm miss-interpreting somewhere but can you point
>out where.
See above.
>Also in my code I was clearing sum to 0 before starting the
>loop but you set it to 255, even adding that part into the
>"add all bytes with carry" routine (which I've done above)
>I cannot match your result, which as you've proven appears
>correct.
Either you start 0 or start 255. There's no difference
in the result unless you never consume a generated carry
in the second case, i.e. if all your bytes except the very
last one are zero (if the last one is not, it will generate
a carry, but this is never consumed).
I.e.
FF C=0 .. <+ 00> .. <+ 01> = 00 C=1 <+ 00> = 01 C=0
00 C=0 .. <+ 00> .. <+ 01> = 01 C=0 <+ 00> = 01 C=0
i.e. same result, while in the pathetic case :
FF C=0 .. <+ 00> .. <+ 00> = FF C=0 <+ 01> = 00 C=1
00 C=0 .. <+ 00> .. <+ 00> = 00 C=0 <+ 01> = 01 C=0
i.e. different result.
Acorn probably intended to start 0, but some fan of
obscure programming realised that it's the same as
starting 255 since there's always a non-zero byte
before the last one is added in (and since Y already
starts 255 and loops 'NE', TYA then saves one byte,
compared to LDA#0). Whoopee.
There's one case where this fails, and that's where
there's no free space left on the drive, so it's
/possible/ for all but the last byte (at index 0) to
be zero in sector 1 (while there's always a non-zero
disc size in sector 0).
John Kortink
--
Email : kortink@...
Homepage : http://www.inter.nl.net/users/J.Kortink
GoMMC, the ultimate BBC B/B+/Master storage system :
http://web.inter.nl.net/users/J.Kortink/home/hardware/gommc
_______________________________________________
bbc-micro mailing list
bbc-micro@...
http://lists.cloud9.co.uk/mailman/listinfo/bbc-micro