Calculator blog

During this week end, my 12 year old son came to me with some problems they had been given in class. There was a story of some guys finding others, during the Middle Ages, that used just one hand to count, and therefore count in base 5. From there, a lot of questions and exercises were raised; the good thing about them is that they made children think, as opposed to trying to memorize procedures and methods. One of the questions for the children was to develop a way so that the main character could convert a number in base–5 to decimal, and vice-versa.

We developed together the methods to perform both, but he wanted me to create a couple of programs for his HP Prime to do that. I will have to start learning the HP Basic, after having used most of the time the keystroke programming of the HP15c and HP 41CL.

The HP Prime comes well equipped to perform any kind of base changes - provided is one of binary, octal, decimal or hexadecimal. There is no provision for arbitrary base formulae, so off we go to write the programs!

Tomorrow I’ll try to have the programs written and tested for him, and I will post them here.

When will we have a new version of the HP prime firmware? The previous one comes from May, and it has been a real improvement in a number of areas.

First of all, stability. I have not suffered yet any calculator freeze or reboot with the new firmware. It was something that used to happen with previous firmwares, as soon as you put the calculator through its paces with CAS and other uses. Now this is a calculator that won’t fail you at work. I have seen reports of it failing - but mostly they refer to the Android version, and always related to low-level programming.

Secondly, there are many more functions. Now (please see yesterday blog installment) you can finally program the menus - although at a lower conceptual level than that I would have liked. But nevertheless, they allow you to do much more than was available at the beginning. Event recording is still limited, and we have to find our ways around the existing limitations - but we have people like Cyrille de Brévisson that helped creating the system and is still around to help (see discussions in hpmuseum.org related to limitations in the event handling stack ( 8 levels) and how to circumvent them through clever use of the available functions - wait(–1) instead of MOUSE) but let’s not delve deep on this subject - it deserves a blog installment devoted solely to event handling in the Prime, for which we gave an introduction with suitable program snippets yesterday.

I have just seen a HP Prime version of the NPV, IRR and cashflow applications made by Salvomic, a user in HPmuseum.org. I found it much longer than my own limited programs, which in reality were just functions to be used out of the keyboard, without any procedural or data entry instructions. But then I saw a screen shot with menu items. That was interesting! I had heard that many users wanted to be able to use the menus in the system, but there was no direct access to them with the common HP Prime functions. That got me interested and I started to search the program code for the menu functions information. It ended up being more low-level functions that I initially expected!

Let’s take a look at them. First, you need to know that something has happened, either on the screen as screen touch (or mouse in the case of the emulator), or on the keyboard.

// —————————————————————————————————

// Detect keyboard or mouse input (keyboard has priority)

// —————————————————————————————————

EVENTHANDLER()

BEGIN

eTYP := “”;

kP := GETKEY;

IF kP <> –1 THEN

eTYP := “K”;

ELSE

m := MOUSE;

m1 := m(1);

IF SIZE(m1) > 0 THEN

 eTYP := “M”;

END;

END;

END;

Then, he defines the procedure PUTMENU(mTXT), where mTXT is a list with 6 text elements. The real procedure that draws the menu is DRAWMENU() with all the text elements. Some of them may be “”.

// ———————————————————————

// Draw the menu using the list passed in

// ———————————————————————

PUTMENU(mTXT)

BEGIN

DRAWMENU(mTXT(1),mTXT(2),mTXT(3),mTXT(4),mTXT(5),mTXT(6));

END;

He also defines the procedure GETMENU(mx,my,mTXT), where mx and my are the coordinates of the mouse click, using the convention of starting in the upper left corner of the screen, counting pixels. He uses a simple CASE function, after determining that the mouse click is in the lower part of the screen (line 4 of the procedure)

// —————————————————————————————————————————————

// Get the number of the menu item selected (1–6) by checking mouse position

// Menu items with empty/blank text will return a zero

// —————————————————————————————————————————————

GETMENU(mx,my,mTXT)

BEGIN

mSEL := 0;

IF my≥220 AND my≤239 THEN

CASE

 IF mx≥0 AND mx≤51 AND mTXT(1)>”” THEN
   mSEL := 1;
 END;
 IF mx≥53 AND mx≤104 AND mTXT(2)>”” THEN
   mSEL := 2;
 END;
 IF mx≥106 AND mx≤157 AND mTXT(3)>”” THEN
   mSEL := 3;
 END;
 IF mx≥159 AND mx≤210AND mTXT(4)>””  THEN
   mSEL := 4;
 END;
 IF mx≥212 AND mx≤263 AND mTXT(5)>”” THEN
   mSEL := 5;
 END;
 IF mx≥265 AND mx≤319 AND mTXT(6)>”” THEN
   mSEL := 6;
 END;

END;

END;

END;

So, you can copy and paste (with permission from Salvomic, of course) into your programs! This is an amazing improvement in terms of user friendliness! (I assume you copy this to the program editor in the emulator or connectivity kit, and then transfer it to your "real" calculator!)

There are three modules coming our way, with the latest modules as explained in the previous blog installment.

All of them have been loaded this week by Systemyde, so the owner will enjoy the very latest modules.

The one I am looking forward to is the HP16c Emulator module. I am not doing assembler, but once I did, so I was used to move figures from decimal to HEX and even sometimes to binary. But to be true, at that time we were using 8 bit words and 16 bit registers and addresses, so you can guess that we’re in the very first eighties!

This new module includes support for words of up to 64 bit - which is 8 of the old bytes! Even the HP41c registers were 1 byte shorter!

Monte (Systemwide “factotum”) told me that he uses it already, and defied me to use myself.

You can see the manual here:

http://systemyde.com/pdf/HP_16C_Emulator_Manual.pdf

This module makes use of the Library#4 created also by Angel Martín

Another day we’ll discuss the functions of Library #4 !

There are new images and modification to old images in the memory of the HP41CL processor.

Monte told me that Angel Martin had modified some of their modules. I hope he has changed the behavior of the %T function in Sandmath - at least that was the plan. But there are also some new modules.

You can see the list of modules and their position in the system memory in the official memory reference of the HP41CL. you can find it here:

http://systemyde.com/pdf/mem_ref.pdf

The new modules created are:

• Tides ROM
• US Ports ROM, pages 1 and 2
• HP Calendar Solutions
• Steam Properties ROM
• Poker Rom
• HP16C Emulator ROM (all 4 blocks)

And changes on the Focal assembly ROM, Sandmath 44, the memory functions ROM YFNF, the ubiquitous Library–4, the 41CL Library functions, the Flash YCRC database and, of course, the 41CL Image database.

This time we’ll discuss the pure short term time functions, not the ones related with days between dates, day of the week, etc. We’ll discuss functions that return seconds of milliseconds.

Did you know that you could use the HP Prime as a stopwatch for your experiments in class? You have several functions that can do the trick.

On one side, you have the TICKS function. It returns the internal millisecond clock value. While this function is not exactly what you were looking in itself, the point here is that you can subtract the value of the function at two different moments in time, and you’ll get the number of milliseconds between these two moments. You can prepare a simple program where you launch a subroutine with an input function, that triggers the tick function and stores its result in a variable, and then you launch another in order to end, store the result in a different value, subtract both, divide by 1000 and you have the number of seconds between the two events that triggered the function.

There is another possibility, which is very neat: using the function TEVAL(). It returns the time in seconds that it takes to evaluate its argument. So, if the argument is a program you have created, that, for example, ends when you press a key, the function will return the number of seconds since you started it until you pressed a key. Neat, isn’t it?

Can any of you provide one of such small programs?

This is a message to all users of the HP15CL. I have just seen messages in hpmuseum.org about a program error, whereby the whole program memory is erased, and in some cases, the calculator cannot get out of that state.

In general, this is a battery exhausted-related problem. The original hp15c had a warning when the battery level started to go below a threshold: a small star “*” would appear in the lower part of the screen. With the extremely low consumption of that model, that meant that you had at least one month to change the battery before the memory was erased.

Now, the HP15cLE works in a completely different manner. It uses the same firmware as the old one; but it runs on an emulation layer on an Atmel processor, of similar type to that of the HP30B. There have been very few modifications, so that the firmware can run in a completely different machine. However, there are a couple of bugs that have slipped in during the process. One of them is the odd working of the PSE function (which has been discussed here before); the other is the fact that the low battery indicator (our “*”) is not activated, and therefore there are brownouts before you can tell that something is happening. This means that you will lose your hard-entered programs; in my case, all of 222 program steps for the several programs I have entered. And you know that you will have to enter them again in 12 months from now (which is the typical battery life on normal conditions (meaning you don’t run calculation-intensive programs too often - like long loops, recursive algorithms, SOLVE procedures, etc.). This is quite upsetting for me! I have not entered again a program in one of my two units - the other is still updated.

If a firmware fix were to be developed, then it could be flashed on memory since the HP15CLE can be upgraded much the same way as the HP30b to be converted into a wp34s. And the memory needed is much smaller than that of the HP30B (which is around 128 kb), compared to around 10kb in this case. But please take a deep breath, and sit down - it’s not going to happen any time soon.

There is yet another discussion in HPmuseum.org about the future (if any) of the RPN/RPL entry method (henceforth called RP*, as it is cleverly done in that discussion)

There are a lot of sound opinions there. It is clear that no one of the posters is in denial about the real situation. RPN is the most effective entry method when speed is a fundamental factor (in chained calculations, for example), and when the user knows what he’s doing.

However, this doesn’t apply in an educational setting. There, it is much more important that the boy learns from what he’s doing - and RPN lacks the clarity and readability of algebraic/textbook data entry. Moreover, RPN is not compatible with most current CAS systems, which compounds the problem further. I wander how HP was able to squeeze RPN entry method in the HP Prime spec definition. Probably is the only thing that keeps the Prime a HP - both hardware and CAS have been developed elsewhere (although mainly by HP-related people: guys that have been working for (or with) HP for an extended period of time)

So what is the future for a RPN-enabled calculator? Will it live only as long as people as you and I live? My 12-year old son prefers RPN - but he has not huge experience in calculators. At least there is hope!

If you remember, some time ago we made a blog issue on how to change a specific function in Sandmath 2x2, in its specific use for the mighty HP41CL.

Although the HP41c and its various modules are incredibly powerful, I did not found any %T calculation in a module I wanted plugged in the system - except the latest Sandmath versions. The easiest method is to program it - it is a very short routine, whose simplicity enamored me when I first saw it in the HP41c user’s manual:

LBL %T

1/x

%

1/x

END

However, given that it was a function within Sandmath, why not using it?

Here is the catch: the Sandmath version consumes the Y argument! I mean, when you’re using %T i9n any HP financial calculator, you typically have the total in Y, the partial in X, execute the function, and you get in X the value x/y*100; but you keep the original value in Y; that way, you can clear x with CLX (which deactivates stack lift), you can enter another number and perform the same operation again, saving yourself the effort of entering Y again. The behavior in Sandmath makes it much more similar to other mathematical functions (where in general all arguments are consumed), but doesn’t behave like other HP calculators do.

So I asked Angel Martin for a fix for the Sandmath 2x2, which I published in this blog; but since then, Angel has already produced another 2 versions, each one more powerful than the precedent: Sandmath 3x3 and Sandmath 4x4. As the latest CL modules come loaded with the latter (strictly speaking, they come loaded with all of them!!), I asked Angel how to patch this version. Here’s his answer:

1. first plug the module, say in port 4:

   “SM44”, PLUG4

2. Copy the module to RAM. The location of the SM44 module is 1A0 to 1A3 (is a 4 block module)

   “1A0>840”, YMCPY

   “1A1>841”, YMCPY

   “1A2>842”, YMCPY

   “1A3>843”, YMCPY

The byte to change is 0xp0C3, relative to where you put it. So:

Step 1. introduce in Alpha the text: “8400C3–1111”

Step 2. execute YPEEK. You should get “8400C3–0369”. This is to check that the previous step did work, and that you’re operating on the right byte.

Step 3. modify the Alpha value to “8400C3–0331”

Step 4. execute YPOKE.

Step 5. Plug it to the port of your choice (mine was 2):

“840–16K”, PLUG4L

What are we doing here? Basically, in that position he was addressing subroutine NFRXY, and now he substitutes it by NFRX, therefore consuming only the x argument.

Angel Martin has created a new and exciting module for the hp41c. It provides emulation for the hp16 “Computer Scientist” calculator. It is freely available, and you can burn it on one of the available systems for that (the Clonix family and others), or in your hp41CL if you happen to have the serial module. By the way, it will become part of any new HP41CL modules, since Systemyde is now programming it as a standard module in the system.

It makes use of the #4 library too, so you will have to include it in your hp41 memory in some way (in Systemyde’s HP41CL module, we usually enter it in page 4, by POKEing the alpha string “804040–8120”). Be aware that Angel has recently made some improvements on the #4 library, so you need to load it too, if you were using a previous version of it.

Enough about setting it up. What this emulation module does? Well, all kind of base conversions between binary, octal, decimal and hexadecimal numbers. It makes full use of the alphanumeric 24-character register in the hp41, and is able to manage up to 64-bit decimal numbers (equivalent to 8 bytes or 16 hexadecimal numbers). It is also able to perform all kind of operations with these odd-base numbers, including rotation, carry, sign change, logical operations like AND, OR, XOR, etc.

It is true that the utility of such machines has diminished in our current world of increasingly high level programming languages - Swift couldn’t be farther from assembler code. But there will be occasions when you will have to descend to what is in the processor register, more so when you’re dealing with hardware at low level - and then you need to be able to know in advance how the system would react.

In the next days I will try to get a handle to this wonderful new module. Angel said that there were several things that come in addition to the original feature set of th HP16c, and that we would be in for some surprises. Let’s see!!