HP 35s Checksum explained

[Tugdual]

Unfortunately I have a bad news... I just found that there is indeed a major flaw with this checksum calculation.
Literals, i.e. any string in your code including EQN as well as constant values are sharing a certain memory area and therefore are allocated by blocks. The 3 bytes OP Code contains an offset to its literal ASCII string which seems to be included in the checsum calculation. And this is really a very stupid design because the checksum will depend on your calculator context.
In particular all EQN are sharing, again the same area as any literal in your code. Therefore it is pretty easy to demonstrate the problem, starting from a MEMORY CLEAR state:
Case 1

Code:

[MEMORY CLEAR]
LBL A
1
->7991

Case 2

Code:

[MEMORY CLEAR]
EQN 123456789 // first create a random EQN before you start editing your code
// Now enter the same code as before
LBL A
1
->7A1D

In the case 2 the literal "1" doesn't have the same address as in case 1 because it is pushed ahead by the previous EQN declaration and this is fooling the CRC calculation.

Conclusion
The idea of implementing a CRC was very good, the way it is done makes me feel extremely sad for myself as a customer and for Hp. How sbdy can spend so much effort designing a CRC procedure and then fail so miserably on such an obvious and basic aspect is above me. I'm afraid this definitely concludes the question of CRC.

This being said, I keep thinking that this calculator is a good one despite its flaws and most of the calculations I did to establish these findings were done using the 35s Hexa capabilities, (except some brute force for which I used the PC... much much faster). Special thanks to Didier who somehow helped me to understand what was going on.