HP-41: upper bits in module ID fields

[Ángel Martin]

(04-14-2020 08:18 PM)hth Wrote:  Was the upper bits in 0xffe ever defined to mean anything? HP does have a couple of modules that use it. Why does SandMath sprinkle in values like this in the ID area?

I followed the same convention used in the HEPAX to mark bank-switched blocks, so on each of them the flag signals how many more banks exist: 3 for bk#1, 2 for bk#2, 1 for bk#3, or 0 for bk#4. This information is used by HEXEDITors and several of my bank-info utilities (BANK?, BANKED, etc.) - for which I needed to extend the flag convention to also carry the on bank# itself (something the HEPAX didn't care for)

The Advantage used a different approach, but still compatible with my extended setup.
I wasn't aware of the RealState bit, but it may just have been a typo.

BTW this is also the same convention used on the ZEPROMs, although there it was easier since they only supported 2 banks. I believe it's document in the ZEPROM manual.

(04-14-2020 08:18 PM)hth Wrote:  I now need to allocate another flag like this and picked the 0xffe word for this purpose. Is this a "safe" thing to do?

Not sure if you mean that you need to modify all the existing ROM trailers or only use the flag in your own modules. For the former it wouldn't be a safe option, but for the latter I think it shouldn't be any problems or conflicts. Perhaps HEXEDIT will get confused though...

I'm also aware of some modules that use those addresses for regular code - for instance the AECROM has a goto in there, accessed during one of the polling points. The CL_TIME module also uses that space for a similar reason.

So tread carefully!

Cheers,