HP Forums

Since posting my photo gallery and noting the unreliable nature of R/S (and ON/C) when interrupting a loop, I have had a few interesting things happen.

I was programming the 35s and testing some routines and goto-ing between differing labels when suddenly the calculator froze with only the "RPN" and "PRGM" annunciators lit - I had just done an XEQ label to start running my test program. No amount of R/S, ON/C or ON/C-GTO keypresses would make it responsive again. I looked in the manual for further keystrokes but it was basically locked up. Nothing I could do would bring it back to life. After leaving it for 10 minutes and trying again in vain to reset it from the keyboard, a paperclip reset finally rebooted it, but also cleared memory. Not 100% sure if it was supposed to clear memory but it did.

After that incident, I was doing some looping speed tests to compare it to some other HP calculators and suddenly noted that the R/S and ON/C *did* work reliably now after the reboot/reset. No more flaky behavior - every push of the R/S key or ON/C would instantly interrupt the program, just as it had on all my previous HP's. Suddenly, totally different behavior from before! Very interesting...

Then, a little later, I was trying to mess around with vectors and for the life of me, could not get the 35s to accept vector input (the first time I had tried). If I typed, for example, [12,35] and pressed ENTER, the calc would come back with SYNTAX ERROR with the curser placed on the 3 after the comma. Didn't matter what display mode, angle mode anything... it would never accept any sort of vector I tried to input. If I recall (not 100% sure), it maybe would accept a single element vector, but for sure never 2 or 3 element vectors.

I then tried to enter a vector ([12,35] for example) as an equation. The editor happily accepted the vector but then gave the same syntax error when I pressed ENTER to evaluate the equation. I also tried [REGY,REGX] as an equation, to build a vector from the stack, but got the same SYNTAX ERROR.

In frustration, I then wrote a quick program which would generate a vector (just [12,35]) and, lo and behold, that worked and placed the desired vector in the X register! Without really looking further at the manual, I thought maybe vectors could only be used in programs (silly, I know) and wrote a trivial program to generate a vector from the X and Y registers - basically just the same [REGY,REGX] equation I had tried in the equation list before. This worked so I happily played with vectors for a few minutes and then tried keying one in directly again. This time it worked!!!

So from that point onward, the calculator has always accepted vector entry as it should, both directly keyed and in the equation list. Very strange. Almost as though something was corrupted in the calculators OS, both initially after installing the batteries for the first time and then again after a reset. Somehow running the vector equation program "fixed" the glitch and it has behaved as expected since then.

Since the calculator was so flaky right after installing the batteries (weird R/S and ON/C behavior) and then giving me the hard crash, it might be wise for any new user installing the batteries for the first time, to do a paper-clip reset immediately before something glitches and causes a loss of calculator memory. Obviously I can't really be sure if an initial reset would have helped in my case...

Just thought you all would be interested in hearing about this.

Regards,
Mike Mander

Let's hope this flaky behaviour was only a side effect...

Do the R/S and ON/C keys still work as expected?

Any difference regarding the other bugs, like checksum?

I haven't done testing of the 35s that intensive as you,

since I still don't like the programming model;-)

However I did some calculations by hand,

and surprisingly had not a single missed key stroke so far!

This is totally different to my 33s,

which has a very unreliable and bouncing keyboard.

No wonder, the orthodox HP RPN addics would say,

since the 33s doesn't have a keyboard, and no ENTER bar...

Regards

Raymond

Yes, since the hard reset, the R/S and ON/C keys have worked as expected. I have not looked at the whole checksum issue. Some very long threads I have to digest first and then key in some programs I suppose.

It does have the COS bug (angles close to 90 degrees) but have not really looked for any others.

I did some looping speed tests and "NOP" speed tests. Takes a little getting used to the programming model and although gotos get renumbered as one adds and deletes lines, if one deletes a line that is a target of a goto, things get messed up as noted elsewhere. I tested a few commands that might be used as a "NOP" target for a goto. I believe using DEG was suggested somewhere but that might be problematic if a program uses trigs. I tried using the "RADIX." command (LS DISPLAY 5) as a NOP, and it seems benign as it will never cause any unexpected program behavior like DEG could. Of course if you are in a different part of the world and use "RADIX,"... then use that as a NOP!

Speed tests:

A001 LBL A

A002 RCL+ C

A003 GTO A002

A001 LBL A

A002 RADIX.

A003 RCL+ C

A004 GTO A002

Simple loop-speed counting comparisons (1 minute execution):

------------------

A001 LBL A

A002 RCL+ C

A003 GTO A002

------------------

B001 LBL B

B002 RCL C

B003 +

B004 GTO B002

------------------

C001 LBL C

C002 1

C003 +

C004 GTO C002

Very interesting speed differences. On LBL B and C, the old 32SII trounces the 35s, let alone the 33s which just annihilates it on all tests!

Yep, excellent keyboard and all, a slightly faster 35s would have been kind of nice...

Regards,
Mike Mander

I just searched some older 35s postings in the archives and came across a mention of the vector bug and Katie's suggestion at using RADIX. as a NOP. I was trying to think of a way to use a non-destructive programmable operation as a NOP and came up with RADIX... but maybe I only thought of it subconsciously because I had read the earlier posts at some point? In any case, I have not been able to come up with a better NOP suggestion...

I didn't bother benchmarking the DISPLAY 7 and 8 functions (1,000 and 1000) for NOP use, since their appearance in a program listing can be very deceiving. In fact the DISPLAY 8 function (1000) looks exactly like the number 1000 in a program listing!

In any case, next time I'll have to search some older postings before bothering to repeat information. Sorry...

Regards, Mike Mander

Mike,

I've had the same vector entry syntax bug several times on my 35S. It seems to happen after a Memory Full error message but I haven't been able to pin down the circumstances. In any event, clearing the memory array seems to fix it.

The major program speed issue with the 35s compared with the 32sII is that constants cause the 35s to go into its line parsing routine -- which is very slow. Avoid all constants inside loops and it's reasonably fast.

The 35s doesn't parse any program line that starts with a number or a vector until run time. So you can type many-dimensional vectors and crazy looking numbers into programs without syntax errors. I don't see much use for this and the cost is having to invoke the line parser at run time. This seems to have been a bad engineering decision like many HP made on this calculator.

Katie,

Thanks. Yes many bad design decisions. I had read about the base-conversion entry quirk and didn't think it would be too bad. But what a pain actually! Can't believe the 35s forces you to append an 'h' to a number entered when you are in HEX mode, for example. Sheesh. It should assume any number entered is already in the current base mode unless specified otherwise. Luckily I don't use non-DEC bases too often.

I guess the only advantage in have the line-parser invoked at runtime is maybe, just maybe, someone will stumble across something that might glitch the 35s and allow some form of synthetic programming - probably very unlikely though!

I'm kind of glad I was able to get out of the vector entry bug without clearing memory as I would have been rather upset at that - twice in a day would have been too frustrating! If it happens again, I'll see if my trick of putting a vector in a program helps again. I presume you must have tried that too though, so I was probably just lucky...

Mike

Hi,

Yesterday I tested the java RPN programmable calculator - software "Calc" in my K610i phone.

Running the programm:

> LBL1
> 1
> +
> GTO1

Loop-count for 60 sg execution = 693938 loops (480x faster that 35s) :-(

Why is Hp35s so slow????. We are in XXI century (I ask it myself)

Best regards

Yeah, we all (painfully) know. ;-)

There was a posting a couple weeks back that talked about the slow CPU and compared the HP-35s to other calcs. I think it was in relation to Casio, but you might search for "timing", "speed" or "casio" and see what you can find. There was a very interesting link to a site that has timing numbers for every calculator imaginable. It was good reading.

thanks,
bruce

Hi,

> Loop-count for 60 sg execution = 693938 loops (480x faster that 35s) :-(

>

Yes, but then you should consider how often

you have to recharge the batteries of your phone;-)

HTH

Raymond

Hi

You are right Raymond.

I really do not need to execute the programs quite often.

And when I use them, I prefer that they are quick. Its consumption of battery is not a problem for me.

Jose