35s checksum problem



#2

Hi, folks.

This would have never be mentioned before, HP 35s may have a checksum calculation problem.

I bought two HP 35s, one for office use, others for home use, of which serial number differs at last two digit (CNA 721049xx).

Then I wrote program (to solve transmission line parameters) and entered it into each calculators, to find the same program shows different checksum.

It seems to be HP 35s' problem, since the line length, calculation result, and line by line comparison shows no difference.

For confirmation of the problem, I wrote very simple program as shown below.

LBL G
1.4
LBL C
1.4
LBL K

One shows,

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

The other shows,

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

While using (include programming) the first one, its checksum had been changed to the different value, as

LBL G, LN= 9, CK= 5966
LBL C, LN= 9, CK= 1427

How about your 35s?

(Please allow my poor English.)


#3

Miner are different:

G-->535D
C-->532C
K-->2436

Entering another program doesn't change the sums, nor does changing to Hex.


#4

Mine are different from the others already mentioned too:

C = 700E
G = 8A28

Looks like the checksum is no longer a useful function.

Am I the only person here that feels like this is the buggiest calculator HP has made since the 49G. The nicer keyboard and more usable memory aside, everything else about this machine seems to be a giant step backwards.

It's time to stop playing with the 35s until there's a decent version released. Every time I pick it up to try something on it I run into another bug, it's just no fun. (OTOH, the Casio fx-9860G Slim looks like it might be a fun machine to program.)

Edited: 10 Aug 2007, 6:56 p.m. after one or more responses were posted


#5

Quote:
It's time to stop playing with the 35s until there's a decent version released.

Am I the only person who doubts that there will be release of "a decent version"? They stuck with the 33s, and the 35s and 50g represent further development, but it's hard to believe this is worth the company's time.

The 35s seems part of the recent wave of nostalgia that includes rebuilding "The Garage". I wonder how much effort (and how much money) they'll be devoting to support this symbolic reminder of past glory?

Edited: 10 Aug 2007, 1:28 p.m.

#6

I have had it for 3 days now and am becoming quite fond of the device. If you are a power user with a requirement for complex matrices you will be disappointed. I am a "light weight", just give me a good solver and a programming enviroment for the rest of my needs, and I am happy. The calculation "history" is a new experience for me, and I really like that feature.

#7

I tend to agree with you, Katie.

What's perhaps most frustrating for me is that HP doesn't appear (or won't) include beta testers in the production process. Yeah, I get the whole thing about company proprietary information, keeping secrets and making sure the competition doesn't find out about new calcs, but THIS fiasco is exactly why they need to break out of that mold. Hopefully Sam can wield some power in this and sees the value in having more folks beta test future calcs, even if only to look for bugs. I'm quite sure that had 20 of us in this group had the calc for two weeks, we would have found **ALL** of these bugs and given back to HP a really valuable contribution in terms of quality.

Lessons from the software world need to be applied here. Beta testing is good. Especially with more and more complex systems.

* * *

I still like this calc. I will play with it and enjoy it, but it has lost some of the "shine" due to these bugs. I just hope they fix them and listen to the truly enthusiastic users.

You know, this reminds me of something Disney did a while back. Let me tell you a story...

After Disney killed the Electric Light Parade, they needed to replace it with something similar but new and fresh. They hired a Hollywood guy to create "Light Magic" in 1997, a parade with even more lights, and kind of themed after fairies.

They had a one night premier for cast members only. It didn't go over so well. A lot of cast members disliked it, and thought it wasn't up to standard. The cast members suggested that the Annual Passholders (AP's) check it out. Disney considered.

A week later, they offered Annual Passholders a chance to view the parade. My wife and I went up to Anaheim and saw it twice on the night it was first out. Disney gave out comment cards and asked for input. Aside from written comments, AP's *lined up* outside the customer relations building to complain about the parade. It was HORRIBLE. It was whiny, the music sucked, there was no story, no tie-in to old Disney characters and some of the fairies were downright evil and scary looking. Literally, children cried when it went by. Some people were just stunned. With an overwhelming majority of dedicated AP's complaining, Disney decided to delay the opening by six weeks to "make repairs".

The parade opened six weeks later, with virtually no changes (!!), and was panned in the press. People hated it. It lasted all of three months before it was killed, and the Disney head who created it was fired. Now, you can barely find mention of "Light Magic" anywhere in Disney-dom. It has been blacklisted. It was incredibly painful for Disney.

The lesson here was that Disney failed to realize who their TRUE fans were and they didn't let them HELP. No one is more dedicated to Disney than the AP's. These are the people who spend hundreds and thousands of dollars every year on passes. They talk up Disney with friends, family and anyone who will listen. Like my wife and I, we would visit Disneyland 2-3 times a month. Some people we know go every other DAY.

These people truly are the hardcore Disney fanatics. Probably not one naysayer in the group. Yet when that same fan base said "wow, this parade really sucks! I mean REALLY!", Disney discounted it. They had -- at their ready disposal -- almost everything they needed to fix the parade, but were too proud to call upon outside help.

Suggestions were coming in left and right. Those were the same suggestions that made it into the New Electric Light Parade three years later (that everyone loves now, BTW). But instead of taking advantage of those who love Disney and are working FOR them, they chose not to. Greed, pride, whatever. It could have been different.

Now, to be fair, HP has never said they WANT input from us hardcore types prior to release. But it would seem to make a lot of sense. Don't stress about 20 more people knowing about a new calc because they have a pre-release version -- JUST DO IT. I don't think we'd be in this situation today had HP given some hardcore users an opportunity to test out the HP-35s prior to announcement.

Anyhow, I somehow climbed up on a soapbox, so now I'd better get off... ;-)

thanks,
bruce


#8

I think you sum it up very well Bruce. This is very sad for HP users. HP either need to decide if they wish to stay in calculator market, or just get out. Don't sell junk, because we don't want junk. Don't follow Bill Gates model and rush to market with lots of bug and expect users to like it. Take time and bring quality to market with everything. With product, with feel, with instruction book, and yes, even with packaging.

#9

Katie,

Quote:
Am I the only person here that feels like this is the buggiest calculator HP has made since the 49G. The nicer keyboard and more usable memory aside, everything else about this machine seems to be a giant step backwards.

It's time to stop playing with the 35s until there's a decent version released. Every time I pick it up to try something on it I run into another bug, it's just no fun.


As an admirer of your excellent posts, this time I would have to disagree. You are right, this is obviously a serious bug. IMHO, your words quoted above show an anger of a perfectionist against the obviously too early released HP35s.

However, may I suggest to put it this way? Checksum function, though very important, did not exist on the HP35 (there was even not any sum there to be checked;). Further on, the same applies to HP67 (my dearest), HP41, ... The checksum came out with later sophisticated models, as a very practical way to find out if the program was correctly input (meaning identically to the pattern), or not.

Would it be better, once we are sure that the checksum function on HP35s is incorrect, to check the correctness of the program by means of a real life test example, supplied by the program? A computer science specialist of your format would certainly say: "No way. You cannot pass through all the branching combinations in a program by a single test example". An engineer in me says: "I would be happy to know that this program works correctly for the presented example, as I expect that my particular problem would not differ too much of it". All in all this is how it was done when there was not a checksum available at all.

Meanwhile, I am happy to see the ENTER key in the right place, nice click keyboard, two line display (mine is not slanted), RAD indicator on the display, etc. If we look again at our posts during the last three or four years, almost all of us here were thinking that after HP48GX even the ENTER key would never come back to its place.

What I can see from what you said, despite the strong bad feelings you have against your machine, you still keep on playing with your brand new, still in production, nice looking, but sometimes strange behaving, HP35s.

Let us love this buggy little beast (at least until the new one comes)! You may check my biography to see how I did this since 1978.


#10

I do love this calc, but...

The lack of a checksum function for programs was one of the major complaints about the 33s. You couldn't tell if your program was entered correctly or not. HP obviously listened and brought it back in the 35s, but I'd submit that this is truly a very important part of the calc.

thanks,
bruce


#11

Has anyone established that the programs are giving incorrect results with differing checksums?

For me, the apparent checksum bug is no problem at all. All of my programs are written myself, and I always test them by solving a few different problems whose results I know. I never bother with checksums.

While not perfect, I think the 35s is a significant step in the right direction. I remember posts from a couple of years in the past where several people confidently predicted there would never be a large enter key again, that there would never be a successor to the 33s. Well, here it is, and many of the 33s complaints were addressed. Overall I am happy with the 35s, (but I won't be selling my 42s or 32sii on ebay).

With that said, it would have been better for HP to delay release until HP had identified these bugs and corrected them. There is less tollerance for these bugs after the bad taste that the 33s left in everyone's mouth. This is not the first HP to be released with bugs, and hopefully yhey will be corrected in time.

#12

Nenad,

You're a better person than I! I'm not sure that I can

Quote:
love this buggy little beast

because I don't trust it to show me the correct results. I also feel like HP has made a semi-conscious decision to not put the time/money needed into properly engineering this and has left it up to us, the HP fans, to do the testing for them at no cost (even better they make money by selling to us).

If I define "bug" *very* conservatively to be: something that causes the calculator to display a wrong or misleading result and that I (personally) can reproduce, here's a short list:

(1) in a program:
VIEW (I)
PSE
this will show the wrong value of I

(2) X<>(J)
will show INVALID(I) if J has and invalid address in it.

(3) the checksum bug (the circumstances leading to this error are
still unknown)

(4) SYNTAX ERROR when entering vectors that are valid (the
circumstances that lead to this error are still unknown).
This one bothers me the most because it requires at least a
memory variable clear to correct, maybe a full memory clear.

(5) the cosine near 90 miscalculation

(6) in a program:
"RADIX."/"RADIX," display change based on the display mode.

Note that these are all bugs that have nothing to do with differences bewteen the calculator and the manual.

-Katie


Edited: 11 Aug 2007, 10:21 p.m. after one or more responses were posted


#13

Katie,

you said:

Quote:
Nenad,

You're a better person than I!


This is simply not true! I personally know this when you sent me a piece of something to repair something else, what I did without a problem;) You are a real friend! Thanks again, this time in public.

Your previous post stating the 6 (up to now) bugs found in our lovely "little beast" proves this once again. It must be appreciated when you approach the buggy 35s problem without any negative feelings, but just stating pure facts.

I am sure that if HP invent produced an excellent calculator (say HP45s) in all aspects (not to point them out again) and releases it after a year of beta testing by 99 posters to the moHP, the 100th poster would come out with a bug finding. This proves something about the competence of our community here.

#14

I'll add two more bug to the list.

The LN= display is bogus for programs that contain inline numbers (& possibly for equations).

Also insertion of a label at the end of a 999 step program isn't allowed.

- Pauli

#15

Forgive me. Let me see if I can succinctly state the issues with the checksum (just so I can understand any ramifications) :

The checksum for a particular program varies from unit to unit for the 35s model.

The checksum for the same program further changes after the program is run.

*

Now let ask, aside from identification and verification of the similitude of the program (either on different 35s units or on the same one after execution on the calculator), does this affect any other function on the calculator?

#16

Lyuka, here are the results after keying in the same programs on my two HP35s calculators:


First 35s: CNA 72101944

LBL G, LN= 9, CK= 10D7
LBL C, LN= 9, CK= ADAE

Second 35s: CNA 72104162

LBL G, LN= 9, CK= 8A28
LBL C, LN= 9, CK= D6F8

Very interesting. This seems like a real bug!


#17

CNA 72102370

LBL G -> LN=9 CK=8A28

LBL C -> LN=9 CK=D6F8

[snide]Now, what was that checksum to be used for?[/snide]

(I still love the calc, but this will make more difficult the sharing of any significant programming.)


Edited: 10 Aug 2007, 12:50 p.m.


#18

Strange... I've been following along all the examples in the HP User Guide that came with the calculator (up through chapter 11) - and the checksums have always matched the examples...


#19

Have you CLEARed ALL before each program entry? I wonder if the presence of other program(s) is what affects the checksums?


#20

I would like to ask people who will take the time to do so to key in the indirect data register packing program from this learning module:

indirect register packing program

and see if the checksum matches what is in the module. In addition to seeing if the checksums come out the same, you'll get a chance to play with a really fun program, even if I say so myself. :-)

The checksum for this program is the same on different machines that I have tried it on.

In my 35s review for datafile:

35s review

I note on page 11 that MEM does not change at times when I think it should.

Perhaps this is related?

Gene

P.S. I too get a different checksum for the short program shown here. But, I get the same checksum for the indirect data register packing program on different machines.


#21

I have 2 HP-35s calcs (3 if you include the one I sent to Germany with my son...)

I entered the indirect register packing program and it appears to function perfectly, but does not have the same checksum. It reports 42C8 versus the expected C4F6.

Serial # CNA 72101735

I will try it on my second unit when I get a chance.

I entered and double checked the program in my second calculator. It works fine but yields a checksum of 1A09...I only utilized the EQN key to enter the stack register functions...

The second calc serial number is # USA 72103834

I cleared both calculators and entered the program from scratch - This yielded E9F8 on both. I had a simple program that did some register calcs and one sub call to a line number and if I enter that program on its own has a checksum of 90F4 but if it is entered after the indirect access routine it has a checksum of 85D0.

Edited: 12 Aug 2007, 11:16 a.m.

#22

On CNA 72102370 I get LN=338 and CK=E9F8. (It appears to run fine.)

What's dismaying, of course, is that I don't really know now whether I've made some subtle mistake in entry, or whether the checksum is truly different. We don't really know whether I've provided any useful diagnostic information.

It kinda' pulls the rug out from beneath the whole program sharing process, doesn't it?

Bummer!

(I'll perform a line-by-line comparison of the program and the listing again . . . )

-- Edited -----------------------

It still looks & acts fine, and I still get CK=E9F8 (FWIW).

Edited: 10 Aug 2007, 2:20 p.m.


#23

Paul, that is VERY strange. I have a version of this program just prior to release that gave a checksum of E9F8. Hard to believe that is coincidence.


#24

Well it is a deterministic machine. We just don't know all the influences that "determine" the checksum. (To state the obvious, apparently there's at least one more factor involved than we'd expect!)

FWIW,

I entered the program from top to bottom, and noticed a different checksum.

Reviewing it, I found one of the equations had been entered "IDIV(REGT-3,3)". (I don't remember whether it was the IDIV or RMDR equation, however.)

I corrected that, and got CK=E9F8. I can find no obvious mistakes remaining.

Checking on one possible source of confusion, I changed one of the equation minus operations to the unary minus (the "+/-" key). That changed the checksum, but also gave me a SYNTAX ERROR upon execution. I changed it back, and still have E9F8.

I deleted the only other program in the machine, and that didn't change Program Y's checksum. Neither did any of the CLEAR options (other than ALL, of course).

Again, FWIW.


Edited: 10 Aug 2007, 2:36 p.m.


#25

"Deterministic machine"

Aha. That should be true.


Sometimes I really don't believe that anymore with windose machines though ;-)

#26

It seems that the inline number affect the checksum to go wrong.

Other test programs, which use no inline numbers, like as shown below, shows the same checksum, so far.

LBL K, LN=57, CK=D0B7

LBL K
CLx
ENTER
ENTER
ENTER
-
*
SIN
+
COS
SQRT
1/x
x^2
LN
10^x
y^x
PI
/
RTN


Edited: 10 Aug 2007, 3:09 p.m. after one or more responses were posted


#27

Interesting . . .

I formerly entered the four vectors (on lines Y032, Y034, Y036, Y071) into the program using only the "[]" key.

Now I've changed all four entries to EQN, then [], then the numerals and commas. Result: LN=338 CK=0978.

Gene: Does your "EQN" annunciator show when scrolling past any of the four vector entry lines?

Edited: 10 Aug 2007, 3:01 p.m.


#28

EQN only shows up for lines that use the stack registers, like REGT.

That would be lines:

Y012
Y018
Y024
Y051
Y064
Y066
Y068

which agrees with the keystroke instructions on page 4 of the learning module.

There is no need to use EQN for lines Y032, Y034, Y036 and Y071. These can be directly keyed without the EQN key.


#29

Right -- I know there is no "need" to use EQN. But in entering numbers (or, it turns out, vectors) directly on the stack, one may use EQN or not. (You may remember that on the 33s one may save a number of bytes by using EQN rather than direct numeric entry in programs.)

Regardless, in light of what Lyuka has just reported, it would be interesting to note whether everyone gets the same checksum (0978) by using EQN for the four vector entry lines (Y032, Y034, Y036, Y071) rather than simple direct entry.

It's a long shot, but what else have we got? Discovering certain rules of entry (like using EQN wherever possible) that would guarantee consistent checksums would be a useful workaround until H-P comes out with a spruced-up version.

-- Edited (again) -------

Just in case, a couple more points of comparison:
Entering programs G & C as shown in Lyuka's original problem report, but using EQN for each "1.4" line, I get:

LBL G -> LN=9 CK=0A3A

LBL C -> LN=9 CK=C145

Edited: 11 Aug 2007, 5:09 a.m.


#30

As indicated above I'd briefly hoped, assuming the problem was indeed related to directly-coded numerics within programs, that coding those as EQNs would somehow fix things.

I substituted EQNs for each of the four vector "direct-entry" lines in the indirect register packing program on two different machines, and got different results. The checksums differed also for the trivial programs "G" and "C" in the post that started this thread, when treated the same way.

Apparently, EQN is not going to help here.

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

#31

Quote:
It seems that the inline number affect the checksum to go wrong.

I pointed out last week or the week before that inline numbers make the size go wrong...

- Pauli

#32

I cleared the memory of both my calculators and enter the program, ten lines at a time and they never differed. I have got the same checksum as Paul.

CNA 72102361 and CNA 72102362 both LN=338 CK=E9F8.

It seems that it has something to do with memory management.

#33

In my CNA 72102361:

LBL Y
LN = 338
CK = 3EA9


Regards,

Miguel

Edited: 10 Aug 2007, 3:43 p.m.

#34

Hi Gene,

When I enter the indirect data register packing program, I get the following

LBL Y
LN= 338
CK= C174

At first I wondered if spaces made any difference, so I changed line Y068 from:

Y068 REGTx[0,0,1]

to:

Y068 REGTx[ 0, 0, 1 ]

But of course that changed the LN as well, from 338 to 342. So I don't think that has anything to do with the checksum problem.

Very odd indeed. HP, help!

#35

Quote:
Have you CLEARed ALL before each program entry? I wonder if the presence of other program(s) is what affects the checksums?

I don't think this is the issue. The examples in the manual seem to be reproduced no matter the location in memory nor the label.

Still looking...

#36

Quote:
[snide]Now, what was that checksum to be used for?[/snide]

Digital Rights Management?

Make sure you can't copy my programs.


We want DRM-free calcs :-)

-- alain.


#37

Well, yes. As noted elsewhere, random checksums do tend to inhibit accurate duplication.

We'll have to get in touch with Steve Jobs. iTunes rights protection issues? Solved by H-P. (Invent.)

#38

Hi,

I would like to know if someone has the same checksum as me, entering the TVM routine. CK=7940

Thanks,

Miguel


#39

I get CK=D073. Example results match yours exactly.


#40

Hi Jeff,

Could you please try these, if you still have TVM on your calculator:

1.- Recalculate Checksum.

a) Clear all variables (direct and indirect variables).
b) Erase the last RTN of the program and reenter it.
c) read the checksum (mine = 23A5).

if that does not work:

2.- Machine reset and recalculate.

a) Push the reset button in the back hole of the calculator.
b) As previous Erase last RTN and reenter it.
c) Read the checksum.

When I entered TMV in both my, 35s the checksum was different
(23A5 and 7940 respectively). I made a machine reset (it is not
destructif) and after that, erasing the last instruction made them
to recalculate and show the same checksum. Once reentering the
last instruction (line T038 RTN) both showed the same checksum = 23A5)

Thanks for your help,

Miguel


#41

The checksum of your program stubbornly remained D073 after each of the actions you requested. Do you have any other programs in your calculators?


#42

In one I only have it, in the other I added Gene's program (CK=E9F8)and the checksums for the tmv remained the same in both calculators. I thought I was into something but I think the mistery is deeper...

Thanks Jeff.

#43

Can someone repost the "TVM routine?"

Thanks.


#44

Accurate TVM for HP 35s by Miguel Toro


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP 35S keyboard problem Nick R 26 6,155 08-11-2011, 12:00 PM
Last Post: Thomas Radtke
  HP 35s - Choosing Initial Guesses for SOLVE problem Pablo P (Spain) 3 1,302 10-03-2010, 08:35 PM
Last Post: Karl Schneider
  HP-28C ROM checksum addresses? Christoph Giesselink 0 798 07-25-2010, 08:25 PM
Last Post: Christoph Giesselink
  HP 35s checksum repeatability observed JJB299 0 755 06-15-2009, 10:06 AM
Last Post: JJB299
  HP 35s - Problem with conversion from polar to rectangular coordinates. Samir Kopas 1 864 08-31-2008, 10:58 PM
Last Post: V-PN
  HP-35s : problem with vector input Jean-Michel 3 1,379 12-14-2007, 05:03 AM
Last Post: Jean-Michel
  More about Checksum Miguel Toro 8 2,330 08-19-2007, 07:27 PM
Last Post: Vincze
  HP-41 program checksum Jean-Marc 2 1,006 04-21-2006, 04:44 PM
Last Post: JeanMarc
  33s CHECKSUM issue: old/new ECL 11 3,109 10-30-2005, 10:43 PM
Last Post: James M. Prange (Michigan)
  HP41 ROM Checksum Meindert Kuipers 4 1,371 10-25-2004, 02:30 PM
Last Post: Meindert Kuipers

Forum Jump: