first two bytes of checksum bad

Despite the data being received 100% correct, the data checksum fails in certain cases.

It’s always the first two bytes of the 4-byte, 32-bit checksum that are wrong.  The last two are always right.  What does this mean!?

In my test track, track 0 of my 0x00-0xff floppy, here are the results:

sector no. 0-5, and 8: all computed checksums match stored checksums

sector nos. 6,7,9,10: last two bytes of computed checksum match, first two are wrong.

The checksum routine is pretty simple and based on exclusive-or:

unsigned long CalcSectorDataCHK(void){

int i;unsigned long odd, even;unsigned long chk = 0L;

for(i=0; i<128; i++){

odd = GetMFMLong(64 + (i< <2)); even = GetMFMLong(576 + (i<<2)); chk ^= odd ^ even;

}

return(chk);

}

}Note GetMFMLong returns a 32-bit long, so we are processing 128*4 bytes = 512 real bytes.

I guess really the question of the week is if I can get away with ignoring the first two bytes of the checksum.  I’m still working on the fix.  I really think this has to do with difference in the size of types of variables between old C and .net compilers, but I can’t nail the problem down.

 

About the author

keith

Amateur Electronics Design Engineer and Hacker

2 Comments

  • Strange enough I’m on to something.

    Now on to a different sector. guess what, my header checksums are now bad.

    I take a look at headers, guess what? Those are in good shape too.

    Once again, data good, but the calculated checksums are failing. And once again, last two bytes are good, first two are bad.

    Guess what function both of those have in common? GetMFMLong(). I had a SERIOUS problem with GetMFMData() that I had to fix related to improper variable sizes…..And guess what? ONLY those two routines actually use GetMFMLong() which is hosed.  This explains why everything else works and checksums fail occasionally.

    GetMFMLong has to be screwed up.

    For the conversation regarding GetMFMData() problem, see this comment here

    http://www.techtravels.org/?p=48#comment-69

    Stay tuned.  Fixing this routine should bring both header checksum problem and data checksum problem to a head.

     

  • OK so this is screwed up.

    1. GetMFMData() was not working right, so I modified it, and produced a version that worked.

    2. GetMFMLong() depends on GetMFMData(), so when I modified GetMFMData(), GetMFMLong() broke. I just figured this out now.

    3. The new(ie 6 months ago) version of GetMFMData() works in all functions that use it 100% EXCEPT GetMFMLong.

    4. GetMFMLong() breaks, so I add the original version of GetMFMData() with a modified name just for GetMFMLong(), and now GetMFMLong() works.

    Everything works. I’m literally in state of shock.