The Museum of HP Calculators

HP Forum Archive 19

[ Return to Index | Top of Index ]

Another RPN calculator program for the Casio FX-9860!
Message #1 Posted by Nigel J Dowrick on 16 Mar 2009, 11:15 a.m.

Here's another RPN scientific calculator for the Casio FX-9860G Slim (and related models). It's much simpler than Reckon (announced on this forum a few weeks ago); there's no graphing, no matrices and no high-precision arithmetic. The calculator has a twelve-level stack, with the lowest six levels displayed on the screen. All of its functions accept complex arguments.

The executable file, the source, and the documentation are all available for you to download freely from here:

(The image file in this directory contains a screenshot.) This is the first program that I have written in C ; if you do look at the source code, don't judge me too harshly!

I have become very impressed with the FX-9860G Slim during the writing of this program. I have always liked the hardware; seeing my unoptimised code running on it has made me appreciate how fast this calculator really is. I am also impressed that Casio has provided such a helpful and powerful SDK.

Re: Another RPN calculator program for the Casio FX-9860!
Message #2 Posted by hugh steers on 16 Mar 2009, 2:30 p.m.,
in response to message #1 by Nigel J Dowrick

I like it!

Another great RPN calculator for the fx-9860g. You have the same motivation, i liked the physical calculator but wanted my own style of operation.

Also, I like your "tagged" value idea. I've always thought modes trip you up and instead, maybe the type of value should go with it rather than be subject to a pre-assumed mode. It's an idea im currently experimenting with. I'll probably end up with modes as well because different people see things differently.

Your formatting to 6 digits is nice for the display. i have the same problem, i just spit out the value to 16 digits which looks ok for real numbers, but rather messy for complex ones. neither is perfect i agree. I can understand you having the same problem with output formatting, because it needs to be tackled in conjunction with the general cases of fix, sci, eng and also complex and angular forms. An area i have to fix too.

the menu system works nicely and this is an improvement over Reckon. Im trying to resist putting in a menu system mainly because it starts to bind the implementation to this calculator. i always have in the back of my mind the idea of porting to different platforms. nevertheless, some customisation is important. eg the use of custom characters.

Actually, i spent some time investigating my own scalable font rendering on the calculator. scaling fonts in 128x64 mono is not fun. I have a demo if anyone wants to see it, but the appearance is never quite as good as the hand-drawn built-in versions. nevertheless, im thinking of using it a bit on the graph screen. The other idea was to try to draw formulae on the main screen using scaling fonts to draw fractions, superscript and subscript nicely.

I agree the SDK is very good. through use of it, im no longer convinced the output code is unoptimised, although i wouldn't like to claim it's totally optimised either. whilst debugging, it's clear the compiler has already eliminated any dead code, inlined functions and removed anything bogus. This is good news as i think if it were totally unoptimised it would have generated a lot more code.

Also thanks for giving out the code and writing the excellent manual!

Re: Another RPN calculator program for the Casio FX-9860!
Message #3 Posted by Nigel J Dowrick on 17 Mar 2009, 3:47 p.m.,
in response to message #2 by hugh steers

Thank you for your kind words - particularly nice since they come from someone whose knowledge of calculators I have long admired! I never had any idea of porting my program to another machine (running my RPN calculator on the HP-50g would be pointless, although having Reckon there would be great!) so I didn't hesitate to implement menus.

The low-resolution display on the Casio is a problem, but I suppose that the 1k of video RAM it implies is part of the machine's charm and one reason for its speed. The limit is only really a problem for complex numbers, when I want both parts displayed on one line. If complex numbers are only used occasionally, then displaying them with the built-in minifonts might be bearable. I hadn't previously realised how complicated display formatting can be!

I like the angle tags in use too, but behind the scenes the code that currently supports them is ridiculously complicated. I suspect that this is due more to messy programming than anything else - I must review the code.

Anyway, thank you again for your comments. Writing my own calculator has certainly given me a lot to think about - I suspect it might become addictive! I think you'd probably agree.

Re: Another RPN calculator program for the Casio FX-9860!
Message #4 Posted by hugh steers on 18 Mar 2009, 2:47 p.m.,
in response to message #3 by Nigel J Dowrick

One of the good bits about writing your own calculator is, once it has reached the actually working stage, it's fairly easy to add stuff. I'm planning to add stuff that i find useful. On another calculator, this would have to be a program.

You are right about the display formatting. the C/C++ language does not have a lot of fine control over display of numbers. I have another such problem with matrices. Currently, Reckon formats each number as 6 figures when inside a matrix in the vague hope that it will fit on the screen - mostly not. To do this properly really requires a matrix "viewer" which can scroll. Also how do you peek at one entry to full precision. These things are significant work if done properly.

For complex number display, what i did on the uWatch ( which has a 16 character screen is convert the real part and iparts to strings, then build the display string and see if it is too big. If so, i reduce the ipart a bit otherwise i reduce the real part a bit and try again. Furthermore, i try to trim away any unecessary chars in the numbers (leading zeros etc.). The whole thing is messy, but i was happy that it managed to get the most on the screen most of the time.

code snippets:

// tidy as many unnecessary chars as possible from a sci number
static void tidyNumber(char* p)
    if (*p == '-') ++p; // skip sign
    if (*p == '0' && p[1] == '.')
        strcpy(p, p+1);

p = strchr(p, 'e'); // exponent? if (p) { ++p; if (*p == '+') strcpy(p, p+1);

if (*p == '-') ++p; // '-' allowed

if (*p == '0') // leading zero in exponent strcpy(p, p+1); } }

void FormatValue(char* dest, double value, double ivalue, int space, BOOL tidy) {


if (ivalue == 0) { // fit into `space's on screen int p = space-1; int l; if (value < 0) --p; // adjust for sign

for (;;) { sprintf(dest,"%.*g", p, value); l = strlen(dest);

if (l <= space) break;

if (tidy) { // try tidying tidyNumber(dest); if (strlen(dest) <= space) break; }

p -= (l - space); if (p <= 0) break; // fail safe } } else { int l; char c = '+'; int id = 6; int d = 7; // cooked guesses at rp, ip sizes

if (ivalue < 0) { ivalue = -ivalue; c = '-'; }


// textify the real part sprintf(dest,"%.*g", d, value);

// tidy to save precious chars tidyNumber(dest);

l = strlen(dest); dest[l++] = c; dest[l++] = 'i'; dest[l] = 0;

if (ivalue != 1) { int li; // now fit as much of the ipart as we can for (;;) { sprintf(dest + l,"%.*g", id, ivalue); tidyNumber(dest+l);

li = strlen(dest); if (li <= space) break; // done

id -= (li - space); if (id <= 0) { // very rarely we cant fit ANY of the ipart // on display. shorten the real part and // try again. d -= 2; id = d-1; if (d > 2) goto again; } } } }

// ensure we dont overrun whatever. dest[space] = 0;

... }

[ Return to Index | Top of Index ]

Go back to the main exhibit hall