+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: HP-41: upper bits in module ID fields (/thread-14852.html)
HP-41: upper bits in module ID fields - hth - 04-14-2020 08:18 PM
HP-41 modules has a four character ID field at address 0xffb-0xffe, used to identify the module and version, i.e. AD1B.
Normally the values stored here are low numbers and HP defined the 0xffd word to also carry a flag if the module is banked. This is done by setting any of the upper two bits (of the 10-bit word) to non-zero.
I now need to allocate another flag like this and picked the 0xffe word for this purpose. Is this a "safe" thing to do?
After running through some modules I found a couple that actually store non-zero bits in that position. Advantage module puts 0x201 (letter A with one of the upper bits set). Real Estate stores 0x100 there. SandMath 4x4 stores a lot of upper bits in the whole ID field area and it varies a bit when I dig deeper into the pages.
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?
RE: HP-41: upper bits in module ID fields - Sylvain Cote - 04-14-2020 08:24 PM
I remember having read somewhere that some of those bits are used for something but I do not remember what for right now.
I will try to find the source of that information tonight.
RE: HP-41: upper bits in module ID fields - Ángel Martin - 04-15-2020 05:49 AM
(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,
RE: HP-41: upper bits in module ID fields - Ángel Martin - 04-15-2020 06:19 AM
Here's the text in the ZEPROM manual, never mind the references to "cores" (something only ZEPROMS have), but see the bold sentence included:
"The ZEPROM hardware initially determines the configuration is bank-switched or
straight from the two most significant bits of data at address location xFFD in core 1. If
both bits are clear, then the module is considered as straight 16K. If either or both bits
are set, then the module is considered as being bank-switched. In a bank-switched
configuration then either one or both of the two most significant bits of the data at
address xFFD in core 3 should also be set. If this is not done, then ZEPROM will be
able to select the secondary bank, but will not be able to return to the primary bank.
The use of the most significant bits of address xFFD complies with the bank-switching
convention established by Hewlett-Packard; in which any bank switching page will have the most significant bit of the data at address xFFD in that page, set. Remember however that ZEPROM only references the bits in core1 (and core 3) to determine if the entire ZEPROM is bank switching. The PROGRAMMER ROM software also uses an extension of the HP convention to determine if a page is bank-switched and also which page is currently selected"
That was back then but later on the HEPAX introduced a more capable Bank-switching scheme (added two more banks to the picture), so my guess is they extnded the x0FFD conventions also to xFFC and 0xFFB - which should infer that using 0xFFE is a safe option for HEXEDIT though...
ÁM
RE: HP-41: upper bits in module ID fields - Sylvain Cote - 04-15-2020 12:10 PM
I had found the information in the ZEPROM manual (P.10) but Ángel beat me to it and way better that I could ever have.
RE: HP-41: upper bits in module ID fields - hth - 04-15-2020 07:38 PM
Thank you for the information.
The background is that I need a way of telling if a module page contains a secondary FAT. That secondary FAT structure can start anywhere in bank 1. Its root pointer is the word at page address 0xfc2 (the address before the bank switchers). However, that location will obviously contain something else in a module that is not aware of the scheme, so I use the upper bits of 0xffe to indicate whether that location is such root pointer or not.
I take from the comments above that the upper bits in 0xffe are "free", though some occasional module might have bits set there. I guess that I just have to be incompatible with those then.
I forgot about the potential issue with 41CL, good that you pointed it out. Luckily it seems the word at 0x5ffe is 0x0014, so it is safe in this regard.