HP Forum Archive 18

[ Return to Index | Top of Index ]

HEPAX (NoV-32) reproducible error Message #1 Posted by Geir Isene on 26 Feb 2008, 5:16 a.m. This error is consistent with my NoV-32/HEPAX: 1. GTO a program in HEPAX RAM 2. SST fast, it then jumps/slips to Main RAM (first program) 3. First page (#8) of HEPAX RAM is now lost and HEPAX itself is now relocated to to this first page (#8). Can anyone confirm this error? Can this be reproduced with the original HEPAX modules?

Re: HEPAX (NoV-32) reproducible error Message #2 Posted by Eric Smith on 26 Feb 2008, 1:55 p.m., in response to message #1 by Geir Isene Only happens when you SST "fast", not slow?

Re: HEPAX (NoV-32) reproducible error Message #3 Posted by Geir Isene on 26 Feb 2008, 2:52 p.m., in response to message #2 by Eric Smith Correct.

Re: HEPAX (NoV-32) reproducible error Message #4 Posted by Eric Smith on 26 Feb 2008, 7:05 p.m., in response to message #3 by Geir Isene Hmmm... Nonpareil doesn't yet have HEPAX support, but it might be interesting to try to reproduce that with V41 (from The Other Site).

Re: HEPAX (NoV-32) reproducible error Message #5 Posted by Geir Isene on 2 Mar 2008, 11:28 a.m., in response to message #1 by Geir Isene Is this reproducible on a MLDL2000 with Hepax?

Re: HEPAX (NoV-32) reproducible error Message #6 Posted by Meindert Kuipers on 2 Mar 2008, 2:19 p.m., in response to message #5 by Geir Isene Just played with this, and I do see some strange behavior. I assume that the SST is done in PRGM mode? It actually goes OK when single stepping, but stopping SST, waiting a few secs and then press SST again will return to main RAM. No pages are relocated though. Remember that HEPAX itself is always in an odd page in the MLDL2000 (page 9 in my case), the first HEPAX RAM page is in page A. In the early versions of the MLDL2000 firmware there would be sometimes odd behavior when SST through mcode with the David Assember, but this was due to an internal timing issue. I also did a quick test with V41, but no problems there. I tested again with MLDL2000, but now I do not see any problems anymore?? Meindert

Re: HEPAX (NoV-32) reproducible error Message #7 Posted by Geir Isene on 2 Mar 2008, 3:08 p.m., in response to message #6 by Meindert Kuipers Meindert: Yes, it is SST in PRGM mode. Can anyone with a NovRAM or NoV-32 confirm this strange behavior? Also, can I somehow locate HEPAX permanently in (for instance) page #8 (like in MLDL2000)? Maybe this will cure the accidental relocation of HEPAX to page #8 when I do the SST in PRGM mode. It may stabilize the setup further.

Re: HEPAX (NoV-32) reproducible error Message #8 Posted by Meindert Kuipers on 3 Mar 2008, 3:09 a.m., in response to message #7 by Geir Isene Hepax cannot be in Page 8 in the MLDL2000, it must be in an odd numbered page (see Howard Owen's paper on using Hepax in the MLDL2000 as part of the HHC2008 proceedings). The relocation of pages (this is a special HEPAX instruction) is not supported in the MLDL2000 anyway, which is also the reason why HEPAX must be in an odd numbered page. Meindert

Re: HEPAX (NoV-32) reproducible error Message #9 Posted by Geir Isene on 3 Mar 2008, 10:22 a.m., in response to message #7 by Geir Isene Quote: Also, can I somehow locate HEPAX permanently in (for instance) page #8 (like in MLDL2000)? Maybe this will cure the accidental relocation of HEPAX to page #8 when I do the SST in PRGM mode. It may stabilize the setup further. I was meaning to say: Also, can I somehow locate HEPAX permanently in (for instance) page #8 in my NoV-32/NovRAM (like it is located in page #A in MLDL2000)? Maybe this will cure the accidental relocation of HEPAX to page #8 when I do the SST in PRGM mode. It may stabilize the setup further.

Re: HEPAX (NoV-32) reproducible error Message #10 Posted by Meindert Kuipers on 3 Mar 2008, 10:38 a.m., in response to message #9 by Geir Isene OK, I get the point. To prevent relocation you should make certain that it cannot relocate to another position by filling all alternative positions with ROMs. AFAIK HEPAX will try to relocate itself to the lowest available page. Also, the trick used in MLDL2000 can be used in Clonix/NoVRAM by positioning HEPAX to an odd numbered page to begin with, for example Page 9. It will then not try to relocate on startup, but it might do so when things go wrong. Meindert

Re: HEPAX (NoV-32) reproducible error Message #11 Posted by Geir Isene on 3 Mar 2008, 2:58 p.m., in response to message #10 by Meindert Kuipers Quote: Also, the trick used in MLDL2000 can be used in Clonix/NoVRAM by positioning HEPAX to an odd numbered page to begin with, for example Page 9. Now, how exactly would I manually allocate it to let's say page #9? And what is the significance of the odd page number?

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. Meindert

Re: HEPAX (NoV-32) reproducible error Message #13 Posted by Jeff Davis on 2 Mar 2008, 4:52 p.m., in response to message #6 by Meindert Kuipers Meindert, I do still have problems SST in MCODE using the David Assembler on the MLDL2000. Sometimes when I step once or twice, stange gibberish appears. Other times I get kicked out of the ASSM mode altogether. I originally thought I had some software conflicts with the Zenrom and M2K ROM. Is there a new software for the MLDL2000 that might have this timing fixed. I have unit 2073. Please let me know. Jeff Edited: 2 Mar 2008, 4:52 p.m.

Re: HEPAX (NoV-32) reproducible error Message #14 Posted by Meindert Kuipers on 3 Mar 2008, 3:05 a.m., in response to message #13 by Jeff Davis Jeff, I do have new firmware, but I was waiting to release it until I have the new M2kM software version ready (with support for MOD files). When you are avialable later today you may skype me and we'll do an online session to upgrade your firmware. Meindert

[ Return to Index | Top of Index ]

Go back to the main exhibit hall