Computation of #ID checksum

[RF_Developer]

This is for those, like myself, who are using #ID checksum to a validate code at runtime.

I know a lot has been written about the rather confused and often mysterious world of including checksums and CRCs in code. This is about a specific instance only: #ID checksum

I have spent much of today debugging code that ran perfectly when compiled with PCHW 4.107 but which stopped working when I upgraded to 4.124. I have already sorted out one issue relating to indexing of strings, which mucked up timecoding my code. I put it to one side and stuck with 4.107 for existing code, using 4.12x for new code.

I've just updated to 4.127 and decided to get to the bottom of the second problem.

At some point between 4.107 and 4.124 (the file dates suggest 16 Oct 2010) the algorithm for computing the checksum by #ID checksum changed. ex_checksum.c appears to have changed to reflect the change, so use ex_checksum.c as a guide to generating new code.

The change itself is that previously the 16 bit checksum on PCH was calculated as the sum of 16 bit program words mod 2^16. In other words the checksum is an unsigned int16 into which the words are simply added ignoring any overflows.

After the change the 16 bit checksum on PCH is calculated as the sum of 8 bit program bytes mod 2^16. In other words the checksum is an unsigned int16 into which each byte, low byte first (though ordering is not important) of the code words are simply added ignoring any overflows.

A worked example: 0xFFFF 0xFFFF 0xFFFF 0xFFFF used to sum to 0xFFFC. Now it sums to 0x07F8.

The effect is that my code checksum stuff broke :-(

I can't comment on other methods of checksum/CRC labelling, such as #rom checksum, which uses a DIFFERENT algorithm to #ID checksum as well as placing the result in a different place in memory. And no, as far as I know, no one has ever got any of the CRCs to work.

RF Developer

[asmboy]

THANK YOU for sharing that !!!!!

OUCH indeed.