More about Checksum



I entered the insertion sorting routine as written by Gene Wright in Datafile V26 N4, in both HP 35s (CNA 72102361 and 72102362) to verify if I got the same checksums. They were different compared between them and compared to Gene's. I deleted one instruction at a time backwards until line I015: there, the checksums were exactly the same! The culprit in this case: line I016, putting ‘1’ in the stack. Beginning with this instruction the checksums of both calculators disagreed. You could try and see if you obtain the same behavior:

I001 LBL I    ---> CK = 4254
I002 STO K
I003 IP
I004 STO B
I005 ISG K
I006 RCL K
I007 STO I
I008 RCL (I) ---> CK = D522
I009 RCL I
I010 IP
I011 STO J
I012 RCL B
I013 x=y?
I014 GTO I026
I015 RDN ---> CK = 5E0A
I016 1 ---> CK = 0B9E ('61) CK = 8136 ('62)
I017 -
I018 STO I
I019 x<>y
I020 RCL (I)
I021 x<=y?
I022 GTO I027
I023 STO (J)
I024 x<>I
I025 GTO I011
I026 RDN
I027 x<>y
I028 STO (J)
I029 ISG K
I030 GTO I006
I031 RTN

1.- The calculators have different content
2.- I made GTO .. in both before entering the program.




Does a replacement of steps 15 and 16:

I015 RDN      ---> CK = 5E0A
I016 1 ---> CK = 0B9E ('61) CK = 8136 ('62)


I015 CLx
I016 e^x

cause the checksums to match again?

I'm pretty confident that it is numbers that are causing the problems with the checksums and size calculations. This alternative code avoids the number. It should also be smaller and slower.

- Pauli


One (1) is a rather mathematically "boring" number. I wonder if you substituted, say, nine (9) or 67 for that one line, would the checksums still diverge?

I'd try this myself, but I carelessly left my 35s at work... ;-o



1 isn't SO boring!

It has four roots, for well, 1, thing... ;)

Hmmmmm... how would I do that on a 35s?!


1 isn't SO boring!
It has four roots

I don't understand your point. If memory serves, every positive real number has two real roots of any even positive integer order, and n complex roots of any integer order n.


Maybe if someone knows something about 35s internals, (s)he could offer a more informed opinion. In my ignorance, I can only speculate whether the 35s' new capacity for vectors and complex numbers might be related. If uninitialized (and unused) vector storage is incorporated in the checksum calculation for programs when simple numbers are being entered, that might explain how differing checksums result.

-- <appended> --------------------------------

FWIW (and in case it hasn't been made clear yet), the User Manual's example programs are not immune. The first three suspect programs from the manual that I entered (chosen because each includes at least one number entered on the stack) all came up with checksums that differ from those listed in the manual:

LBL S -- page 16-13 -- CK=DDC4
LBL F -- page 16-14 -- CK=8C04
LBL I -- page 16-19 -- CK=2159

Edited: 18 Aug 2007, 11:05 a.m.


Hi Bruce,

One (1) is a rather mathematically "boring" number

Sound like you have listened to the BBC series on numbers.


If you haven't heard the series, then I highly recommend it. There are three series on numbers:

Five Numbers, Another Five Numbers and A Further Five numbers.

While you are there, also check out the series on Electronic Brains.

Electronic Brains



1 isn't boring!

- Pauli


1 is not boring, but it is the loneliest number. ;)

Why would number throw checksum off though? That I not understand. Every didgit and keystroke I would assume have an ascii code in the system, or something similar that it would be assigned. Why would a number on one person machine be different than another persons? I wonder though, if program typed in on one mode, and then typed in on different mode yield different checksum? Meaning, if you type in on one calculator in degree mode, and on different calculator in radian mode, I wonder if that be different. Or maybe with different base, although I not sure it would let you do the later. Hmm, maybe on some calculator, 1 is larger than on others. You know, 1 + 1 = 3 for very large value of 1.

Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-28C ROM checksum addresses? Christoph Giesselink 0 473 07-25-2010, 08:25 PM
Last Post: Christoph Giesselink
  HP 35s checksum repeatability observed JJB299 0 448 06-15-2009, 10:06 AM
Last Post: JJB299
  35s checksum problem Lyuka 42 5,649 08-14-2007, 07:54 AM
Last Post: Jeff O.
  HP-41 program checksum Jean-Marc 2 642 04-21-2006, 04:44 PM
Last Post: JeanMarc
  33s CHECKSUM issue: old/new ECL 11 1,847 10-30-2005, 10:43 PM
Last Post: James M. Prange (Michigan)
  HP41 ROM Checksum Meindert Kuipers 4 856 10-25-2004, 02:30 PM
Last Post: Meindert Kuipers
  HP-41 Bar-Code checksum algorithm. Diego Diaz 3 758 11-29-2002, 05:19 AM
Last Post: Diego Diaz
  HP18C & HP28C ROM checksum? Christoph Giesselink 0 450 11-03-2002, 06:11 PM
Last Post: Christoph Giesselink

Forum Jump: