Imprimir

Calculator blog


Musings and comments about our common interest

 

Publicado el por

Sandmath 4x4 fix for %T (same as for Sandmath 2x2 previously)

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.

Leer mensaje completo