35s program checksums

[r. pienne]

The batteries in my HP 35s died recently, and I had to key in all my programs and equations again. That's no great problem, but I notice that most of the program checksums are different than before, although I'm certain the code in each program (except one) is exactly the same.

I know Pauli's famous HP 35s bug list says "checksums are meaningless", but I'm wondering has anybody here managed since to figure out any consistency at all in them?

Thanks a lot for any advice.

R.

[Frozen North]

Checksums and line counts are consistent between the User Guide and my HP-35s.

[MarkHaysHarris777]

(03-29-2014 11:35 PM)r. pienne Wrote:  I know Pauli's famous HP 35s bug list says "checksums are meaningless", but I'm wondering has anybody here managed since to figure out any consistency at all in them?

Some of the bugs on the bug-list are really quirks. For instance, number 15. Yes, some programs cannot be interrupted... especially if you put a tight loop in them! It has nothing to do with whether the program should be interrupted without a PSE, its that the PSE breaks the tight loop allowing the firmware to 'see' the interrupt. The 35s is using 1980's technology-- its 8502 processor core primarily. Welcome to 8 bit unprotected 'slow' programming.

The checksum and program size numbers are NOT a bug, nor are they meaningless. The problem is that the slightest change in the 'stored program' including the label or spaces changes the check sum. On my 35s the same program instructions keyed against the same label 'always' produce the same check sum. The sample programs from the manual always produce the same checksum in my unit, and the program lengths in bytes are always consistently the same... also reflected in the decrement of available bytes from the heap. If you key a program into label P the checksum will be different than the 'same' program keyed into label A, or Q. A program without a label will produce a different checksum than the very same program keyed with a label.

I am still working on verification of this next point. I suspect that the 'order' of the program labels alphabetically in relation to the top and bottom of program space may affect the checksum (I'll get back to you on that).

The bottom line for me is that I cannot reproduce the checksum|size bug on my 35s unit/ its very consistent.

Cheers

[Mark Hardman]

(01-21-2015 11:01 PM)MarkHaysHarris777 Wrote:  The bottom line for me is that I cannot reproduce the checksum|size bug on my 35s unit/ its very consistent.

There are many, many examples on the old forum site.

For example:

35s checksum problem

I would say that the issue has been documented to the point that it cannot be disputed.

Marcus, we would all like to welcome you to this forum. Could I please ask you a small favor? This is a small, quiet community (snicker). Could you please not shout? It really isn't necessary.

Thanks.

[MarkHaysHarris777]

(01-21-2015 11:12 PM)Mark Hardman Wrote:  35s checksum problem

I keyed the example from above, and I get the checksums of the original author:
LBL G
1.4
LBL C
1.4

LBL G, LN= 9, CK= D23F
LBL C, LN= 9, CK= 18BC

These are consistent, and I cannot get them to change. I do notice another thing though... there are no RTN instructions. This problem may have to do with the branching calculation offset problem (which I do see often) because it can't figure out exactly which instructions to include in the checksum?
In my coding I always use labels, keep the labels in order, and make sure the GTO XEQ instructions don't change on editing. My checksums don't change.
The other thing I am wondering about is the build date. My unit was built in late november 2014. It still shows revision 0 2007--- but I'm wondering if they have made some subtle changes reflected in the new units, but forgot to bump up the revision level. (not likely)
Another thing that may affect this is that I reserve 101 indirect memories, which changes where the program code is located, which might make a difference on how the checksum is calculated.
By the way, my equation checksums and lengths are also very consistent. I have another HP35s on order for the purpose of cross development and experimentation; maybe I can get to the bottom of it.

Sorry about the font... I'm gonna blame my browser... the editing options are apparently not cooperating for me between my browsers. Hopefully this is better.

Thanks for the heads up! Nice to meet you Mark; have a great day.

[r. pienne]

Since I posted my problem, I discovered that the programs had in fact been changed - indirectly. I keep all my general-purpose subroutines in one "program" (Z002, Z074, Z188, etc.), and when I changed one of them, the following ones all got renumbered, and so the programs using them also changed. That explains the changing checksums. It's actually quite a neat system I think.

R.

[MarkHaysHarris777]

(01-22-2015 09:59 AM)r. pienne Wrote:  Since I posted my problem, I discovered that the programs had in fact been changed - indirectly. I keep all my general-purpose subroutines in one "program" (Z002, Z074, Z188, etc.), and when I changed one of them, the following ones all got renumbered, and so the programs using them also changed. That explains the changing checksums. It's actually quite a neat system I think.

R.

Thank you for your candor, and for some hints moving forward. I am going to be diving into this a bit in a week or two when I can get my hands on a second unit. Without the second unit for control|compare|contrast it will not be possible to speculate further. I truly suspect that for *everyone* the bug is simply not understanding how the checksums are calculated and what the rules are. Once we iron that out and publish it on the site somewhere folks can have a better confidence in the length checksum system. I too agree its a pretty neat system.

Thanks, good to meet you!

[rprosperi]

(01-23-2015 05:59 AM)MarkHaysHarris777 Wrote:  Thank you for your candor, and for some hints moving forward. I am going to be diving into this a bit in a week or two when I can get my hands on a second unit. Without the second unit for control|compare|contrast it will not be possible to speculate further. I truly suspect that for *everyone* the bug is simply not understanding how the checksums are calculated and what the rules are. Once we iron that out and publish it on the site somewhere folks can have a better confidence in the length checksum system. I too agree its a pretty neat system.

Thanks Marcus for taking on this job, hopefully your investigation will reveal some pattern which makes the checksum variations to be clear and maybe even predictable.

I think many of us want to use and love the 35S more, but its hard to shake the loss of confidence that occurs when one encounters this checksum thing (usually leading to huge, frustrating amounts of time double- & triple-checking code, etc. only to eventually discover it's fine, it was a 35S problem, not yours).

The many other bugs are well documented, but are far less likely to be issues for most use, but the checksum thing was, for me, a deal breaker. As some have pointed out, we all got along fine with long programs in older machines before the checksum feature even exisited, but in the 35S case we have something staring at us specifically saying "this program is NOT correct" (compared to source that was copied).

Given the 35S role as the last RPN Calculator HP will make (thus HP-35 "bookends") it is particularly sad that early on, HP chose to not fix the problems, thus more and more 'bad' machines enter the market, making a recall (or whatever) even less likely due to the increasing liability. No doubt it occurred during a management change in the calculator group (statistically likely anyhow...). Given the real cost numbers and HP's focus shift from quality to operating margin, I'm not sure I would have made a different decision were I in that seat, but I'd like to think I could have argued that treating it that way would guarantee it would be the final machine of that type.

Anyhow, thank you Marcus and Didier for giving me good reasons to take out my 35S and love it a bit more. I look forwad to your results.

[MarkHaysHarris777]

(01-23-2015 02:14 PM)rprosperi Wrote:  Given the 35S role as the last RPN Calculator HP will make (thus HP-35 "bookends") it is particularly sad that early on, HP chose to not fix the problems, thus more and more 'bad' machines enter the market, making a recall (or whatever) even less likely due to the increasing liability.

I also am viewing the 35s as a 'bookend' to an era. But I decided to apply a little logic to the evidence. I mean, what is, is. The unit is selling. The unit is still being manufactured. The unit is being used for real work, and the unit is recognized as the most powerful programable exam calculator (at least in the United States). How can this be if its sooo buggy? Begs the question.

I also have been thinking about the pre-release testing. Did HP NOT send this unit out to professionals prior to release to have it tested? Sure looked that way (I was initially shocked). ... 'till I started looking a little closer. For what ever reasons HP had, nobody recalls a calculator unit that works well within design goals and engineering criteria, and continues to sell. The very fact that the unit was not pulled from the market (yet continues to be sold and used professionally) speaks volumes about whether the 'buggy' or 'flaky' nature of the unit is bonafide. Yes, it has a couple of minor annoyances, and one gotcha. As a matter of fact, it really only has *one* gotcha. WARNING: Do not put the unit into a tight loop without a stop or pse. DONT do THIS:
A001 LBL A
A002 GTO A001

That is a little like Daffy Duck's famous, "Don't ever push the purple button!"

If you put the unit into a tight loop (intended or not) you might not (and probably won't depending) be able to pull it back with anything short of removing its batteries for a time, and losing your work. This is not a bug. This is an inherent 'gotcha' with the 8502 interrupt mechanism, including the scan routine(s). This 'gotcha' existed all the way back to the 8502's little sisters, the 6510 and the 6502. If you put the 6502 into a tight loop on the VIC20 (from Commodore) you would indeed have to turn it off to get it back. (ask me how I know?)
So, DONT DO THAT ! Never push the purple button! This problem is on the bug-list as number (15) and because it can happen if a would-be programmer is not aware -- well it has a very negative (although undeserved) infamous perception.

I will have a more formal response to the bug-list a little later; still thinking through it, and I do want to be as complete as possible.

I will give you a little hint about the perceived checksum difficulty-- what constitutes the smallest program unit of execution on the 35s, and what are the limits in storage for checksum computation for a given set of labels over a given memory range? If a would-be programmer does not understand the rules of engagement, then the checksums cannot be used to their advantage. I'm still experimenting with this, but for now I am convinced that the checksum mechanism is working as designed.

Thanks for the encouragement.
Cheers

[rprosperi]

(01-24-2015 07:51 AM)MarkHaysHarris777 Wrote:  I will give you a little hint about the perceived checksum difficulty-- what constitutes the smallest program unit of execution on the 35s, and what are the limits in storage for checksum computation for a given set of labels over a given memory range? If a would-be programmer does not understand the rules of engagement, then the checksums cannot be used to their advantage. I'm still experimenting with this, but for now I am convinced that the checksum mechanism is working as designed.

Your comments motivated me to RTFM. Again. The section (p. 13-23) which describes the role of the checksum states:

Quote:The checksum is a unique hexadecimal value given to each program label and its
associated lines (until the next label).

Don't believe I ever thought much about the parenthetical note (my emphasis added above).

Looking further into the manual, sections 15, 16, and 17 list many sample programs to illustrate various topics, but in each listing, the [SHOW] Checksums are included within the listings at the end of each 'routine', or stated differently, just before each new label. This would seem to imply the checksum shown is only for the section between the prior label (inclusive) and the following label (exclusive).

So, maybe it is functionaling correctly, though with a perhaps unintuitive behavior. I think most folks would assume a program checksum is just that, a checksum for the program, when in fact they really are routine checksums.

As you say, more research is needed, just thought I would share that discovery, which could be documenting that I'm the only idiot that never noticed this.

Thanks.

[MarkHaysHarris777]

(01-24-2015 05:53 PM)rprosperi Wrote:  As you say, more research is needed, just thought I would share that discovery, which could be documenting that I'm the only idiot that never noticed this.

There are several things I know for sure at this point:
1) CK is based on labeled groups of lines, NOT associated lines from other labeled units (although associated lines from other labeled units CAN change lines of a calling program, and therefore CAN change the calling program's CK <--- this is usually what happens to folks...
2) Ck is NOT based on ordering of labels, nor is it based on position in program storage.
3) CK is NOT based on variable storage, nor indirect memories
4) If the labeled unit does not change, then the CK WILL NOT CHANGE (I have not been able to invalidate this claim taking 1-3 into account, thus far.

Consider the following: (keep in mind this is NOT a real program... know one would do this:

Code:



     A001  LBL  A            ; LN=9     CK=24F1
     A002  1.2
     B001  LBL  B            ; LN=9     CK=7534
     B002  1.3
     C001  LBL  C            ; LN=9     CK=28C6
     C002  x
     C003  RTN
-

Now consider please, do we have three programs, or one program? If you XEQ A all three will run... try it.

Changing any of the lines, in any of the segment labels, will ONLY change the CK of that labeled unit (even though ALL the lines of the program are associated with the entire program). Changing x to / in C will ONLY change the CK of C, not A, nor B.

Now consider this monster... and remember, nobody would code this... but they code stuff LIKE it all the time:

Code:



     A001  LBL  A                ; LN=9   CK=8550
     A002  XEQ  B002          ;
     A003  RTN                    ;
     B001  LBL  B                 ; LN=21  CK=2889
     B002  1.2                      ;
     B003  1.3                     ;
     B004  +                        ;
     B005  RTN                     ;

-

Now consider please (after studying) "what will happen if insert x<>y after B001?"

Will the CK for B change alone? Will the CK for A also change????

In fact the CK for both will change, and this is a BIG FAT surprise to most would-be programmers of the HP35s; especially if some time passes before they update B. Let us suppose that the coder inserts the x<>y instruction immediately after B001 so that the whole thing looks like this:

Code:



     A001  LBL  A                ; LN=9   CK=B85F       <==oh, look a surprise maybe
     A002  XEQ  B003          ;       <====notice what happens here (recalculated)
     A003  RTN                    ;
     B001  LBL  B                 ; LN=24  CK=7FE0       <=== we expected this change
     B002  x<>y                  ;    CODE INSERTED HERE CAUSES the TROUBLE
     B003  1.2                      ;            <==== entry point of B is renumbered !
     B004  1.3                     ;
     B005  +                        ;
     B006  RTN                     ;

-

Now suppose for a moment that you have many entry points (targets of a GTO(s) or XEQ(s) in a labeled unit (say U for utilities) and you make even ONE change in the utilities labeled unit near the top... yup, ALL of the CKs will change in EVERY SINLGE labeled unit that calls the routines in the U labeled unit because ALL or MOST of the U labeled unit entry points get renumbered, and then subsequently (recalculated) in the calling routines... <===== this is what is happening with most folks experiencing this

The bottom line is that if the CK changes in a labeled unit, then SOME character has changed in that labeled unit (normally due to GTO XEQ target renumbering).

So far, including comments from you, I have yet to find *anyone* experiencing this so-called bug that IS NOT the victim of this scenario; albeit, usually way more complicated than this one.

Now I ask you, (and I'm still researching it and hammering it out to make sure) is it fair to call this an HP firmware bug? Or, is the CK mechanism doing its job as designed by some brilliant engineers and the bug-labeling is really unwarranted (maybe an apology might be in order...)? I ask you?

Food to Think On...
Cheers,

[r. pienne]

The mechanism where insertion/deletion of lines causes following lines to get renumbered, references to those lines updated, and checksums changed accordingly, is certainly not a bug; it's a desired feature. Assuming it works properly.

The bug-list says that checksums are "meaningless", without going into detail. But checksums are supposed to be meaningless; they're a one-way hash of the contents of the program (OK, the inter-label code) designed simply to indicate (yes or no) whether the instructions were entered correctly or not. As long as the checksum for a given block of code (allowing for automatic changes to GTO/XEQ lines) is always the same, then it's working.

I imagine it would not be a simple matter to reverse-engineer the checksum algorithm, so that we could predict the checksum of a program.

I haven't yet seen any evidence that the checksum mechanism is buggy.

R.

[Gerald H]

As a mere human who believes the designers of the operating system also to be human I find the easiest & laziest hypothesis is that the craftsmen erred in their algorithm.

My experience of checksums being useful on other platforms, & in my own imagination of the question, leads me to conclude the HP 35S has a bug in the check sum display.

Should you devotees who believe in the higher values of such "checksums" concoct a convoluted but nevertheless convincing explanation of the vagaries I will contribute further to congratulate you.

So far I can only congratulate you on producing a most humorous thread.

[Paul Dale]

I will stand by my original meaningless comment I'm afraid, even though that was written in haste many years ago. Clearly these checksums are deterministic within the firmware of the 35S and the steps you went through after powering up originally.

That the checksums do, in fact, have a meaning that is somewhat too convoluted for normal users isn't useful or helpful. None of the gymnastics you've gone through to attempt show they are useful is necessary on other checksummed calculators.


- Pauli

[MarkHaysHarris777]

(01-27-2015 11:17 AM)Paul Dale Wrote:  That the checksums do, in fact, have a meaning that is somewhat too convoluted for normal users isn't useful or helpful. None of the gymnastics you've gone through to attempt show they are useful is necessary on other checksummed calculators.

The checksums really only have one useful purpose: to alert the operator (me) that one of my programs has changed (probably by me) because of a recalculation of a GTO or XEQ target because of a called routine renumbering (because of my own editing!). That's it. Here is the rub... if you tell people that the checksum is meaningless they will ignore a 'critical' warning which may lead (probably will lead) to an infinite loop (tight or no) and a lockup. Again, if one of your checksums changes, something is wrong! (and its working as designed).

Now, having said that, the thing people try to use checksums for doesn't really work in practice often, because the author didn't keep up with the published checksum because she thought that the checksums were bogus. Even some of the examples for proof cases of bugs were in this category... when you get down to it you find that the program 'really did' change, or the checksum was just out of date.

But here is another thing... didn't HP users 'like forever' have programming 'without' *any* checksums?

... have to admit it... I'm really wanting to play with the WP34s... I'm closer!

Cheers,

[walter b]

The WP 34S doesn't feature any checksums you can see.

d:-)

[EdS2]

Surely the big win for checksums is when you type someone's program in - you want to know you got it right.
For example, the many digits of pi programs:
http://www.hpmuseum.org/cgi-sys/cgiwrap/...i?read=899

[BartDB]

(01-21-2015 11:36 PM)MarkHaysHarris777 Wrote:  

(01-21-2015 11:12 PM)Mark Hardman Wrote:  35s checksum problem

I keyed the example from above, and I get the checksums of the original author:
LBL G
1.4
LBL C
1.4

LBL G, LN= 9, CK= D23F
LBL C, LN= 9, CK= 18BC

These are consistent, and I cannot get them to change. I do notice another thing though... there are no RTN instructions. This problem may have to do with the branching calculation offset problem (which I do see often) because it can't figure out exactly which instructions to include in the checksum?
In my coding I always use labels, keep the labels in order, and make sure the GTO XEQ instructions don't change on editing. My checksums don't change.
The other thing I am wondering about is the build date. My unit was built in late november 2014. It still shows revision 0 2007--- but I'm wondering if they have made some subtle changes reflected in the new units, but forgot to bump up the revision level. (not likely)
Another thing that may affect this is that I reserve 101 indirect memories, which changes where the program code is located, which might make a difference on how the checksum is calculated.
By the way, my equation checksums and lengths are also very consistent. I have another HP35s on order for the purpose of cross development and experimentation; maybe I can get to the bottom of it.

Sorry about the font... I'm gonna blame my browser... the editing options are apparently not cooperating for me between my browsers. Hopefully this is better.

Thanks for the heads up! Nice to meet you Mark; have a great day.

Checksums are totally useless.

Your example is nugatory and shows lack of investigation.

Checksums change depending on what other programs or equations are in the memory.

First enter another program then enter these programs again. Or save some equations in the equation list. Checksums are different.

Stating they are useful to see if you have accidently changed a program yourself is not really useful. What if you've deleted the program and need to re-enter it? Will you remember exactly what programs and equations were present when you first entered the program?

The use of checksums on other HP calculators has made it easier for others to enter them correctly - hence it being quoted e.g. this hp-32s program has checksums at the end of each label. Now see Pauli's game for the 35s Game for HP-35s, it took me a few hours to key in and no useful checksum meant several more to re-read & test.

And now the cherry on the cake: I had about 15kb of programmes and the batteries died (after leaving the calculator unattended for about 2 months). I have the listings of all these programmes, but do you really think I remember in what order I had entered them or what equations were saved at the point I had originally entered each program? Now I have 15kb of programs to re-enter that I have to spend hours to manually re-check, test etc. to ensure they're error free!!!

The bug list is quite correct - checksums are useless. And it is a bug.

[Gerald H]

(04-01-2015 09:19 AM)BartDB Wrote:  

(01-21-2015 11:36 PM)MarkHaysHarris777 Wrote:  I keyed the example from above, and I get the checksums of the original author:
LBL G
1.4
LBL C
1.4

LBL G, LN= 9, CK= D23F
LBL C, LN= 9, CK= 18BC

These are consistent, and I cannot get them to change. I do notice another thing though... there are no RTN instructions. This problem may have to do with the branching calculation offset problem (which I do see often) because it can't figure out exactly which instructions to include in the checksum?
In my coding I always use labels, keep the labels in order, and make sure the GTO XEQ instructions don't change on editing. My checksums don't change.
The other thing I am wondering about is the build date. My unit was built in late november 2014. It still shows revision 0 2007--- but I'm wondering if they have made some subtle changes reflected in the new units, but forgot to bump up the revision level. (not likely)
Another thing that may affect this is that I reserve 101 indirect memories, which changes where the program code is located, which might make a difference on how the checksum is calculated.
By the way, my equation checksums and lengths are also very consistent. I have another HP35s on order for the purpose of cross development and experimentation; maybe I can get to the bottom of it.

Sorry about the font... I'm gonna blame my browser... the editing options are apparently not cooperating for me between my browsers. Hopefully this is better.

Thanks for the heads up! Nice to meet you Mark; have a great day.

Checksums are totally useless.

Your example is nugatory and shows lack of investigation.

Checksums change depending on what other programs or equations are in the memory.

First enter another program then enter these programs again. Or save some equations in the equation list. Checksums are different.

Stating they are useful to see if you have accidently changed a program yourself is not really useful. What if you've deleted the program and need to re-enter it? Will you remember exactly what programs and equations were present when you first entered the program?

The use of checksums on other HP calculators has made it easier for others to enter them correctly - hence it being quoted e.g. this hp-32s program has checksums at the end of each label. Now see Pauli's game for the 35s Game for HP-35s, it took me a few hours to key in and no useful checksum meant several more to re-read & test.

And now the cherry on the cake: I had about 15kb of programmes and the batteries died (after leaving the calculator unattended for about 2 months). I have the listings of all these programmes, but do you really think I remember in what order I had entered them or what equations were saved at the point I had originally entered each program? Now I have 15kb of programs to re-enter that I have to spend hours to manually re-check, test etc. to ensure they're error free!!!

The bug list is quite correct - checksums are useless. And it is a bug.

I had decided not to contribute any more to this thread, however you, Bart, seem honest & so I'll add my two pennorth.

Some folks believe the Bible more than experience or science - what such folk do with authorities is clear.

Accordingly the God given operating system must be right & any argument against it futile.

[Tugdual]

You may check this http://www.hpmuseum.org/forum/thread-3041.html

I spent a lot of time investigating on Checksums using the emulator to spy the memory.
My conclusion is indeed that checksum are irrelevant and of no use.