16C internal floating point format?

[billf]

Hi all,

I'm in the middle of writing a clean-room 16C simulator, as a hobby project. I don't have a real 16C (but my 15C is still working great!), and I don't want to anything like look at ROM images, or run out and buy a calculator. But I do have a question as to the behavior of a real 16C as regards the binary representation of floating point numbers. I'm guessing it's BCD mantissa and exponent, with one nybble for the mantissa's sign and one for the exponent's - that fits nicely in 56 bits - but I don't know which digit goes where, and there are a few edge cases besides.

So, if someone has access to a real calculator, could you do me a favor and let me know what you get in (56 bit) hex when you store the following numbers into registers? 0.0 42.0 -42.0 1e42 1e-42 0.0001e-99 9.999999999e99, and finally, the results of (99 <ent> 9e99 *), (-99 <ent> 9e99 *) and (0 1/x). I think that covers all the bases.

Thanks!

In return, I'll be happy to give you a free copy, when/if I have it working well. That's not much of a prize, though, since I plan to give it away, and put up the source on github.

BTW, I'm writing it in Flutter, which will make it easy to deploy most everywhere. For reference, I made an Android and desktop Java version of Emmet-Gray's WRPN (after asking him if he was OK with it); my version cleans up the appearance on high-res screens by using rendered fonts (see jrpn.jovial.com). I was looking for a project to keep myself out of trouble for, oh, about another month of stay-at-home, and making a higher fidelity simulation is a good fit, so I'm writing one from scratch.

Cheers,

Bill

[ThomasF]

(04-03-2021 08:48 PM)billf Wrote:  So, if someone has access to a real calculator, could you do me a favor and let me know what you get in (56 bit) hex when you store the following numbers into registers? 0.0 42.0 -42.0 1e42 1e-42 0.0001e-99 9.999999999e99, and finally, the results of (99 <ent> 9e99 *), (-99 <ent> 9e99 *) and (0 1/x). I think that covers all the bases.

Thanks!

Hi Bill,

This is what I get:

0.0 --> 0h
42.0 --> 04200000000001h
-42.0 --> 94200000000001h
1e42 --> 1000000000042h
1e-42 --> 1000000000958h
0.0001e-99 --> not possible to enter
9.999999999e99 --> 09999999999099h
(99 <ent> 9e99 *) --> 09999999999099h
(-99 <ent> 9e99 *) --> 99999999999099h
(0 1/x) --> Just gives "Error 0"

Note that 99 <ent> 9e99 gives overflow - i.e. it becomes 9.999999999e99
I also used 64 bit wordsize when in hex-mode (FLOAT 8 - <enter number> STO - hex 0 WSIZE RCL), since I expect that registers are in 64 bits length (to be able to store a 64 bit integer), correct me if I am wrong.

Edit: was partly wrong. Used the I-register which is always full size!

Hope this helps you!

Cheers,
Thomas

[billf]

Perfect, thanks Thomas! Exactly what I needed. Little-endian BCD, which is slightly surprising (to me), but sensible.

One other semi-related question: For overflow, is it a flashing "9.999999 99" (like the 15C does), or does it set the G flag, or neither?

[Joe Horn]

(04-04-2021 12:21 AM)billf Wrote:  One other semi-related question: For overflow, is it a flashing "9.999999 99" (like the 15C does), or does it set the G flag, or neither?

The 9.999999 99 doesn't flash (it just displays steadily, like a normal result), and the G annunciator lights up (AKA flag 5 is set).

[billf]

Great! That's a little easier to implement :-) Thanks again.

[KF6GPE]

As the Google TPM responsible for the team contributing to Flutter there, thanks for choosing to do it in Flutter!

Let me know if you have questions for the team, and I'll see if I can get input from one of the devs I work with.

Looking forward to seeing the simulator! I'd be a happy beta tester or user, for sure.

[billf]

BTW, slight correction - I meant big-endian. The internal format is rather delightful - if anyone's curious, here's my description:

Code:

///
/// Stored in what I think is the 16C's internal format
///
/// This format is interesting.  It's big-endian BCD.  The mantissa is
/// sign-magnitude, with the sign in a nybble that is 0 for positive, and
/// 9 for negative.  The exponent is 1000's complement BCD, with a magnitude
/// between 0 and 99 (inclusive).  So it looks like:
///
///      smmmmmmmmmmeee
///
/// s = mantissa sign (0/9)
/// m = mantissa magnitude
/// e = exponent (1 is 001, -1 is 0x999, -2 is 0x998, etc)
///
/// The most significant digit of the mantissa is always non-zero.  In other words,
/// 0.1e-99 underflows to zero.  The mantissa is NOT stored in complement form.  So, a
/// mantissa of -4.2 is 0x94200000000.
///
/// Note that I didn't refer to a ROM image to figure this out, or anything
/// like that.  I just asked what the behavior of the real calculator is
/// for a couple of data points.
/// cf. https://www.hpmuseum.org/forum/thread-16595-post-145554.html#pid145554
///

[ThomasF]

Yes, that seems to follow the way HP implemented the representation of floating points in most (if not all) of its 56-bit CPUs.

See e.g. the following thread for some more information:
https://www.hpmuseum.org/cgi-sys/cgiwrap...read=90949

Cheers,
Thomas

[billf]

Hi Thomas and/or all,

One other behavior question: What happens when you try to enter the following program?

G SF 9

How about

G SF A

My theory is that they behave differently: I think the calculator will let you enter SF-9 as a program instruction, BUT executing that program instruction is guaranteed to generate an "Error 1". On the other hand, I'm betting it won't let you enter SF-A at all. Is my guess accurate?

What I see is that the back of the calculator (according to an image I have) says that "Error 1" can mean "F > 5," so it must let you input invalid flag numbers. However if I set the max at F (15), I get too many opcodes -- when I limit it to 9, I get 255 opcodes, which makes total sense. This even means 0 is left over as NOP, which maybe they use internally when running off the end of a program, since it looks like the number of program lines is stored internally divided by 7.

It's a little weird that they allow entry of invalid flag numbers in program opcodes, but maybe that aligns the instruction set of the 16C with the 15C or something.

This really was a superbly engineered calculator.

[ThomasF]

Hi Bill,

Entering any of those lines generates "Error 1", both in Run and in Prgm mode. Any flag above 5 generates "Error 1".

On the 15C I know that someone found a way to enter "synthetic" instructions to be able to enter new "opcodes", but to my knowledge this has not been done on the 16C.

Cheers,
Thomas

[billf]

Hi Thomas, and anyone else interested,

I have a first alpha up on the web! Let me know what you think:

https://new.jrpn.jovial.com/

There's a link under Help to submit any issues you run into. On the issues page, you'll see a few mostly cosmetic "to do" items (like making a portrait layout). I haven't put up a build for other platforms, just because that takes work for not much value... Of course the real thing will have native builds for All The Platforms.

I'll post an announcement outside this thread in a few days if all goes well.

Cheers,

Bill

[KF6GPE]

Nice work!! I like it.

I'm going to flash this in front of the team this week --- they'll be glad to see a good hobbyist project like this in Flutter, and I think the notion of reproducing a programmable calculator with Flutter will be one several of them find rewarding.

[KimH]

Very cool! Have a 16C but now I also have a bookmarked one, thanks for that!