The Museum of HP Calculators

HP Forum Archive 17

 35s checksum problemMessage #1 Posted by Lyuka on 10 Aug 2007, 10:05 a.m. 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.)

 Re: 35s checksum problemMessage #2 Posted by bill platt on 10 Aug 2007, 11:41 a.m.,in response to message #1 by Lyuka Miner are different: ```G-->535D C-->532C K-->2436 ``` Entering another program doesn't change the sums, nor does changing to Hex.

 Re: 35s checksum problemMessage #3 Posted by Katie Wasserman on 10 Aug 2007, 12:43 p.m.,in response to message #2 by bill platt 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

 Re: 35s checksum problemMessage #4 Posted by Paul Brogger on 10 Aug 2007, 1:12 p.m.,in response to message #3 by Katie Wasserman 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.

 Casio fx-9860G Slim Message #5 Posted by Donald Williams on 10 Aug 2007, 1:30 p.m.,in response to message #3 by Katie Wasserman 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.

 Re: 35s checksum problemMessage #7 Posted by Vincze on 10 Aug 2007, 5:45 p.m.,in response to message #6 by Bruce Bergman 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.

 Re: 35s checksum problemMessage #9 Posted by Bruce Bergman on 11 Aug 2007, 10:59 a.m.,in response to message #8 by Nenad (Croatia) 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

 Re: 35s checksum problemMessage #10 Posted by Brian Healy on 11 Aug 2007, 3:58 p.m.,in response to message #9 by Bruce Bergman 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.

 Re: 35s checksum problem -- short list of bugsMessage #11 Posted by Katie Wasserman on 11 Aug 2007, 2:42 p.m.,in response to message #8 by Nenad (Croatia) 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

 Re: 35s checksum problem -- short list of bugsMessage #12 Posted by Nenad (Croatia) on 11 Aug 2007, 4:29 p.m.,in response to message #11 by Katie Wasserman 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.

 Re: 35s checksum problem -- short list of bugsMessage #13 Posted by Paul Dale on 12 Aug 2007, 4:41 p.m.,in response to message #11 by Katie Wasserman 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

 Re: 35s checksum problemMessage #14 Posted by Ed Look on 10 Aug 2007, 10:39 p.m.,in response to message #2 by bill platt 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?

 Re: 35s checksum problemMessage #15 Posted by Seth Morabito on 10 Aug 2007, 12:10 p.m.,in response to message #1 by Lyuka 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!

 Re: 35s checksum problemMessage #16 Posted by Paul Brogger on 10 Aug 2007, 12:45 p.m.,in response to message #15 by Seth Morabito 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.

 Re: 35s checksum problemMessage #17 Posted by Kevin Kitts on 10 Aug 2007, 12:53 p.m.,in response to message #16 by Paul Brogger 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...

 Re: 35s checksum problemMessage #18 Posted by Paul Brogger on 10 Aug 2007, 1:03 p.m.,in response to message #17 by Kevin Kitts Have you CLEARed ALL before each program entry? I wonder if the presence of other program(s) is what affects the checksums?

 Re: 35s checksum problem - another testMessage #19 Posted by Gene Wright on 10 Aug 2007, 1:17 p.m.,in response to message #18 by Paul Brogger 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: 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: 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.

 Re: 35s checksum problem - another testMessage #20 Posted by Dave Johnson on 10 Aug 2007, 1:48 p.m.,in response to message #19 by Gene Wright 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.

 Re: 35s checksum problem - another testMessage #21 Posted by Paul Brogger on 10 Aug 2007, 1:56 p.m.,in response to message #19 by Gene Wright 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.

 Re: 35s checksum problem - another testMessage #22 Posted by Gene Wright on 10 Aug 2007, 2:21 p.m.,in response to message #21 by Paul Brogger 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.

 Re: 35s checksum problem - another testMessage #23 Posted by Paul Brogger on 10 Aug 2007, 2:28 p.m.,in response to message #22 by Gene Wright 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.

 Re: 35s checksum problem - another testMessage #24 Posted by bill platt on 10 Aug 2007, 10:13 p.m.,in response to message #23 by Paul Brogger "Deterministic machine" Aha. That should be true. Sometimes I really don't believe that anymore with windose machines though ;-)

 Re: 35s checksum problem - another testMessage #25 Posted by Lyuka on 10 Aug 2007, 2:42 p.m.,in response to message #21 by Paul Brogger 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

 Re: 35s checksum problem - another testMessage #26 Posted by Paul Brogger on 10 Aug 2007, 2:54 p.m.,in response to message #25 by Lyuka 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.

 Re: 35s checksum problem - another testMessage #27 Posted by Gene Wright on 10 Aug 2007, 3:03 p.m.,in response to message #26 by Paul Brogger 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.

 Re: 35s checksum problemMessage #28 Posted by Paul Brogger on 10 Aug 2007, 4:22 p.m.,in response to message #27 by Gene Wright 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.

 Re: 35s checksum problem -- EQN didn't helpMessage #29 Posted by Paul Brogger on 11 Aug 2007, 5:16 a.m.,in response to message #28 by Paul Brogger 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.

 Re: 35s checksum problem - another testMessage #30 Posted by Paul Dale on 12 Aug 2007, 4:39 p.m.,in response to message #25 by Lyuka 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

 Re: 35s checksum problem - another testMessage #31 Posted by Miguel Toro on 11 Aug 2007, 12:38 a.m.,in response to message #21 by Paul Brogger 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.

 Re: 35s checksum problem - another testMessage #32 Posted by Miguel Toro on 10 Aug 2007, 3:30 p.m.,in response to message #19 by Gene Wright In my CNA 72102361: ```LBL Y LN = 338 CK = 3EA9``` Regards, Miguel Edited: 10 Aug 2007, 3:43 p.m.

 Re: 35s checksum problem - another testMessage #33 Posted by Seth Morabito on 10 Aug 2007, 5:44 p.m.,in response to message #19 by Gene Wright 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!

 Re: 35s checksum problemMessage #34 Posted by Mark W Paris on 13 Aug 2007, 11:57 p.m.,in response to message #18 by Paul Brogger 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...

 Re: 35s checksum problemMessage #35 Posted by Alain Mellan on 10 Aug 2007, 6:23 p.m.,in response to message #16 by Paul Brogger 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.

 Re: 35s checksum problemMessage #36 Posted by Paul Brogger on 10 Aug 2007, 6:41 p.m.,in response to message #35 by Alain Mellan 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.)

 Re: 35s checksum problemMessage #37 Posted by Miguel Toro on 10 Aug 2007, 6:46 p.m.,in response to message #1 by Lyuka Hi, I would like to know if someone has the same checksum as me, entering the TVM routine. CK=7940 Thanks, Miguel

 Re: 35s checksum problemMessage #38 Posted by Jeff O. on 11 Aug 2007, 11:17 a.m.,in response to message #37 by Miguel Toro I get CK=D073. Example results match yours exactly.

 Re: 35s checksum problem - TestMessage #39 Posted by Miguel Toro on 11 Aug 2007, 1:34 p.m.,in response to message #38 by Jeff O. ```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 ```

 Re: 35s checksum problem - TestMessage #40 Posted by Jeff O. on 11 Aug 2007, 7:06 p.m.,in response to message #39 by Miguel Toro The checksum of your program stubbornly remained D073 after each of the actions you requested. Do you have any other programs in your calculators?

 Re: 35s checksum problem - TestMessage #41 Posted by Miguel Toro on 11 Aug 2007, 8:32 p.m.,in response to message #40 by Jeff O. 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.

 Re: 35s checksum problemMessage #42 Posted by Mark W Paris on 13 Aug 2007, 11:59 p.m.,in response to message #37 by Miguel Toro Can someone repost the "TVM routine?" Thanks.

 Re: 35s checksum problemMessage #43 Posted by Jeff O. on 14 Aug 2007, 7:54 a.m.,in response to message #42 by Mark W Paris

Go back to the main exhibit hall