The Museum of HP Calculators

HP Forum Archive 16

[ Return to Index | Top of Index ]

Regular HP12C and HP10C: [1/x] bug?
Message #1 Posted by Vieira, L. C. (Brazil) on 9 Jan 2007, 6:01 a.m.

Hi, all;

last year, a 'keyboard lock' for the HP12C was mentioned by one visitor, and I felt compelled to investigate. Right after January 1st. I got such information from a friend of a friend... and it works! At least, it gave me the expected results.

In fact, it seems to be a bug in the [1/x] routine in both the regular HP12C and the HP10C. I tested with the HP11C and the HP15C and it did not happen. I did not test the HP16C, but it seemed meaningless, as you´ll see.

Exception made for the new breed HP12C Platinum and Prestige, all voyagers have the [ON]/[yx] reset ([ON]/[PMT] in the HP12C, [ON]/[D] in the HP16C), and some investigation from other contributors allowed us to know that, if I am not wrong, a nibble rotation in the x-register contents is actually what happens. So, after such [ON]/[PMT] reset ([ON]/[yx] in the HP10C), chances are that what you see in the display cannot be handled by the calculator internal routines as a valid number.

In both the HP10C and ´flat´ HP12C the resulting 'number' after this reset causes a sort of endless loop if the [1/x] key is pressed. Maybe the [1/x] routine in these models never reaches a return point with such arguments.

SO... if you want your HP12C (or HP10C) in a coma state for some minutes, try this:

KEEP IN MIND THAT YOUR CALCULATOR WILL NOT RESPOND TO KEYSTROKES FOR SOME MINUTES, MAYBE 10, AND THAT I TESTED THIS PROCEDURE IN, AT LEAST, FOUR HP12C AND ONE HP10C, BUT I CANNOT ENSURE THAT THE SAME BEHAVIOR AND/OR INTEGRITY WILL BE OBSERVED IN ALL UNITS!!!!

turn your calculator on;
press [1][ENTER];
simultaneously press [ON] [PMT] (HP12C);
you should see something like 0.00004;
press [1/x]

Your calculator will not respond to any keystroke for some time. I guess it waits for about 10 minutes, i.e., the auto shut-off time. I do not know if this 'coma period of time' is recycled if a key is pressed, all I know is that I had to leave them resting for some time prior to use them again. Not a 'keyboard lock' as stated before, instead a 'coma' state.

There it is... I was told that people used to do this here to avoid uninvited users to take control of their beloved calculators.

My 2¢.

Luiz (Brazil)

Edited: 9 Jan 2007, 7:32 a.m.

      
Re: Regular HP12C and HP10C: [1/x] bug?
Message #2 Posted by Valentin Albillo on 9 Jan 2007, 7:35 a.m.,
in response to message #1 by Vieira, L. C. (Brazil)

Hi, Luiz:

This is not a bug.

The definition of bug implies that the division routine is producing the wrong results or otherwise malfunctioning when applied to arguments within the range it was designed to cope with.

But the value you're passing it does not fall in that range but rather is simply what was called a NNN (Non Normalized Number) back in old PPC times.

Your NNN value is not essentially different from the ones first generated in the HP-67 by using a so-called "black-box" or else resorting to "bed bouncing", where you would try to achieve an extremely short false contact of the batteries to try and produce an NNN in the X-register, the stack, or some storage register.

The resulting NNNs where then used to display cuasi-alphanumeric messages in the HP-67, and would result in the same long times for division (also for logarithms) you're experiencing now and for the same cause. Much worse, attempting to print one of those NNN in the HP-97 could easily result in the thermal print head being left on and thus quickly burning itself out.

That was not a bug of the PRINT functionality, just that NNNs weren't supposed to be fed to most routines, and would cause unexpected behavior in most cases.

By the way, I don't have a calculator at hand right now, but you may want to check LN or LOG with your NNN, to see if it hangs the same way.

Best regards from V.

            
Re: Regular HP12C and HP10C: [1/x] bug?
Message #3 Posted by Vieira, L. C. (Brazil) on 9 Jan 2007, 7:55 a.m.,
in response to message #2 by Valentin Albillo

Hi, Valentin; thanks for your clarifying words. As always! 8^)

I remember reading about the NNN and the deadly consequences when trying to print them with the HP97 printing. Good reminding!

About the term ´bug´. I must confess I actually do not identify how (and when) to correctly use some terms, ´bug´ being one of them. I thought that error (miss)handling might be the case here, because with some NNN generated by [ON]/[yx], I saw

[ Error 2 ]
shown in the display of the HP11C after [1/x], and with others a zero (0.0000) was returned. As the [ON]/[PMT] is a regular keystroke sequence and the HP12C manual states that the display must be cleared with [CLx] after [ON]/[PMT] is performed, I thought that handling the generated NNN might be considered, and in the HP12C and HP10C, trying to use it causes a crash. But you surely pointed out something relevant here: going ahead trying to generate plausible numbers from a NNN as argument may cause all sorts of behaviors.

Thanks again.

Best regards.

Luiz (Brazil)

Edited: 9 Jan 2007, 7:57 a.m.

                  
Re: Regular HP12C and HP10C: [1/x] bug?
Message #4 Posted by Valentin Albillo on 9 Jan 2007, 8:38 a.m.,
in response to message #3 by Vieira, L. C. (Brazil)

Hi again, Luiz:

Thanks for your always kind words, a few comments:

    "[...] in the HP12C and HP10C, trying to use it causes a crash."

      Actually, I don't think it is a crash, in the sense that the machine is locked in an 'infinite loop'. I think it's probably doing more or less what the HP-67 did, i.e., trying to perform the division but, as an NNN was feed to it, the usually extremely fast subtract procedure is acting with such an small argument (non-normalized) that it simply takes ages to finally reach zero.

      You could easily check that in the HP-67 because the red LED display was on sometimes while the subtracting loop was performed and thus you could see the number getting smaller till it eventually finished several minutes later. In the Voyagers, it seems the LCD is not refreshed in real time but only when the operation finally concludes and that's why it seems to be locked, which probably it's not.

      I remember times of more than 20 minutes for some arguments in the HP-67, and still longer times indeed seem possible to me.

      By the way, did you test some NNN arguments of yours with LOG and/or LN, as I suggested ?

Best regards from V.

                        
Re: Regular HP12C and HP10C: [1/x] bug?
Message #5 Posted by Vieira, L. C. (Brazil) on 10 Jan 2007, 5:39 a.m.,
in response to message #4 by Valentin Albillo

Hi, Valentin;

[LN] in the HP12C causes the same behavior, as you predicted. Did not test [LOG] in the HP10C.

Best regards.

Luiz (Brazil)

      
Re: Regular HP12C and HP10C: [1/x] bug?
Message #6 Posted by Katie Wasserman on 9 Jan 2007, 10:57 a.m.,
in response to message #1 by Vieira, L. C. (Brazil)

Luiz,

You can take it out of this "coma state" by pressing the keys in the 4 corners at the same time -- ON, +, /, n (SQRT on the 10C) -- and holding for about 1 second. (Or you could pull out the batteries, I suppose.)

-Katie

            
That´s new! (was: Regular HP12C and HP10C: [1/x] bug?)
Message #7 Posted by Vieira, L. C. (Brazil) on 10 Jan 2007, 5:48 a.m.,
in response to message #6 by Katie Wasserman

Hi, Katie;

Is it a known key combination? I thought about pulling the batteries out (or even the famous brief short in their terminals) but I wanted to know if there was another possibility to 'bring it back', like this key combination you are mentioning.

Good to know, good information. Thanks!

Best regards.

Luiz (Brazil)

                  
Re: That´s new! (was: Regular HP12C and HP10C: [1/x] bug?)
Message #8 Posted by Katie Wasserman on 10 Jan 2007, 10:07 a.m.,
in response to message #7 by Vieira, L. C. (Brazil)

Luiz,

I just stumbled on it while playing around with your 'coma' find. I have no idea if anyone else came across this before. I also noticed that this same 4-corners key press works to instantly end the + or x self-test routine.

Another curious NNN I found is the 0.1 number that's not quite 0.1: Start the standard divide-key self-test and press the ENTER key to cause it to fail immediately with Error 9. Press ENTER again and you'll get 0.1 in X. This number works just like a real 0.1 in almost every aspect except if you take the reciprocal of it, the calculator thinks it's zero.

-Katie

                        
Re: That´s new! (was: Regular HP12C and HP10C: [1/x] bug?)
Message #9 Posted by Antonio Maschio (Italy) on 10 Jan 2007, 11:38 a.m.,
in response to message #8 by Katie Wasserman

KW wrote

Quote:
This number works just like a real 0.1 in almost every aspect except if you take the reciprocal of it, the calculator thinks it's zero.

-Katie

Well, curious. It works on my CN1300XXXX HP 12C made in China too, except that the reciprocal of this 0.1 is turned in to 0.00.

-- Antonio

Edited: 10 Jan 2007, 11:40 a.m.

                              
Re: That´s new! (was: Regular HP12C and HP10C: [1/x] bug?)
Message #10 Posted by Katie Wasserman on 10 Jan 2007, 6:13 p.m.,
in response to message #9 by Antonio Maschio (Italy)

Yes, sorry, that's what I meant to say -- it didn't quite come out right....

                              
Re: That´s new! (was: Regular HP12C and HP10C: [1/x] bug?)
Message #11 Posted by Ken Shaw on 16 Jan 2007, 12:12 p.m.,
in response to message #9 by Antonio Maschio (Italy)

Confirmed. Same result with HP-15C serial # 2301A02668

      
HP 15C NNNs?
Message #12 Posted by Warren Anderson on 9 Jan 2007, 11:08 a.m.,
in response to message #1 by Vieira, L. C. (Brazil)

My HP-15C 2241A04424 does exhibit bizarre inconsistent behavior when playing with [ON]-[XX] keystrokes.

In just a few minutes I have generated 0.000 40, some garbled segments, and just now a flashing "partial 2 _ _ _ _ _ _ 0 _ _ _ 0"

These NNNs remain in the stack when I roll it down. When the NNN is flashing, all numbers in the stack flash. They stopped when I turned off/on.

If I attempt an operation on one such as sqrtX I get Error 1. Turn off the calc, back on, the NNN is still displayed. Clear the error, still there.

I can store and recall the NNNs.

So far, no prolonged loops or unresponsiveness of the calc.

I wonder if anyone explored synthetic programming with the 15C? I'm not going there, simply curious.

            
Re: HP 15C NNNs?
Message #13 Posted by Valentin Albillo on 9 Jan 2007, 11:26 a.m.,
in response to message #12 by Warren Anderson

Hi, Warren:

Warren posted:

    "I wonder if anyone explored synthetic programming with the 15C?"

Best regards from V.
            
Re: HP 15C NNNs?
Message #14 Posted by Warren Anderson on 9 Jan 2007, 11:32 a.m.,
in response to message #12 by Warren Anderson

Oops, just read in the manual that the flashing display and "C" annunciator are the result of flags being set. But it might be interesting that [ON]-[xx] set some flags (arbitrarily?).

                  
Re: HP 15C NNNs?
Message #15 Posted by Valentin Albillo on 9 Jan 2007, 11:47 a.m.,
in response to message #14 by Warren Anderson

Hi again, Warren:

Warren posted:

    "But it might be interesting that [ON]-[xx] set some flags (arbitrarily?)"

      When you're dealing with NNNs most anything can happen as the results are usually undefined and thus unpredictable.

      However, the mere fact that the "C" annunciator does appear and/or the display starts blinking doesn't necessarily mean that flags 8 and 9 have been set, it might be a side effect of the display routines trying to display your Non-Normalized-Number, i.e., coping with information they weren't designed to cope with. Also, you'll see your NNN number differently sometimes if you look at it using the mantissa function (i.e.: f PREFIX).

      To see if that's the case, enter and run this small program after you've caused the "C" or the blinking to show up when dealing with some NNN (not as a result of entering complex mode, provoking overflow, or explicitly executing SF 8 or SF 9): 

          LBL A
    F? 8
      8
    F? 9
      9
    RTN
      If flag 8 and/or flag 9 are set you'll find "8" and/or "9" in the stack after running it, else your X register will be left unchanged. This should make clear if the flags are indeed set or not.

Best regards from V.
                  
Re: HP 15C NNNs?
Message #16 Posted by Eric Smith on 16 Jan 2007, 9:38 p.m.,
in response to message #14 by Warren Anderson

Using the ON-D operation results in modification of the internal processor state as well as the X register. On the 15C, this can result in an inconsistency between the stored user flag values (including flags 8 and 9) and the processor-internal flags that are involved in complex mode and display flashing.

If you get a 15C into such a state, I would highly recommend doing a full memory clear (ON-minus) before trying to use it for any important calculations.

The manuals for all of the Voyagers recommend clearing the X register after using ON-D, but in the case of the 15C they apparently overlooked the other effects on calculator state.

      
Re: Regular HP12C and HP10C: [1/x] bug?
Message #17 Posted by Howard Owen on 10 Jan 2007, 11:55 a.m.,
in response to message #1 by Vieira, L. C. (Brazil)

ON-Y^X on my 15C (SN 2522A35432) apparently results in a NNN near zero, since subsequently pressing 1/X results in a long sleep. Katie's four-corner reset works for me too.

Regards,
Howard

            
Re: Regular HP12C and HP10C: [1/x] bug?
Message #18 Posted by Ken Shaw on 16 Jan 2007, 12:23 p.m.,
in response to message #17 by Howard Owen

(1) 4 corner key combo terminates self-test as described. (2) [ON]-[Y^X] combo sets the complex flag, but nothing else unusual. 1/x generates Error 0 as expected.

HP15C serial 2301A02668

[ Return to Index | Top of Index ]

Go back to the main exhibit hall