HP 35s Checksum explained

[Tugdual]

Topic on litterals
As I mentioned before, when entering a EQN, a string (in ASCII) is stored in a different location.
The OP CODE remains 3 bytes long but the count of # of characters is added to the total.

Few remarkable aspects
- values entered in the code are stored the same way as EQN though they don't have the same OP CODE. Therefore they share the same memory area.
- each string is stored in a 35 bytes block. The 2 first bytes indicate the length. It seems to be possible top have larger strings and in that case the 35s stores them in multiple blocks, not sure how.

Entering

Code:

A001 LBL A
A002 1

and

Code:

A001 LBL A
A001 2
A001 1

Then removed line A001 produce the same code but the string are arranged differently and the pointer in the second case is 35 bytes farther than in the first case. Still the CRC is the same indicating that the pointer valued is not used to calculate the CRC.

Conclusion
Litterals (strings entered with EQN or constant values) seem to be handled properly in the CRC calculation. At the moment I still don't know why some calculators should return different values. I also cannot reproduce the problem and my hardware and simulator are always returning identical values.
I would be curious to see if some people get different values on their simulator. We're not sure that all calculators are strictly identical (same ROM? Some are may be also defective) but if the simulator returns different values in some occasions this would definitely indicate that we have a memory context that impacts the calculation.