HP 35s Checksum explained

[Tugdual]

(02-10-2015 12:16 AM)MarkHaysHarris777 Wrote:  Except for one small problem... I deleted *all* of my test equations and *none* of my programs with literals changed... nor did their checksums.

I then added a random EQN as you did
EQN 123456789

... and none of my programs with literals changed, nor did their checksums. In fact, since I have been on this journey I have been adding equations and programs and *none* of the checksums have changed (I have not tried any of this on the emulator).

Marcus try this: call Mem and check the amount
Create one more short EQN and check again Mem
You should see that 35 bytes were consumed.

This is exactly what I observe in memory. Any EQN or literal is using a block of 35 bytes. Now if you enter a very long EQN or literal, multiple blocks will be consumed and the memory management looks like a chained list of blocks (with offset of previous, next items but this is a bit unclear to me).

Once a block is allocated, it has no reason to move... so even if you clear EQN all the blocks allocated for your code literals will remain at the same place. This is why it is important to start from a known state (MEMORY CLEAR) and execute a script to predict what happens in the memory organization.

Now I have seen some blocks moving in some occasions but I cannot explain when and why. May be a CLEAR is sometime calling for some basic internal reorganization to avoid too much memory fragmentation. I'm not sure about that.

Also I have not been able to figure out how exactly the checksum of EQN and literals is calculated. I'm not far but there is always a random difference of 2 or 3 that I cannot explain. I also couldn't figure out all the details of blocks management though I have a rough idea.

Anyway for now, my conclusion is that I'm certain about checksum issue and so far I could:
- reproduce the error starting from a known state
- get a basic understanding of why we have the error (totally design flaw, shame on Hp)

Having more understanding would be worthless since there is no way to actually fix it and also my point was to verify that this was not related to hardware issues or code bug. In a sense you can think positive: the issue is not at all random or buggy, it is totally deterministic and totally a design flaw.