HP16C behavior on overflow when entering numbers?

[billf]

Hi all,

I have a question about numeric entry on an HP16C, for an enhancement to my 16C simulator (https://jrpn.jovial.com/). Could someone with an actual 16C try out these examples for me, please? The enhancement is described at https://github.com/zathras/jrpn/issues/53

My guess is that behavior in 8 bit decimal signed 2's complement mode when pressing digits without pressing enter would be:
255777777 gives -1
254777777 gives -2
256777777 gives 25
256477777 gives -2 (the 6 is ignored, but the 4 isn't)

and in 10 bit decimal signed 2's complement mode:
5127777777 gives -512
1023777777 gives gives -1
1024777777 gives 102
1024177777 gives -3

Right now, my simulator isn't stopping before overflow, so e.g. pressing the 7 key continues to change the display - not altogether unreasonable, but it seems that's not what the real 16C does. My simulator is cleanroom, and I don't own a 16C, so the example on page 37 of the owner's handbook was all the specification I had. It doesn't say what happens if you overflow, rather than just having bits propagate into the sign bit.

So: Now my theory is that, during digit entry, it's OK if bits propagate to the sign bit, but keystrokes that result in actual overflow are ignored. I think my four examples above are sufficient to tell me if this is right!

Cheers,

Bill

[mfleming]

Confirmed on my 16C (2251A) though the keys can sometimes not register. g-Clx between entries.

Edit: no overflow flag.

[billf]

(07-29-2023 02:37 AM)mfleming Wrote:  Confirmed on my 16C (2251A) though the keys can sometimes not register. g-Clx between entries.

Edit: no overflow flag.

Wonderful, thanks! And thanks for checking the overflow flag behavior; I hadn't thought of checking that.

Cheers,

Bill

[billf]

(07-29-2023 02:37 AM)mfleming Wrote:  Confirmed on my 16C

Hi again,

Another question, if you don't mind. How does BSP behave in these cases? I think two tests would be sufficient here... In 8 bit 2's complement signed integer mode:

CLX 2 5 5 (display reads -1) BSP (what happens?)
CLX 1 2 0 7 (display reads 127) BSP (I'm guessing 12?)

I can think of two reasonable outcomes for 255: a) Display reads "1" (as if you had pressed 1 CHS), or b) display reads 0, that is, BSP becomes like CLX when the displayed value is modified from the keystrokes.

Right now, my simulator does a), but I have a sneaking suspicion that b) might be what the real calculator does. b) requires a flag indicating an unsigned->signed conversion, but that flag is needed anyway to get the other observed behaviors.

[Sylvain Cote]

HP-16C S/N: 2332A05061

(07-30-2023 02:19 AM)billf Wrote:  In 8 bit 2's complement signed integer mode:

Code:

DEC
8 
WSIZE 
2'S COMPL

(07-30-2023 02:19 AM)billf Wrote:  CLX 2 5 5 (display reads -1) BSP (what happens?)

Code:

CLX     //    0 d
2       //    2 d
5       //   25 d
5       // -001 d
BSP     //   25 d

(07-30-2023 02:19 AM)billf Wrote:  CLX 1 2 0 7 (display reads 127) BSP (I'm guessing 12?)

Code:

CLX     //    0 d
1       //    1 d
2       //   12 d
0       //  120 d
7       //  120 d
BSP     //   12 d

[billf]

Interesting, thanks! Not what I was guessing at all, but I think I see what it's doing.

One more test, if someone would be so kind. I messed up the "1207" example. Here's what I meant to check: 8 bit unsigned decimal mode, and press

CLX 258 (display reads 25, I think) 4 (I'm expecting 254) BSP (I'm expecting 25) BSP (expecting 2). That is to say, the 8 keypress is completely ignored.

My theory on signed entry: It's got the flag for "converted from unsigned", and on BSP, if the flag is set, it converts *back* to unsigned and takes off the least significant digit.

[ThomasF]

Yes, can confirm that.
HP16C (serial 2641A)

Code:

DEC
8
WSIZE
UNSGN
CLx       0 d
258       25 d
4         254 d
BSP       25 d
BSP       2 d

Cheers,
Thomas