HP 35s Checksum explained

[MarkHaysHarris777]

(02-09-2015 10:36 PM)Tugdual Wrote:  Case 1

Code:

[MEMORY CLEAR]
LBL A
1
->7991

Confirmed

Quote: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

Confirmed


Thank you, this is the first time I'm getting closer on this. Now I have a catch for you to try. I have also determined that the checksum for (programs, not equations) is based on whether there are equations in memory *first* or not. If equations exist in memory *first* then the A program gets checksum 7A1D (You'll notice our two machines are consistent) but if equations are placed in 2nd (programs are first) then the A program gets checksum 7991 (also consistent with your machine.

BUT... once that *firstness* is established adding programs and equations to memory does NOT change any of the checksums. In other words, once the literal program A is in memory I can add equations with literals all day long without changing A's checksum. Also, on the other hand, if the equation (123456789) is in memory *first* and program A gets checksum 7A1D I can add additional programs or equations into memory without changing any of the checksums.

Of course, I must agree, there is a dumb design issue here because the checksum for the programs (nor equations) should be based on position in memory! CONCLUSION: yes, the checksums are only useful "for context" (between machines) IFF we know how the primary context was established (at any rate this explains why checksums are very consistent "within" context because once the order of memory usage has been established the checksums are not going to change---the reason why I have not been able to reproduce this up until now... so again, thank you!

I must add, for me personally, on the HP35s the most important use of checksums is for confidence 'myself' (to know whether my own context has *changed*). If I modify a program by altering a GTO or XEQ target (say against my own utility library) I want to be alerted to the fact that 'renumbering' may have occurred. I may use the checksums to get that confidence. On the other hand, cross checking between machines (I have two of them) is only going to be relevant (to me, on my units) if I setup the machines the same way (programs first, equations second). Unfortunately, based on this new information, I am not able to have that same confidence between my unit and someone else's (yours perhaps) since I have no idea whether you had equations in memory before you entered any programs!

Again, I plan to run the wheels off this thing. I think its worth having (obviously, I own two of them) and I think its worth using professionally. But we do need to keep the caveats in mind, and we do need to understand the limits of operation.

PS I pulled out my TI30 yesterday (original) and put it into a tight loop just for fun... if you entered this on the 1976 TI30 0 INV TAN that silly thing would go into a tight loop and not come out until you powered off, and sometimes not till you removed the 9v battery! TI fixed that in the later models (my July 1977 model, for instance, does not have the quirk). My point for bringing it up is that when we know what the 'quirk' is, and how to avoid it, then we really don't have any problem.

PSS Nice to meet you, and thanks for working with me on this... it has been most helpful!

Cheers,
marcus