Introducing... The HP-41Z !! (Kinda long)


Hi Everyone,

If the teaser has worked then you're here to know more about the HP 41Z: is it a new model? an enhanced 41CY? a mispelling?

well, all and none of the above at the same time:-

The 41Z is a new HP-41 ROM dealing with Complex Numbers operation. It has 44 MCODE functions (plus header), including all trigonometric, hyperbolic and their inverses. They are all programmable, and the result is shown on the ALPHA display as well as left in the X and Y registers.

Fundamentally it allows the calculator to work like a Complex-mode machine, albeit there is no need to set it in complex mode - just a few key assignments do the work.

I said it is a MCODE ROM. That's true, but a word on the particulars is in order. In this case MCODE stands more for Macro-Code than for Micro-Code. Many functions make extensive use of the mainframe math routines, so much so that to all effects it is more like an MCODE-version of RPN.

Of course it isn't slower than a well-conceived FOCAL program, but because of the heavy subroutine calling, in some cases the functions aren't much faster either. Speed isn't the goal, but the convenience of MCODE functions versus FOCAL: no registers usage, consistent input-output, etc.

There have been many challenges to get this project ready, not the least of them to overcome limitations of the system platform (a 4-level return stack really isn't enough!!). The ROM is now ready for beta-testing, so let me know if you're interested and I'll swing an image over to you ASAP.

Long live the 41!


Function list:

-HP 41Z














































Very impressive! If I knew how to burn a ROM I'd be most interested. Your article convinced me that it's worthwhile to learn how to burn my own roms.



That is really not an issue today. All you need is one of Digo's Clonix modules and in about 2 minutes you can have any ROM image you want in it. A bit more expensive and difficult way is to find a Zeprom module (good luck) and burn your images into it.



Don't forget that it runs on V41 and EMU41 as well, and there the functions really *fly*.

For non-virtual oeration then of course a Clonix is the way to go. Once the beta testing is over will also be the time to burn all those Zeproms, guys!



Hello, Angel;

I forgot to post my e-mail address in my last post (this thread).

Please, can you send me an e-mail?

Thank you.


Luiz (Brazil)


Angel, congratulations on another MCODE achievement. You are definitely an MCODE champion of this forum. Personally, I do not use complex numbers - have enough trouble with real ones. However, I would be more interested for some kind of manual for your MATH ROM that you released a moth ago. I've tried some functions but they are not that obvious. Any chance we can get some documentation soon.



Hi Miki,

Manuals always follow way behind the software development, but they will come. I've also tweaked some of the functions in the SandMath ROM, which now run better -the bessel routines are now using MCODE subroutines to speed-up the execution. More on this will follow...



Hello, Angel;


I'm impressed with the function set, mostly when one can have a clue (and even be sure) about what are they related to. Wow!

I second Andreas when he mentions that a ROM burner (flash ROM recorder?) for the HP41 is something to have at home. Also, Diego's NoVRAM ROM is suitable for the task, as Miki mentioned.

About twenty five years are past and the HP41 is still an "under development", updated portable system. Amazing!

Cheers and success.

Luiz (Brazil)


Congratulations ! I am definitely interested in trying the complex ROM both on P41CX emulator for PalmOS (this would require the ROM to be sent to Charles Lee, though, since the program can only handle the ROMs that are listed in the ROM manager) and on ev41 for PocketPC. Thanks for sending me the files, and congrats for the work ! Complex numbers were so far the major shortcomings of the 41 compared to the 15C/42S. Does you ROM handle both polar/rectangular form like the 42s does ? This would be a big plus.




The assumption is that data entry is always done in normal mode (rectangular), where Z=X+iY. Polar input isn't expected, but can be done if followed by P-R. And likewise the output is always in cartesian mode. I'm not familiar with the way the 42 does it, maybe you care to elaborate? Enhancements are always possible...

Some functions "force" the RAD mode to do its work. Clear examples are ZLN and e^Z. Some others are happy doing it in DEG mode, which BTW shows better precision when using the internal routines [TOPOL] and [TORECT] - both very tricky to handle.



Hi Angel,
Thanks a lot for your answer.
The 42s was the first calculator allowing to enter complex numbers directly in polar form; however, this is done by changing a flag that affects both entry and display,hence it is impossible to enter a complex number in polar form and then work on it in rectangular form, unless you convert it. Only the 48 and 49 allow to have different modes for display and entry. This would be a great idea for the '41. I feel like using ->R and ->P on the 15C is workable but a bit combersome as you alwas have to convert back and forth.

Btw - did you implement complex versions of inverse trigonometrics, like the 15C and 42S have ? This is what is lacking in the '41 Advantage module and the 32S/32Sii...

And do you use 2-level or 4-level stack ?


What do you think ?


Hi Vincent,

Yes, not only the inverse trigonometric fncs (ZASIN, ZACOS, ZATAN - a little devilish, idn't?) but also the direct and inverse hyperbolics (ZSINH, ZCOSH, ZTANH, ZASINH, ZACOSH, ans ZATANH) are all implemented.

I'll give some thoughts to what you describe on the polar vs. cartesian forms. My first gut reaction is that it almost takes the same effort to change such flag than to eXEQute ->R (or ->P). It would probably be better that the input were defined by the current status when the data are entered, but again remember that this means changing -_DEG or ->RAD as well...



forgot about the stack level part:- It is a 3-level one!

How? Let me begin by saying that I eschewed the use of data registers as a design criteria (simply hate it). My original intention was to use a custom buffer area to hold the imaginary parts of the numbers, and thus that would have allowed a 4-level stack, albeit with required dedicated functions to handle them. For instance, ENTER^ could not be used.

Soon I realized that my MCODE skills are far from being apt to such goal, and thus I reverted to the simpler design of using the four real-stack levels as two complex-stack model (exactly like it's done in the Advantage).

However don't let this put you off, because with the right function set, a two-level stack is more than sufficient. For instance, you can use Z^2 and ZSQRT instead of the more cumbersome Z^N and Z^1/N (wich are also there); HALFZ and DECX/INCX allow you to calculate Z/2 and Z+1/Z-1 without disturbing the stack; I* and I/ work great to multiply by i or by -i; ZENTER^, Z<>W, ZCHS, and ZREV do the trick for stack manipulation; and so on...

finally, consider that by using the normal stack you also have access to all parts of the numbers using the standard function set, which comes very handy as well in many ocasions.

If all this wasn't enough, I'm also using the M and N registers of ALPHA as an auxiliar level (the third). it's a little volatile because ALPHA is also used to show the result (if not running a program), but it comes very handy! Functions for this are: ZRCLA, ZSTOA, and Z<>A.



Hello, Angel;

I remember that the CCD module optionaly uses X-memory registers to create (define) matrices, as well as it allows using regular registers to do the same. The curious fact is that the CCD module defines a new "class" for X-memory registers that hold matrix data (neither ASCII nor data).

I thought about using a data file to hold temporary data (stack values), but taht would impose the need for an HP41CX or an X-F/M module. Have you considered this possibility? I know that this means two sets of routnies (if they are too different) or a major re-doing with the use of some specific command to select X-MEM or REG-MEM operation, or something like this.

BTW: can you point out your "knowledge base", you r source of information, so you could develop such a ROM module? I'm impressed with that because since the 80's I'm dreaming of doing that (develop ROM modules for the HP41), but I thought I'd never find any source of information about his. I'm adding my e-mail if you prefer a private answer.

Congratulations again and success, Angel.

Luiz (Brazil)

Edited: 18 Mar 2004, 10:48 a.m.


Hello Luiz,

Of course I'd consider enhancements, what other purpose would it be by posting on this thread? Your suggestions is what I was seeking for.

Yes, the CCD is an amazing piece of software engineering, but remember that the advantage picked up where the CCD left off!! I know there are great FOCAL programs using the CCD array set that will do the Inverse, Determinant ans solve systems of linear equations. I have done a few myself, but believe me: they all lag *way* *behind* the MCODE functions on the advantage. If you haven't made the comparison you should, you'll be astonished.

The CCD introduced a new file type (index #4) to store matrices. The Advantage uses the same (as it basically is same function set), althought you wouldn't see the "M" descriptor on CAT'4. Additionally, they both use a custom buffer (index #5) where they store the current matrix name and other stuff.

Afraid that my "source base" isn't any single one reference place, but the accumulated (little) knowledge after years of programming. Trial and error. Ken Emery's book of course is a must. I don't have VASM listings, so would really appreciate getting a copy!



"The assumption is that data entry is always done in normal mode (rectangular), where Z=X+iY. Polar input isn't expected, but can be done if followed by P-R. And likewise the output is always in cartesian mode. I'm not familiar with the way the 42 does it, maybe you care to elaborate? Enhancements are always possible...

Some functions "force" the RAD mode to do its work. Clear examples are ZLN and e^Z. Some others are happy doing it in DEG mode, which BTW shows better precision when using the internal routines [TOPOL] and [TORECT] - both very tricky to handle."


You could do internally always cartesian, always RAD, but the display would be determined by Flag settings

Naturally your ROM has to convert in and out when appropiate, but that's easy for you to program, right?



Luiz, paraphrasing the great Sam Clemens' words: "the rumors of the 41's death have been largely exaggerated"

remember that it ain't over 'til the fat lady sings...



To give you a flavor of the type of programs you can write with the 41Z ROM, here is a couple of examples on how to mimic the hyperbolic functions using other functions in the ROM:

hope you agree it looks elegant enough (imagine doing this with standard functions!)

LBL "SINHZ" -> same as ZSINH


LBL "ASINHZ" -> same as ZASINH



Dear Angel,

again good news from you about a HP41 rom solution, now for calculating complex numbers...

Please give more details about your macro-programming-technology : Do you start with a standard focal programm solution, than translating the needed commands to mcode jumps to existing rom addresses of the Hp41 operating system.....

What do you think about adding complex matrix functions, or a solution which uses the existing matrix function set of the CCD-Module...

Best regards – Christoph Klug


Hi Christoph,

There isn't a "technology" per se, although your description is technically correct. It is a very manual process, and takes lots of care and effort to properly access the mainframe math routines (specially without VASM listings!). The 41 OS is an incredible intertwined code, and hacking parts of it isn't for the faint of heart...

As per the complex matrix aspect, I'm very happy with the treatment given by the Advantage ROM to this problem. In fact, even though I really love the CCD Module, I have to say that the lack of high-level matrix operation (MDET, MSYS, MINV) and the capability to work with complex matrices make it unpractical in this area.



Angel, I have to (partially) disagree with you on the CCD ROM. Although there are no 'hardwired' high level matrix functions in the ROM, it is really a trivial programming task to make them. One can just use those given in the CCD manual. And with today's technology (read Clonix) one can put his own favourite math functions (just like you are doing) into a ROM module alongside CCD. I have built my own high level math ROM that is a combination of MATH module, HL MATH and GEOMETRY solutions, and some of my own matrix, interpolation etc routines.

Am I reading your message correctly that you do not have VASM listings. If so, let me know and I can send it to you.


Edited: 18 Mar 2004, 12:07 p.m.


Miki, thanks for your offer. I'd appreciate getting a copy of the VASM listings, will for sure help me refine the code!

I think I already responded this to Luiz, but the CCD array functions, wonderful as they are, were further improved on the advantage. Any FOCAL program to do the high-level matrix functions that you can come up with will be much slower and more cumbersome and inconvenient than the advantage MCODE functions. Besides, "trivial" isn't exactly the word I would use to write them! The CCD manual examlpes are quite lenghty, and will be difficult to improve on them (I remember I tried many moons ago, then I gave up and adopted the advantage!).



Dear Angel,

thanks a lot for the 41Z rom file :-)

Would it be possible to programm the high level matric mcode functions from the Advantage-Module to an own rom solution, for using them with the CCD-Module ?

Regards - Christoph Klug


Hi Christoph,

there's another solution in the works;-)




In a word: I'd rather have one tooth pulled than attempt what you're proposing!!

Seriously, it would be very close to mission impossible, given the levels of intricacy and interdependency between all those functions.


Possibly Related Threads…
Thread Author Replies Views Last Post
  Last call for 41Z/SandMath Overlays... plus new ones Ángel Martin 0 1,485 12-12-2013, 10:27 AM
Last Post: Ángel Martin
  HP Prime: Long integers (continued) Helge Gabert 2 1,508 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  HP Prime: Pass "Long" Integers to a Program Helge Gabert 6 2,445 11-03-2013, 01:12 PM
Last Post: Helge Gabert
  HP Prime polynomial long division bluesun08 13 3,678 10-30-2013, 03:29 AM
Last Post: parisse
  Sandmath/41Z overlays Bernd Grubert 1 1,306 10-29-2013, 03:32 PM
Last Post: 'Angel Martin
  41Z / SandMath Overlays: Ready at last! Ángel Martin 3 1,752 07-23-2013, 01:30 PM
Last Post: Ángel Martin
  Poll: SandMath and 41Z Overlays anyone? Ángel Martin 20 5,255 05-20-2013, 04:13 PM
Last Post: aurelio
  A very long HP-17BII equation Gerson W. Barbosa 22 5,346 04-19-2013, 12:37 AM
Last Post: Gerson W. Barbosa
  A long WP-34S night Siegfried (Austria) 10 3,108 04-16-2013, 02:11 AM
Last Post: Siegfried (Austria)
  HP-25 left on for a long, long, while Matt Agajanian 12 3,597 04-10-2013, 11:33 PM
Last Post: Steve Leibson

Forum Jump: