How to recover a screwed HP-41CY / RAMBOX-II. Fortunately it is working again !


Hello dear HP41-RAMbox enthusiasts,

here I am back again, and I can tell you the for me very happy news that I succeeded to recover my HP-41CY !
(For those who are interested but do not know about what I am talking here, please refer to the Forum Archive, see )

I write this report because first I want to thank again all of you who helped and supported me by their answering posts in this Forum. So thank you again, Mike, Raymond, Christoph and Angel for your kind posts.

Secondly I want to share my experiences with you on RAMbox recovery in case that your one should run crazy one day, too. These are my first experiments with the W&W-RAMbox, so maybe these results are known by many of you, but maybe they can help others also not being so familiar with that device ... who knows ...
Sorry, if I should bore you by a too long text here ... ;-)

Every synthetic 41-programmer knows that after the HP41 froze or ran competely crazy due to some “ill code“ programming or some “not allowed“ experiments, it can at least be recovered by a Master Clear/Memory Lost. But this only addresses the RAM area and not the Q-ROM-area that is used for Mcode.

Unfortunately, the Q-ROM-Master-Clear of the RAMbox-II-OS is uncomplete and does not help the experimental Mcoder in some cases which easily can happen. What is missing in the RAMbox-II-OS is a “RAMbox Complete Master Clear“-routine that erases all pages of both banks, no matter if you are momentarily working in bank #1 or bank #2. The implemented routine only allows to erase the bank were you are just in (working-bank).

The best way to recover a crazy RAMbox-II will be to write an own Mcode-function that addresses the bank#2 area in a more general way than RAMbox-II-OS does. But before we will have such a new self-made Mcode function, here I want to tell you about a procedure that should always help to recover a HP41CY or RAMbox-II.

My RAMbox went crazy due to some conflict of the plugged-in HEPAX-RAM or the self-switching process of its ROM-pages. By this some “ill code“ was placed in some Q-ROM-area of the RAMbox-II. In general it is possible to work with both devices together, it gives you a full 32k-HEPAX-RAM without losing the 4k-space of the RAMbox-OS and with full HEPAX functionality. This full 32k-RAM can be addressed by, e.g., using only a 8k-Standard-HEPAX module or by a 16k-ZEPROM which only carries the four bank-switched pages of the HEPAX-ROM area. In general this works fine but only in some cases there may happen such a conflict I had to face.

Now the problem was the following: I was in RAMbox bank#1 (OS “A“ being active) and could erase all “ill code“ from bank#1. But I could not erase bank#2 because I did no longer have access via the function “PG<>“ and the RAMbox-OS “B“ was hidden. First I thought that it was deleted as I wrote in my former post at this Forum, but it was not, it was only hidden. I further had tried the function “PG10“ as Raymond also had proposed. That was a good idea to regain access to the RAMbox-OS “B“ because “PG01“ and “PG10“ have a bank- interleaved structure of the 8 Q-ROM-pages. Unfortunately also this function did no longer work and so I could not reactivate OS-„B“.

Now I used plug-in ROM modules in order to deactivate some of the underlying RAM-pages of the RAMbox. At every page were I had placed a ROM module, there the “ill code“ could no longer be active and disturb the system. By this it was indeed possible to regain access to the even pages (#8,#A,#C,#E) of bank#2 and thus to also the RAMbox-OS “B“. Since then I knew that OS “B“ had fortunately not been erased but only been hidden. But still I was not able to access the odd pages (#9,#B,#D,#F) of bank#2. The reason was still remaining “ill code“ at bank#2 which I could not delete neither by a RAMbox-Master-Clear nor by a hexeditor because I had no access to the “infected“ Q-ROM-area.
After a RAMbox-Master-Clear of the even pages of bank#2 I could at least remove all plug-in ROMs without losing again my even pages of bank#2.

Now “PG10“ was working again and I could use it to switch from OS-“A“ to OS-“B“. Back to OS-“A“ I could jump by using “PG<>“, but not in the other direction! The odd pages always showed the contents of bank#1, no matter if OS-“A“ or OS-“B“ was active.

As I was not able to mask the still remaining “ill code area“ by a plug-in ROM module, the “ill code“ could only be in page #9 of bank#2. The reason was that I could mask any page-pair #A&#B, #C&#D, #E&#F by using an 8k plug-in ROM or page #A,#C,#E by using a 4k ROM, but I could not mask pages #8 or #9, because then I would have hidden and deactivated the RAMbox-OS at page #8 which I had to use for the functions “PG<>“ and RAMbox-Master-Clear.

So, I copied the RAMbox-OS “A“ and “B“ into an even page (page#A) by “COPYROM“ of the HEPAX module. I had to choose an even page because only the even pages were accessible at bank#2 (see above) and the still not completely erased “ill“ bank#2 was the important one in this case. The built-in “COPYPG“ function of the RAMbox does not work here because there is a copyright-protection implemented by W&W that does not allow to copy their own OS. For those who do not have a HEPAX, please see “Appendix“ below for alternative solutions.

After I had copied the OS to page#A, I masked pages #8 and #9 by plugging a 8k ROM module into port 1. Using only a 4k-ROM module is no solution because it only masks the even page of a port, i.e. page #8 in this case. But still the “PG<>“ and “PG01“ functions were not working properly. What now ? Yes, the worst case scenario had happened to me, there was not only “active ill“ code in page #9 but also in other odd bank#2 pages. So I had to mask both, page #9 by the 8k ROM and page #D by another 8k ROM which I could identify to be the villain. Now everything was fine again, I could again use “PG01“, and “PG<>“ in all possible directions. I made a RAMbox Master Clear in bank#2, and by this the “ill“ code in page #9 was erased.
Of course the RAMbox Master Clear got stuck because I performed it from the copied clone in page #A which was not write-protected. But fortunately the erase process seems to begin with the lowest page addresses. So the “ill“ code in page #9 was erased first before the OS in page #A killed itself. If the method with the self-killing Master Clear had not worked, I would not have known what to further do. Using the HEX-Editor of the HEPAX, by which you can delete whole page blocks does not apply because it only “sees“ the plugged-in ROM modules which I still needed for masking the “ill“ code (if you removed the masking ROMs, the RAMbox switched back to bank#1 instantaneously, I checked that). The same problem applies for the RAMbox's own function "CLPG" which also cannot clear a RAMbox page which is momentarily deactivated by a ROM module.

After having pulled out (“cold“ pull out of course) the 8k-ROM in port 1 the HP41 was working again. I performed a second complete Master Clear from the write-protected OS and erased also the remaining “ill“ code in page #D.

Now I could remove all remaining plug-in modules and now, my HP41CY was fully functional again ..... puuuuh, you cannot imagine, I am glad ! :-))))))))))))


Concerning the COPYROM function:

As the HEPAX module is very expensive and also extremely difficult to find these days, I cannot recommend the HEPAX-solution for RAMbox recovery here without reservation, of course. For someone who only owns the RAMbox-II or HP41CY but no other MLDL device or ROM/EPROM with a copy-page function should do the following: Take the RAMbox-OS-image which you can get from other HP41 enthusiasts and change both 10-bit-words at ’nFFD’ and also at ’nFFE’ to any other value than 17 (hex). 17,17 means “WW“ (=23,23 dec, i.e. the 23rd alphabetic sign, that is “W“. Maybe it looks like my own name initials ;-) but sorry they are not ... unfortunately I was not involved in the development of this brilliant device HP41CY ... ;-))
A kind HP41 expert had given me this valuable indication. Thank you, #D (I am sure you can identify yourself ...), again for this valuable information! I did not want to name you here again as I do not know if you want so. I found out that you have to change both (hex17)-words, so not only the second one, if you want to copy the page.

After RAMbox OS image modification you can load it from IL mass media or via IL/PC-gateway to your HP41. Alternatively, you can load the “COPYROM“ function from another ROM image, i.e. from HEPAX-OS or Eramco-OS or others which are easily available for free in the web.

Then you can perform the same steps as I did with help of HEPAX.


I would have really been sad if my RAMbox would have been dead as it is so difficult to replace. I really also hope for the MLDL2000 of Meindert and for the CLONIX of Diego. These will be very helpful devices. I would like to use a CLONIX with bank-switching for hard-implementing the RAMbox-II-OS (“A“ at bank#1 and “B“ at bank#2). Then in principle one could also remove the internal buffer battery.

Last not least, let me again thank you very much for your helpful comments after my last post in the Forum where I had asked for help. This Forum is crowded by a really good community which I know for only one year since I revitalized my HP41 interest after about 15 years.

Best regards from Germany,


Edited: 12 Dec 2003, 2:43 a.m. after one or more responses were posted


Good news for you, bad for me. Yesterday I recognized that my CY doesn´t work properly. I deleted all pages with CLPG and the calculator was working like a normal CX. I made a backup on cassette from all pages of a W&W Rambox I´m using on another CX. Now I wanted to copy them to my CY.. All was ok and I could copy all pages back untill I had a "page broken" on page 13. I thought that was only the end of the cassette. But now the horror! When I powered off the CY and tried to power it on again, it didn´t start up.
How can hepl me restarting a CY that doesnt poweres up? I think, when I take of the CY´s backup battery, all pages have to be cleared and I can reconfigure it. Is that right? Does someone has a better possibility?



Hallo Matthias,

please do not worry too early. I believe that it can be fixed. The example of my own RAMbox crash shows this to you, too. There was always my worry that there might be a hardware defect but I think it is very easy to screw up a RAMbox on pure software basis with some “ill“ Mcode which you can also easily generate by a momentarily disturbed cassette transfer or a partly disrupted cassette file.

The broken page is no reason at all to get worried. As you might have had a not perfect cassette transfer the checksum may have been disturbed.

Don’t worry that your HP-41CY did not power up. That happened very often to me throughout my experiments. First try to reactivate it by several trials of CLR/ON(MemoryLost-MasterClear). If this does not help take out the battery compartment (the standard HP41 batt compartment, not of the RAMbox) and replace it immediately. Then again several trials of CLR/ON until the HP41 shows MEMORY LOST. Often this does not happen with five trials or so, so do not give up and repeat CLR/ON and also ENTER/ON (hold both keys at the same time).
When the RAMbox asks you for a RAMbox Master Clear, do it. Maybe after that your 41CY is already healthy again. Try to clear both 32k banks !

If not, there are many possibilities to fully recover all RAMbox functionalities as I had to pass through (please see my steps that I have described before, but certainly your CY is not as much screwed). I think you do not need to disconnect the internal buffer battery for recovery!

This would be the very final approach. In that case before you should program one of your ZEPROMs with OS-“A“ at bank #1 and OS-“B“ at bank #2 (you have a Zeprom burner, so you can do it with your other HP41). Christoph already had sent me the ROM images of the OS. It is in EMU41-bin format. He or I can send you these images via email (but not today evening because I am just in a hurry for dinner ...).

But certainly this very last step will not be needed! Certainly you will be able to recover it by the above described steps.

And certainly there will not be any hardware defect. So do not worry too early! Please tell us the status of your trials if still problems remain and certainly we will find a solution how to proceed.

Good luck and “see“ you again ...



I just had a long telephon call with Raymond del Torno. He found a very easy was to reinitialize my CY. Now it works perfect.

I told him about the broken page 13. The told me, that the calculator tries to address all pages during the startup. Now there is a broken address in the startup. That was the cause for the hangup.
We decided to put a standard application module in port 3. So the calculator did not address the page 13 on the RAMBOX but in the real module. So I could startup the calculator.
With CLPG I deleted all pages so that they are clear for reprogram them.

Thanks to Raymand, he saved my sunday!


Nice - enjoy!


Possibly Related Threads…
Thread Author Replies Views Last Post
  The HP Prime saga - Part II Michael de Estrada 21 5,798 11-30-2013, 01:04 PM
Last Post: Michael de Estrada
  PRIME: re-format the flash drive to recover the operating system Harold A Climer 2 1,701 11-06-2013, 12:22 AM
Last Post: Michael de Estrada
  HP Prime Save Power Turn Off Not Working Timothy Roche 12 4,115 10-27-2013, 01:41 PM
Last Post: Michael de Estrada
  Temporary User Mode Key Programs not working in RPN BruceTTT 7 2,664 10-14-2013, 01:46 PM
Last Post: BruceTTT
  HP-32S II Expansion Matt Agajanian 14 3,693 07-21-2013, 10:19 PM
Last Post: Matt Agajanian
  Classpad II fx-CP400 emulator Namir 0 1,058 07-07-2013, 08:07 AM
Last Post: Namir
  HP 32S-II Vertical Curve Program Ron Cardwell 2 1,368 05-20-2013, 07:54 AM
Last Post: Thomas Klemm
  HP-97 suddenly not working Brad Barton 10 2,750 02-25-2013, 08:15 PM
Last Post: Brad Barton
  [41CL] Problem with PowerCL ... not working Doug (NYC) 5 1,962 01-22-2013, 07:18 PM
Last Post: Doug (NYC)
  42S exit key not working dwsmith 4 1,642 11-05-2012, 10:59 AM
Last Post: dwsmith

Forum Jump: