W&W-RAMBOX II and HP-41CY Issues (very long)


Hi HP41 fans,

here, I collected my first experiences with the W&W-RAMbox/MLDL (especially the 64k-based RAMbox II and the HP-41CY). As the debate on RAMboxes has become more alive during the last weeks, I hope that I can add some valuable information on RAMbox features and also how to recover it in case of the loss of its soft operating system. I was told that I should place this information on RAMbox experiences into the Articles’ Forum. As the information can be found there more easily in case that someone needs it in the future this may be a reasonable solution. I am myself not sure if this document is good enough for the Articles Forum and do not know what your opinion is. Anyway, I hope that you can find some (little) valuable information in the text below although these are my very first steps in getting to know the W&W-RAMbox II which I have got only some months ago. Perhaps at a certain point in the future it would be an idea to collect all Forum information on HP41 RAMboxes and combine them to an article in Articles’ Forum.

Best regards,




1) Use of HEPAX with HP-41CY or W&W-RAMbox

2) CLEAR RAMBOX – Properties of MasterClear and PageClear (CLPG)

3) RAM-Switching between Blocks A and B of the W&W-RAMbox II

4) Completely sufficient: Using of only ONE RAMbox-OS instead of BOTH

5) How to reactivate a RAMbox after its OS was deleted due to empty buffer battery ?

6) How to recover a completely -by software- screwed RAMbox-II (or HP41CY)?


1) Use of HEPAX with HP-41CY or W&W-RAMbox

The use of HEPAX with HP-41CY or a W&W-RAMbox is principally possible. It is even reasonable because HEPAX identifies RAMbox-RAM as own HEPAX-RAM-pages. By this a 8k-STANDARD-HEPAX can activate 32k of the RAMbox-RAM as if you had plugged in a 16k-ADV-HEPAX and additionally a 16k-DOUBLE-MEM-HEPAX. Also a ROM-only version of a HEPAX would be capable to manage the “foreign“ RAM in this way. A ROM-only version could for example be realized in a ZEPROM which provides 16k and the full bank-switching capabilities.

As the HEPAX-OS(16k in four banks of one page) maps itself automatically to page 6 (or another page smaller than 8) it frees up all user memory to full 32k. If you plug your HEPAX to port 8, it first deactivates the RAMbox-OS and then maps itself into page 6. So while having only 28k (or 28k + 28k in 2 blocks of RAMbox II) in the original W&W-RAMbox you now have access to all 32k of that block.

If you plug the HEPAX module not into port 1 but into port 3, then you can use the functions of both ROMs – HEPAX and RAMbox-OS – at the same time. This can be very convenient because it allows you to switch between both 32k blocks of a RAMbox II and to also use both types of RAM management – by RAMbox-OS and by HEPAX (e.g. using the RAM as Extended-File-Storage system) at the same time. Further you have access to the full HEPAX functionality like, e.g., 10-bit-hexeditor, disassembler, page catalog, display contrast adjustment, and many useful utilities more.

Here are some details that may be important to know when dealing with the combination of HEPAX and W&W-RAMbox or HP-41CY:


- Some of the RAM may be that from the RAMbox, but other that of the plugged in HEPAX, so the two RAM layers can overlap and parts are hidden. It depends on the contents of the RAM pages when plugging in the HEPAX. It also depends on PG<>. After using this command the other RAMbox RAM block will be active but it will not be initialized by the HEPAX. So you need to switch off and on the calculator. After that all RAM of the second block is also detected and assimilated as HEPAX-RAM.

- If you carry out a RAMbox MasterClear, only the RAMbox-RAM is addressed but not the HEPAX-RAM. As both RAMs may overlap, the RAMbox MasterClear does not erase all RAM. At least after also plugging out and in again the HEPAX, all RAM will be erased.

- In some cases the full RAM of the RAMbox represents the visible layer. Then the MasterClear has access to the whole displayed RAM pages.

- If the HEPAX- or RAMbox-RAM do overlap or not is of no significance because the full functionality RAM+ROM is active in both cases. If one uses a ROM-only version of the HEPAX (i.e. in a ZEPROM) no overlap can occur.

- Due to the possible RAM overlap a conflict can happen between HEPAX and RAMbox. But in general this is NOT critical at all. If a conflict happened one can recognize it by strange CAT-2-entries. If these are visible, you should switch the calculator off again, remove the HEPAX module, switch the calculator on again, then again off. Insert the HEPAX again and switch the calculator on again. Try CAT 2. In most cases now everything is fine and the conflict is removed. If not, repeat the whole procedure until the HP41 has a normal CAT 2.

- Please avoid plugging the HEPAX module into port 4 because here the conflict happens more often. Port 3 is fine (or port 1 if the RAMbox OS shall be deactivated).

- If the RAMbox pages are empty before plugging in the HEPAX module, there should not happen a systematic conflict that cannot be cured by the procedure described above. In case of special ROM images stored in the RAMbox pages or certain MCode, it may happen that a systematic conflict appears. But a strange behaviour can also happen if HEPAX is not plugged in (with any MCode any behaviour may be induced, of course).

- If the HEPAX- and the HP-IL-module shall be used BOTH TOGETHER with the HP-41CY/RAMbox II, the IL module dip switch for the printer should be disabled! Then the triple-combination works fine. Else you get an ILL CONFIG for any module/port combination. The ILL CONFIG is not due to the RAMbox OS but due to the RAM itself. Masking the OS by a standard plug-in ROM does not help.


2) CLEAR RAMBOX – Properties of MasterClear and PageClear (CLPG)

RAMbox-Master Clear of the W&W-OS only deletes all ACTIVE pages. That means that if the full block A is active it is completely cleared even if plugged-in ROM modules are masking some of the pages. So the whole ACTIVE UNDERLYING RAM is erased. The CLPG function of the W&W-OS does NOT clear UNDERLYING RAM if there is a plug-in ROM at its page address. So there is a principal difference between MasterClear and CLPG !

If block A is active, block B is not erased by the MasterClear. After block B is activated by PG<>, a MasterClear deletes this full RAMblock (28k).

Page 8 which carries the 4k-RAMbox OS is never erased because this page of both blocks of the RAMbox is write-protected by a hardware solution. So, no software has write- or delete-access to page 8. The write protection can only be switched off by a mechanical (red) dipswitch inside the HP-41CY or the W&W-RAMbox II.

The erase process of the RAMbox starts with the lowest page address, i.e. at page 9 if page 8 is write-protected.

If you have activated PG01 or PG10, the RAMbox-MasterClear only erases the active (visible) pages, i.e. in PG01-state it erases all even pages in block A and all odd pages in block B. In PG10-state it erases all odd pages in block A and all even pages in block B.
So, the RAMbox MasterClear always only addresses the active RAM area (but also the underlying RAM in that area in case of using plug-in ROMs !).

CLPG cannot be used to delete the W&W-OS even if it is only a copied version that is not placed in the write-protected page 8. The reason is a delete-preventing information within the W&W-OS. I have not yet found out where to deactivating it. It is NOT identical with the copy-preventing information at nFFD and nFFE (where only both 10-bit words with hex#17 have to be replaced by any other value), which prevents to use COPYPG in order to copy the OS itself from one page to another one.


3) RAM-Switching between Blocks A and B of the W&W-RAMbox II

The W&W-RAMbox II uses bank switching in a non-usual manner if compared to the bank switching implemented in, e.g., Advantage, HEPAX, or ZEPROM. It is not completely symmetrical regarding the two blocks. Jean-Francois-Garnier has recently given details on this issue (see http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=49070 ).

If you use the hex editor of the HEPAX in an Advantage- or another bank switched ROM area, the flag indicators show you the active bank and you can switch between them. This is not the case for the RAMbox OS “banks“ A and B, neither for the OS itself, nor for the addressed RAM blocks. RAMbox OS “A“ and “B“ are not linked together in classic bank switched manner but carrying out a bank switch operation activates another RAM area. So automatically, the OS which is placed in that area gets passively be activated by this procedure. So the OS does not switch its own two different “banks“ OS-A/B but it switches the active RAM area of the RAMbox. This can also be easily seen if one exchanges both RAMbox-OS’s, i.e. if one copies OS-A to block B and OS-B to block A. In that case everything works fine except the function PG<> which is without operation because it activates RAM area at page 8 that carries itself (its own OS).

A further important property of the RAMbox layout is that if you plug in a ROM module it is always prioritized to the underlying RAM. So the RAM is masked by the ROM and invisible to hex editors and standard clear procedures. The prioritization does not principally apply for HEPAX RAM that is defined and mapped/remapped by HEPAX software after initialization. It seems to me that it depends on the initial memory state if HEPAX- or RAMbox-pages are prioritized. The prioritization of ROM modules to RAMbox RAM pages does not apply for the RAMbox MasterClear function (see above).

There are three commands of the RAMbox II that support switching between the RAM blocks.
1) PG<> is NOT independent from the state before its use.
2+3) PG01 and PG10 are independent from the state before used (“history-free commands“). Their MCode is IDENTICAL in both RAMbox-OS’s, “A“ and “B“.


With PG01 all EVEN pages of block A and all ODD pages of block B are activated and also OS-A.


With PG10 all ODD pages of block A and all EVEN pages of block B are activated and also OS-B.
So, both commands support an A-B-interleaved page architecture.


There are 4 results that depend on the initial position of the RAMbox:

a) Block A active: PG<> switches to block B

b) Block B active: PG<> switches to block A

c) [A/even, B/odd](OS-A) active (after a PG01-command): PG<> switches to block B.

d) [A/odd, B/even](OS-B) active (after a PG10-command): PG<> switches to block A.

For more details please see



4) Completely sufficient: Using of only ONE RAMbox-OS instead of BOTH

As bank switching of the W&W-RAMbox II is different to classical bank switching in Avantage-, ZEPROMs and other ROMs (see above), the OS A and OS B certainly cannot be implemented in a ZEPROM or CLONIX module in a classical way as two bank switched 4k banks. Nevertheless, it would be advantageous if one could fully replace the soft-implemented OS that is saved at pages 8 of the RAMbox-RAM (write-protected by hardware layout/internal dip switch).

In case that the internal buffer battery and also the calculator battery should fail, the volatile RAM-based OS would unintentionally be deleted. A further advantage of a plug-in-ROM-based solution is that it gives the user the flexible control over the full 64k RAM space. He can remove the ROM and use own MCode functions to address the RAM.

Maybe by implementing the RAMbox OS in a ZEPROM or CLONIX without the internal bank switching one can even save 4k of ROM space (two times 4k is wasted memory for nearly identical code). For example one could replace the PG<> function by two new functions PG00 (ENBANK1) and PG11 (ENBANK2;ENBANK3). Further one should introduce flags that are set or cleared by the four functions PG00, PG11, PG01 and PG10. They memorize the state in which you are just in. This can be important if a program has to ask for the momentary configuration in order to adapt its addressing.

But even without such changes of the code of the original RAMbox OS it is sufficient to use ONLY one OS, e.g. only OS-A or only OS-B, in a simple non-bank-switched ROM/ZEPROM/CLONIX. By this you already have full access to the whole RAM area and to all interacting operations.

First of all, PG01 and PG10 are identical in both OS’s. So with only one OS (e.g. OS-A) you can access [A/even, B/odd] via PG01 and [A/odd, B/even] via PG10. By this you already cover the whole 64k(56k)-RAM area. It does not matter if you define A or [A/even, B/odd] as block “A“. Important is that you have access to all 2x8=16 pages.

But this is not the full story. One very important functionality is an interaction area of both mixed blocks [A/even, B/odd] and [A/odd, B/even]. With only PG01 and PG10 there is NO interaction. The interaction is needed if you want to transfer code from one block to the other, so it is an important basic property! But this can still be achieved by PG<>.

If you use only one of the two OS’s, the PG<>-operation is no longer bidirectional. It is only unidirectionally active. If you use OS-A only, PG<> always activates the full block B, i.e. [B/even, B/odd] (if you use OS-B only, PG<> always activates the full block A, i.e. [A/even, A/odd]). But at [B/even, B/odd] you have access to 4 of the 8 pages of [A/even, B/odd] and also of [A/odd, B/even]. So this overlapping RAM area can be used for code interaction/exchange. More is not needed. Nevertheless an implementation as described above with PG00 and PG11 would be more convenient to the user.


5) How to reactivate a RAMbox after its OS was deleted due to empty buffer battery ?


For RAMbox experts please directly refer to ***) (the rest is only a description of the very basics for reloading a ROM image !)


As the RAMbox-OS of the W&W-RAMboxes I and II (and also of the HP-41CY) is software based it can be erased by accident. In case of a W&W-RAMbox I with only one 32k-RAM block the procedure to reload the OS and to revitalize the RAMbox is very easy. Also to reload the OS of a 64k-ERAMCO-RAMbox is easy because it has mechanical dip switches which are used to switch between the two 32k RAM-blocks.

The most critical issue could be expected when dealing with the sophisticated W&W-RAMbox II that switches between the two 32k blocks by software commands instead of mechanical switches. So when the OS is deleted how to switch between the “guideless“ RAM blocks without it ?

But I experienced this procedure to also being without difficulties. It is described below.

Cases where a RAMbox-OS recovery is needed:

Case a): RAMbox-OS is completely deleted by failure of internal buffer battery (and in addition empty calculator battery).

Case b): RAMbox-OS is partly corrupt due to some battery failure or something else.

Case c): RAMbox-OS was deleted/removed in order to use the full 64k without OS via own MCode routines. There is still MCode in the RAMbox and due to some MCode experiments the user lost control over the HP41. Only a complete physical RAM clear can help.

Steps to perform:


#1) In case b) and c) it may be needed that the RAMbox must be cleaned from any remaining software code which could corrupt the overall calculator management and function (such a remaining code can “kill“ the whole calculator operation and there is no way to remove it because no MasterClear-routine applies anymore. Only power suspension can help to completely erase the RAM).

So, the calculator battery has to be removed, then the HP41 has to be opened and the
internal buffer battery of the RAMbox has to be disconnected or briefly short-circuited. In order to empty the calculator capacitor, the battery contacts should be short-circuited or one has to wait for 24 hours or so.


#2) In all cases a),b) and c) the internal (red) dip switch should be placed to the other than the original position, i.e. it has to be switched to deactivate the write-protection of page 8.

After that the HP-41 has to be re-assembled.


#3) Now you need some additional means:

a) a HP-IL module

b) a HP-IL cassette drive OR a disk drive OR a PC/IL-interface card + ISA-PC + EMU41 emulator
(the PC/IL card can be the HP-82973A or the rebuilt card from Christoph Klug which is market available. The EMU41 can be got from Jean-Francois Garnier for little money).

c) if you have the PC/IL solution you can get the RAMbox-OS as a ROM image from the HP41 community. Then you do not need an own backup.

d) If you do not have the PC/IL solution but a cassette or disk drive then you need a backup of the RAMbox OS on a tape or disk. So when having a RAMbox it is highly recommended to make an own backup as soon as possible (before a later accident happens). If you have no backup tape/disk you can ask other HP41 enthusiasts who will send you a tape/disk with the RAMbox-OS.

e) A ROM module that supports ROM image import from HP-IL mass media. There are several ROMs that can do it, e.g. the HEPAX and different RAMbox OS’s (W&W, Eramco). Many RAMbox users do not own these as hardware ROM modules, so they should get an EPROM box, a ZEPROM or in the future a CLONIX with the needed code. Everyone who owns a W&W-RAMbox should have a CLONIX module when it is available in the future. The CLONIX can either hold such COPY-ROM routines or the RAMbox OS itself (see bullet point 4).

With the plugged-in ROM module (plugged into port 2,3or 4) you carry out a READROM command (or READPG or similar command) to load the RAMbox-OS backup from the cassette/disk via IL to the RAMbox. It is loaded into default block A. The OS should be loaded into page 8 (also all other even pages work as well for the use of the OS, but only page 8 can be write-protected by the hardware).

The procedure up to here is no big news, it applies for all kind of standard RAMboxes whose RAM block switching is hardware based (mechanical switches). For hard-switched RAMboxes this procedure has to be repeated after having changed the switch position.



The important difference of the W&W-RAMbox II to standard RAMboxes is that its block switching is done by the OS itself.
After the OS has been loaded into the completely “guideless“ RAMbox as described above, PG<> or PG10 have to be carried out. After that the calculator often freezes (hangs-up) because the second page is guideless (no OS available) but this is NO problem at all !

The freeze is no heavy hang-up, so you can retrieve the control over the HP41 very easily
by pressing ENTER/ON (halfnut version?) simultaneously or briefly removing and replacing the battery compartment (fullnut version?). This is always working.

In case that you use the HEPAX for READROM a further switching off and on the calculator after that is recommended in order to initialize the guideless second block. After that reload the RAMbox OS-“B“ again into page 8 via IL and a READROM-equivalent function. The plug-in ROM which provides it is still active for this purpose. Alternatively to OS-“B“ you can also load OS-“A“ again (see bullet point 4) if you only have a backup of one OS. After that you have full control over the RAMbox again.



#4) Open the calculator again and set the dip switch back to “write-protection“. This is recommended although the described procedure is simple because else you cannot use the RAMbox MasterClear. Else the OS would “kill“ itself during the clear process.

I have tried these steps without clearing page 8. I had masked page 8 and the OS by a simple 4k-plug-in ROM module and performed the above-described steps with page 10. Everything worked fine. There should be no principal difference in behaviour between the page-8 or page-10 loading procedure.

If you use the HEPAX module for READROM, you should disable the printer dip switch of the IL-module (see bullet point 1).


6) How to recover a completely screwed (by software) RAMbox-II (or HP41CY)?

It can happen that the calculator hangs-up due to experiments with MCode or by loading corrupted files into the RAMbox. This can lead to different levels of corrupt calculator states that sometimes are very difficult to recover. The MasterClear function often no longer works or can only erase parts of the RAM.

The very last step would be to disconnect or short-circuit the RAMbox buffer battery and to perform the steps to reload the RAMbox OS after a complete clear by power suspension (see description above).

But in general this is NOT needed if RAMbox OS is still present and not corrupted. Then masking of RAMbox pages by plug-in ROM modules can help. Please see a detailed description in the Forum:



All the steps being described above have to be carried out at own risk, i.e. I cannot take over any responsibility for any damage that should happen to your equipment.

Anyway, all software actions are not critical at all, but opening the calculator should only be done very carefully and it is recommended to being ground connected (calculator and person) in order to avoid electrostatic shock to the hardware. Information on disassembling the calculator can be found at the hpmuseum-sites.


Edited: 18 Dec 2003, 3:24 a.m.


TNX 4 the info. I did not read all but store it for later.



It's certainly a whole bunch of info!... I'll need some time to fully understand it, as well as confirm the refferences to the Clonix. At first glance those refferences are right.

Thanks for the great job and kind regards.


Possibly Related Threads…
Thread Author Replies Views Last Post
  The HP Prime saga - Part II Michael de Estrada 21 5,874 11-30-2013, 01:04 PM
Last Post: Michael de Estrada
  HP Prime: Long integers (continued) Helge Gabert 2 1,500 11-07-2013, 11:24 AM
Last Post: Helge Gabert
  HP Prime: Pass "Long" Integers to a Program Helge Gabert 6 2,438 11-03-2013, 01:12 PM
Last Post: Helge Gabert
  Re: [WP34S] Flashing Issues Les Wright 22 5,944 10-30-2013, 02:16 PM
Last Post: Les Wright
  HP Prime polynomial long division bluesun08 13 3,651 10-30-2013, 03:29 AM
Last Post: parisse
  HP-Prime: issues in entering expressions fhub 30 7,841 10-02-2013, 12:32 AM
Last Post: Tim Wessman
  ( Parenthetical Issues ) yes, pun intended. Matt Agajanian 3 1,602 09-09-2013, 05:46 PM
Last Post: Matt Agajanian
  HP-32S II Expansion Matt Agajanian 14 3,752 07-21-2013, 10:19 PM
Last Post: Matt Agajanian
  Classpad II fx-CP400 emulator Namir 0 1,064 07-07-2013, 08:07 AM
Last Post: Namir
  HP 32S-II Vertical Curve Program Ron Cardwell 2 1,384 05-20-2013, 07:54 AM
Last Post: Thomas Klemm

Forum Jump: