Help request for someone with a real HEPAX



#14

I've recently been informed of a potential problem with HEPAX simulation, which occurs on simulators by multiple authors. Unfortunately I cannot find my HEPAX module at the moment to verify how it behaves. If anyone with a real HEPAX (not e.g. Diego's NoVRAM or NoV64) has a spare few minutes to try something for me, I'd be most appreciative. Just contact me by email.

Thanks!
Eric


#15

Hi Eric,

I do have an HEPAX module

so, if I can help...

Regards,

Jean-Marc.


#16

Thanks Jean-Marc, but others here on the forum have now done the test I needed. The NoV-64 and HEPAX work as expected, but V41, Nonpareil, and i41cx+ have a bank-switching issue.

I've ordered a NoV-64, and once I get that I can collect logic analyzer traces for comparison to the simulators.


#17

I am curious on what the issue is?


#18

I am interested as well to find out about this issue. I can do some tests with HEPAX in the MLDL2000, and get accurate traces. This is not the real HEPAX however, but a copy in Flash ROM with its own bankswitching mecahnism.

Meindert


#19

I'll leave Eric to elaborate as he sees appropriate but it's related to some instances where the operation fails to switch back to bank1.

I tested the real HEPAX, the NoVoRAM and the MLDL2k and all of them manage to work as expected.

I however remember being able to trip up the HEPAX itself but don't know the sequence anymore. - In fact, that's how I managed to look at bank3, taking advantage of a failed switch back. Surely involves calling XF or HEPAX...


#20

Hi all,

There are a couple of things that makes bankswitching (BS) a not-so-easy feature to be implemented, neither physical nor emulated.

First is the fact that *every* BS module (or its emulated counterpart) *must* be able to interpret the ENBANK instructions, modify their internal memory addressing accordingly *and* keep track of it. This must be done independently inside every BS module.

Second, every non-BS module (including OS mainframe) *must* be accessible no matter which bank is active in the BS module where the "call" (JC/JNC) comes from.

The mess may come from any combination of these two sources:

Example 1: A BS module is running on bank n (n>1) then it jumps to an address in a non-BS page. If emulator does not have *all* non-BS pages visible from *all* banks you'll get a weird behaviour... (more likely a crash).

Example 2: Emulator includes ENBANK handling... (this is needed if it emulates CX) but just one bank pointer (instead of one for every BS module). Then it switches accordingly to the "last" ENBANK instruction, but it will switch "every" BS module... again a source for weird behaviour, since a BS module with 4 banks could be accidentally swiched back to bank n (say 2) when it is supposed to be in bank k (say 3).

To my mind the bug reported by Eric is about this second example. I faced this very same problem when developing the NoV-AdvH modules emulation, which handles two BS modules (HEPAX & Advantage) with the same code.

Software emulators will need one BANK pointer for OS (CX) + one for HEPAX + one for Advantage... IR... etc...

Don't know how MLDL handle BS but, since it's a physical device as NoV's, they don't need to care about the OS pointer (calculator itself handles it) that's why HEPAX works as expected on both. However, this is the reason why you cannot (yet) run Advantage into NoV-64: a second BS pointer is needed.

Rule of thumb:

BS modules: must have a dedicated BANK pointer for each BS page.

non-BS module: must be visible from every posible BANK (1-4)

I've also implemented a safety rule into NoV's: BANK is always set back to 1 just before STAND-BY.

Hope this helps.

Diego.


Edited: 25 May 2010, 7:39 p.m.


#21

Thanks for this explanation Diego.

Most modules implement bankswitching in a pair of banks (one module port), and that is how the MLDL2000 does it, every pair of banks has its own register to remember the state. ANd I realize that this is a source of possible conflict, if 2 BS modules are used in the same (virtual) module slot.

The W&W RAMBOX (and also the 41CY) can switch pages in a different way, but I have forgotten how exactly.

It is important to return to bank 1 on STANDBY, I forgot this in the first MLDL implementations, and both HEPAX and Avantage ROMs will not work in that case.

Still it would be nice if Eric could explain the suspected bug in some detail ...

Meindert


#22

Hi Meindert,


Quote:
The W&W RAMBOX (and also the 41CY) can switch pages in a different way, but I have forgotten how exactly.

For obvious reasons I have this information really "fresh" in my mind.

However, I don't think the term "Bankswitching" is fully appropriate. Although it also makes use of the same pseudo-instructions (H'100, H'140 & H'180) it's more a question of available OP codes than real Bankswitch. If I'm allowed to name it I'll choose "RAM swapping".

The process was first (and accurately) described by J-F Garnier in this thread.

Again, implementing this on emulated or physical devices is somehow cumbersome. IMHO this this one is a bit easier for the SW guys, than for the HW ones.

Best from Madrid.

Diego.

#23

Antonio Lagana tracked down the HEPAX issue to the Nonpareil code failing to select bank 1 when going into sleep states (either light or deep sleep). Neither he nor I ever noticed any issue with the Advantage ROM without that.

The specific symptom was that in PROGRAM mode, when entering the XP or HEPAX functions, bank 3 would remain selected. This results in the HEPAX functions not being available, and the bogus FAT of bank 3 showing in CATALOG 2.

I suspect, but have not verified, that doing this on an HP-41 with both a HEPAX and HP-IL Development module, and with flag 44 set (possibly by executing the "ON" function of the HP-IL Development module), would result in the same behavior.

Flag 44 prevents the 41 from going into deep sleep, but with the HP-IL Development module installed, it also will not go into light sleep.

#24

Diego, thank you for the in depth explanation!

I had the bug in my not released emulator as well, I just corrected it.

It makes perfect sense, the ROM will just react to bank switch instructions when fetched from the same unit. Otherwise it would need to contain bus decode logic to spot bank switch instructions, which would complicate the design.


#25

You're welcome Håkan.

I'm glad to know this info has been useful.

Look forward to seeing your emulation released.

Best.

Diego.

#26

Much thanks to Ángel Martin, Diego Diaz, Peter Platzer, and Antonio Lagana for their assistance in tracking this down!


Possibly Related Threads...
Thread Author Replies Views Last Post
  Four-Level RPN and the Real World Matt Agajanian 14 2,793 12-13-2013, 03:57 PM
Last Post: Manolo Sobrino
  "HexZombie - a tool for real programmers" Thomas Chrapkiewicz 8 1,287 11-16-2013, 12:46 AM
Last Post: Kiyoshi Akima
  Prime feature request Stefan Dröge (Germany) 0 465 11-06-2013, 11:06 AM
Last Post: Stefan Dröge (Germany)
  request M.E. pac for HP-67/97 wallet cover scan Ignacio Sánchez 0 495 11-06-2013, 09:36 AM
Last Post: Ignacio Sánchez Reig
  Unexpected problem with the real Prime Javier Goizueta 4 901 10-08-2013, 01:00 PM
Last Post: Marcus von Cube, Germany
  HP-Prime Polynomials: User Guide and Request CompSystems 4 950 09-30-2013, 09:48 PM
Last Post: Han
  HP Prime "Notes" feature request Charles Bennett 0 420 09-27-2013, 12:14 PM
Last Post: Charles Bennett
  [REQUEST] Your "Prime" Conference Questions Tim Wessman 9 1,269 09-22-2013, 05:34 AM
Last Post: Giancarlo
  [HP-Prime xcas] operations with complex numbers + BUGs + Request CompSystems 9 1,543 09-08-2013, 10:40 PM
Last Post: CompSystems
  [HP-Prime xCAS] Review Polynomial Tools + BUGs + Request CompSystems 0 450 09-05-2013, 12:53 PM
Last Post: CompSystems

Forum Jump: