|Re: HEPAX (NoV-32) reproducible error|
Message #12 Posted by Meindert Kuipers on 4 Mar 2008, 3:07 a.m.,
in response to message #11 by Geir Isene
For Clonix or NoVRAM, you would need to make the correct configuration with the main HEPAX being in an odd numbered page. I do not think it can be just moved, you need to make a new configuration. I have never done this myself.
With MLDL2000 it is quite easy to move ROM images around and put anything in an odd numbered page.
The trick here is that HEPAX is normally a hard wired module, and is fixed to the even page of the port it is plugged in. The text below is from a paper that Howard Owen presented at the HHC2008 conference (it is in the conference proceedings). Note that the initialization of HEPAX memory most now be done by hand, but that process is also described in the paper.
Mapping the ROMS into HP41 Address Space
The first thing we need to determine is where we want the HEPAX module to live in the HP41's address space. Since the HEPAX occupies only 4Kibi words in the 41's memory map by using bank switching, we only need to find one free page to load the module into. However, there is an additional complication we have to take account of at this point. The HEPAX uses some undocumented instructions of the Nut CPU to aid in its initialization routines. The MLDL 2000 doesn't support these instructions. So if the HEPAX is allowed to run its normal initialization, it will fail and the module will be unusable.
The solution to this problem is to load the HEPAX into an odd numbered page in the 41's address space. Since the HEPAX code assumes it is running from a real add-on module plugged in to one of the HP41's four ports, its page must be even. (Ports occupy two pages each of address space. The lower page always has an even page number.) The first thing the HEPAX does on initialization is to try and relocate itself to the lowest numbered port that doesn't already contain a module or system ROM. In order to do that, the HEPAX has to find itself in memory. It does that by looking for it's own ROM ID in the even numbered pages only. If we load the module into an odd numbered page, the HEPAX will not find itself, and will abort the initialization. This allows us to avoid the execution of those
undocumented instructions, but it leaves us responsible for finishing the initialization that the HEPAX aborted out of.
Hope this helps to explain things.