HEPAX grabbing wrong XROM numbers?

Discussion about the new DM41X calculator
Post Reply
isene
Posts: 44
Joined: Sat Jul 22, 2017 2:02 am

HEPAX grabbing wrong XROM numbers?

Post by isene »

It seems that loading HEPAX with certain other modules freezes the machine (need to pin-reset).

Here's what can be verified:

Load ISENE.ROM (XROM #17) and GEIR.ROM (XROM #23) together with HEPAX (Modified HEPAX 1G) and the machine freezes. I cannot check what XROM numbers the HEPAX RAM pages get, but I suspect they grab conflicting numbers when plugged - because plugging ISENE.ROM and GEIR.ROM without HEPAX works just fine. And so does plugging either module together with HEPAX (but not at the same time together with HEPAX).

I could add that plugging HEPAX + GEIR + ISENE works just fine under HP-41CL (but I have more control over where the RAM pages go and can fix conflicting XROM numbers before the calculator freezes).

Could anyone shed some light on this and how to fix?
rprosperi
Posts: 1048
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: HEPAX grabbing wrong XROM numbers?

Post by rprosperi »

Are you using the HEPAX module from the .zip file here:

https://www.swissmicros.com/dm41x/fat/ ?

This is the only version that should be used with the 41X.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Olivier de Nantes
Posts: 83
Joined: Mon Mar 16, 2020 9:37 am
Location: France

Re: HEPAX grabbing wrong XROM numbers?

Post by Olivier de Nantes »

Maybe the FORTH P7 Module, could be added in this directory ?

See post in topic "Source for additional MOD files"
Olivier de Nantes (Bretagne)


HP41 (x3 : 2CV / 1CX), HP 42S, HP 48G+, HP 71B, HP 15C LE, HP 35S, HP PRIME

DM41L, DM 41X (Beta - SN: 00078), DM 42 (SN: 1028)
isene
Posts: 44
Joined: Sat Jul 22, 2017 2:02 am

Re: HEPAX grabbing wrong XROM numbers?

Post by isene »

Updated all modules to latest from that source. Still freezes - no change.

Could someone try to replicate?

ISENE.ROM = https://github.com/isene/hp-41_isene-rom
GEIR.ROM = https://github.com/isene/hp-41_GEIR.ROM

Load both and the HEPAX module to find your DM41X freeze (try the same on an HP-41CL and it does not).
Ángel Martin
Posts: 109
Joined: Mon Apr 24, 2017 8:19 pm

Re: HEPAX grabbing wrong XROM numbers?

Post by Ángel Martin »

isene wrote:
Fri Mar 20, 2020 6:34 pm
Updated all modules to latest from that source. Still freezes - no change.

Could someone try to replicate?

ISENE.ROM = https://github.com/isene/hp-41_isene-rom
GEIR.ROM = https://github.com/isene/hp-41_GEIR.ROM

Load both and the HEPAX module to find your DM41X freeze (try the same on an HP-41CL and it does not).
This looks like an issue with the module loading functionality, not intrinsic to the HEPAX module itself.
Is there any XROM id# conflict perhaps? The HEPAX will assign #C and #D to the RAM pages, so this may be also creating havoc - but should not lock things up, as it's the case here.

The other thing to check is how did you prepare the .MOD files for those ROMs?
If the settings are wrong that usually leads to lock-ups.
rprosperi
Posts: 1048
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: HEPAX grabbing wrong XROM numbers?

Post by rprosperi »

Other things to check before concluding it's a 41X-unique problem:

A. Does it work properly on V41?

B. Does it work properly on a genuine 41CX using a NoV or Clonix module?

If the custom images have only been used on 41CL successfully, it's possible that is due to idiosyncrasies in the CL. Each of these platforms have minor differences from the others, so a given issue needs to be checked in multiple configurations to isolate the problem cause. If it works on all these other platforms, I'd agree it likely is a 41X issue that could then be investigated.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
isene
Posts: 44
Joined: Sat Jul 22, 2017 2:02 am

Re: HEPAX grabbing wrong XROM numbers?

Post by isene »

I already have the setup working with my NoV-64 and NoV-32 modules. It would take me a few weeks to get around testing on other platforms. But I'd like to explore one line of questioning first: Given that the DM41X user have little control over the sequence of how modules are plugged, it would seem reasonable that HEPAX RAM always get plugged last - since the XROM numbers are assigned by the HEPAX module, it should go last to make sure it avoids conflicts. And if that is not how it is supposed to work already (and thus the issue lies some other place), it should be an easy fix. What do you think?
isene
Posts: 44
Joined: Sat Jul 22, 2017 2:02 am

Re: HEPAX grabbing wrong XROM numbers?

Post by isene »

Bump?
rprosperi
Posts: 1048
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: HEPAX grabbing wrong XROM numbers?

Post by rprosperi »

Not sure if you're looking for feedback from me, but if so, here goes.

The HEPAX module (in the distribution on the SM site) has been tested extensively by a bunch of folks for many months, and has generally been found to have no problems. There is reluctance to force the 41X module loading sequence into something artificial, as it seems it generally isn't needed, and who knows what side effects that will create, we could chase that for months.

With no disrespect for your custom modules intended, if they have not been verified to work properly on all other viable platforms (meaning V41, 41CL and NoVRAM) there is no way to conclude the issue is 41X-specific. Many (!) items suspected of being 41X bugs to date turned out to be cases of things that worked on one of the mentioned platforms, but then after much chasing with no luck, were found to be issues of things that ran on one of the platforms but not the others. Subsequent investigations found and corrected the issues, and the fixed item would then work on the 41X.

The 41X, 41CL, NoVRAM and V41 all have subtle differences in their implementations, and it's sometimes the case that a module has been tested and tweaked to work with one of them, unknowingly conforming to the tweaks in that case.

Once the modules have been verified to work correctly on all the platforms, but still not work on the 41X, then it's a compelling case that 41X has some kind of compatibility issue worth investigating. Note that this guideline is not specific to your modules, but applies to all modules with reported issues, custom or vintage.

hth
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Post Reply