HP10C 'Bug' ..?



#22

I've just spent a few minutes trying to figure out why a simple PRANG wasn't working on my HP10C. (I needed a set of 'random' values). Usually I would enter the whole program as follows:

01-     48 ' .
02- 5 ' 5
03- 2 ' 2
04- 8 ' 8
05- 4 ' 4
06- 1 ' 1
07- 6 ' 6
08- 3 ' 3
09- 31 ' R/S
10- 9 ' 9
11- 9 ' 9
12- 7 ' 7
13- 20 ' *
14- 42 35 ' f FRAC
15- 22 09 ' GTO 09
(To get a more random set I usually substitute R/S with ENTER and run the program for a while first...)

To save time on this occasion I just entered the 'seed' value by hand and used the following code instead:

01-      9 ' 9
02- 9 ' 9
03- 7 ' 7
04- 20 ' *
05- 42 35 ' f FRAC
06- 22 00 ' GTO 00
I keyed in the program, switched to RUN, pressed f Clear PRGM + f Clear REG to reset everything, entered my seed, and pressed SST to single step the code to make sure every thing worked ... was surprised to find that the digits '997' were appended to the seed value already in X which is not what I expected - the first SST had not enabled stack lift!

I compared this behaviour with that of my HP34C and found that the HP34C did enable stack lift as expected...

I'm not sure if this is a bug but it didn't look right to me. Anyway I thought it might interest someone here - incidentally does anyone know how an HP33E/C behaves in the same situation? (Mine broke 12+ years ago so I can't check but I think it behaved the same way as the HP34C).

Mike T.

#23

Hi, Mike;

the owner's manual for all Voyagers state that [SST] is a neutral operation, and it does not actually terminate digit entry IF the program step executed with [SST] has a digit-entry key code ([o] to [9], [.], [EEX] and [CHS]). If you press [R/S] to start running a program, [R/S] itself terminates digit entry, while [SST] does not.

I have the HP10C Owner's Handbook, July 1982, Rev. B. The neutral operations are listed at page 101.

It is not a bug...

Cheers.

Luiz (Brazil)

Edited: 27 Feb 2005, 8:16 p.m.


#24

I think (non verified) that this behaviour changed when the "backspace" key appeared in the HP 41C and from then on. As the Voyagers and Pioneers have a "backspace" key, I would not expect them to behave as Classics, Woodstocks or Spices with regard to digit entry termination.


#25

Hola, Andrés; como estás?

Have you ever observed the HP25/25C? If I am not wrong, it works the same. All of the program examples for the HP25 that expect a number entry immediately followed by another number already stored in the program have an initial ENTER. It took me some time to verify that that ENTER was necessary for a Single STep execution and had no effect for a straight execution with [R/S].

I guess that the fact of newer calculators (HP41, 42, 32S and ahead) use a single step to store a whole number in programs instead of a discrete sequence of keystrokes is the key difference. All Voyagers kept the discrete number entry in programs.

Cheers.

Luiz (Brazil)

Edited: 28 Feb 2005, 8:52 a.m.


#26

What I found interesting was that earlier models, HP34C (and HP11C) did behave as I expected, it was just the HP10C that was different - all the more intriguing as wording used to describe the neutrality of the SST operation is identical in all three calculators manuals!

Does any one know how the HP33C/E behaves under the same conditions - I don't remember it being 'odd' but is was a long time since mine worked...

Mike T.

#27

Have you ever observed the HP25/25C? If I am not wrong, it works the same. All of the program examples for the HP25 that expect a number entry immediately followed by another number already stored in the program have an initial ENTER. It took me some time to verify that that ENTER was necessary for a Single STep execution and had no effect for a straight execution with [R/S].

R/S behaves no differently than SST on the HP-25: if a program starts with a number, and you enter a number and then press R/S, the number in the program gets appended to what you just entered.


IIRC, the big change came with the HP-41C, which treats a number as a single program line. I don't think it has anything to do with the backspace key -- but I'm sure someone will prove me wrong. :-)

- Thomas


#28

I don't think it has to do with the "backspace" (<-) key by itself [I mean the arrow key used to correct digit entry mistakes, not the "backstep" (BST) function], but I think that HP had to redesign the digit entry code to allow for the (<-) to work; and that may relate to such behavior differences between models. IIRC, there was a "digit entry flag". I understand that things may be different at a program run beginning, so my ideas may prove wrong indeed.


#29

Hi Andrés, all;

I checked my HP55 and digit entry works the same for [SST]. If you are entering a number and there's a program positioned in a step with any digit-entry code ([0] to [9], [.], [EEX] or [CHS]) and this step is executed through [SST], the resulting action is added to the number in the display, either new digits or change signal or enter exponent. And the HP55 has no backspace feature.

I understand what you mean about redesigning digit entry to allow backspace, because prior to the HP41 there was only [CLx] available. I agree with Vassilis, I also think that the main reason is the need to not to finish digit entry through program steps while pressing [SST] in calculators where whole numbers must be "spread" through program steps. The HP41, HP42S, HP32SII and HP33S (others?) store one number in one single program step, as Vassilis mentions, so digit entry is resumed after that step is executed, and there's no way to add extra digits.

Just to add that.

Cheers.

Luzi (Brazil)

#30

If I understand it correctly you imply that SST should enable stack lift?

SST does not enable stack lift on ALL models that have unmerged numbers in programs. This is because SST does not (cannot) know if you are in the middle of a number sequence.

Look at the program in your posting. Assuming that you entered the seed followed by ENTER and pressed SST on line 000, you get 9 on the display. Then you press SST again.

What do you expect to happen? If the calculator enables stack lift when you press SST then you will never be able to single step through a program with numbers in it.

However, since SST does NOT enable stack lift, you get 99 on the diplay.

On the HP-41 and models that have merged numeric instructions, the entire number is on a single instruction, so having two numbers on subsequent instructions implies an ENTER between them. This is why the behavior of SST on the HP-41 is slighlty different.


Regarding the behavior of R/S I am not sure which behavior is better, although enabling stack lift appears to be the usual behavior (HP-67/97, HP-34C, HP-19C).

**vp


#31

It seemed intuitive to me that the first time I pressed SST the stack should lift and when on the HP10C it didn't I wondered why.

What I find very interesting is that the general consensus seems to be that the HP10C is behaves perfectly normally which still leaves me wondering why the HP11C and HP34C behave differently as on these models the first SST (and only the first SST) does enable stack lift - obviously subsequent SSTs do not.


#32

Mike T. wrote:
> ... the HP11C and HP34C behave differently as on these
> models the first SST (and only the first SST) does enable
> stack lift

not on my HP-34C

I do not have an HP-11C to test though

**vp

#33

Hi, Mike;

Quote:
the first SST (and only the first SST) does enable stack lift
Yeap! This is a fact when program memory is positioned on step 000. Otherwise, if you press [SST] in the HP11C (or HP34C) while you are entering a number and current program step is not 000 and it contains a number-entry code, this 'action' is added to the number in the display. I tested it in my HP11C right now.

Cheers.

Luiz (Brazil)

Edited: 2 Mar 2005, 1:51 a.m.


#34

I can confirm that the same thing happens on my HP34C (SN:2126S32231), after trying the following tests -

[f] [Clear PRGM] .05284163 [SST] displays 9 (as I expected)

[f] [Clear PRGM] [GTO .001] .05284163 [SST] displays .052841639

Repeating these tests on my HP10C (SN:2235A07777) displays .052841639 in both cases, which is what started this whole thread in the first place - neither have backspace but as the HP10C came out last in the voyager series I wonder if something was lost, possibly deliberately, when the digit entry code was reworked to remove the code to handle backspace from the HP10Cs firmware, and if so was it ever changed...?

Hopefully I will be able to check how this works on an HP12C some time in the next couple of weeks.


PS. Luiz - Thanks for spotting the obvious for me, I've tried e-mailing you a couple of times but without success - I've almost finished something that might interest you.


Mike T.


#35

Oops, I have a program already in my 34C (I actually do
use it from time to time after all :-) so I just SSTed down till I found some numeric sequence and did my tests there.

It didn't occur to me that a number placed in location 000 would (or event that it should) behave differently.

My trusted HP-97 does not have this behaviour, i.e. RTN 123 SST SST will produce 12345 (with 001 4 and 002 5). On the other hand 123 RTN R/S produces 45. Different behavior but predictable.

Is the HP34C's behaviour documented ANYWHERE? If it is then its a feature, if not, its a bug.

**vp


#36

On the other hand 123 RTN R/S produces 45.

Did you mean to write RTN 123 R/S? Because the way you wrote it, it couldn't possibly return 12345 (I'm pretty sure RTN terminates number entry).

I should try this on my HP-67... Time to finally hook up some batteries (I bought that thing on eBay months ago but have been too busy to even try it yet!)


#37

Thomas Okken wrote:
> Did you mean to write RTN 123 R/S?

yes, I do not know what I was thinking. The result though is the same in both cases (i.e. both R/S and RTN terminate number entry).

**vp

#38

More tests

The behavior Mike wrote about (i.e. SST at line 000 causes stack lift) works only on my HP-34C

On my HP-33C and my HP-38C SST at line 000 does not cause stack lift. Strange!

For the record, my HP-67/97 and my HP-19C also behave like the HP-33C

I guess somebody thought it was a good idea at around the 34C timeframe and added this "feature". Strange though that the HP-38C (which also came out at the same time as the 34C does not have the same "feature").

**vp


#39

The 38C came out at the same time as the 34C, but I don't think they changed the firmware from the 38E -- just added continuous memory.

#40

Vassilis,

Thanks for trying this out on the HP33C, I didn't remember noticing this before but it has been a long long time since I used an HP33C or HP97 (like 18 years too long!).

Are you able to repeat this test on an HP11C? The results I got indicated that the HP11C behaved that in the same way as the HP34C.

Mike T.


#41

I now have an HP12C (SN#3451S04459), and the first thing I I tried were the tests I described above...

I obtained the same results as with my HP10C - so I rather think that the correct subject title for this thread should have been as Vassilis suggested 'HP34C feature!'.

It is strange how quickly we accept the familiar as normal behaviour. Despite the fact that the HP34C behaves differently the HP33C, after getting used to the HP34C I found it difficult to believe that my HP33C had ever been any different.

Mike T.

PS. Luiz - Did you get my email.?

#42

... was off-line for some hours, maybe all night. If you want to give it another try:

lcvieira at quantica dot com dot br

Thanks!


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP10C series battery door compatibility? Bruce Larrabee 6 451 08-11-2013, 05:42 AM
Last Post: Bruce Larrabee
  Nonpareil + HP10C Mike (Stgt) 0 154 05-13-2013, 04:58 AM
Last Post: Mike (Stgt)
  HP10C enulation PeterP 5 343 10-25-2010, 06:40 PM
Last Post: PeterP
  Regular HP12C and HP10C: [1/x] bug? Vieira, Luiz C. (Brazil) 17 806 01-16-2007, 12:23 PM
Last Post: Ken Shaw
  NEW HP10C & HP15C !!! john smith 5 288 05-06-2003, 08:10 PM
Last Post: Les Bell [Sydney]
  HP10C Thibaut.be 12 545 05-09-2001, 12:43 PM
Last Post: stefan

Forum Jump: