HP-41 XROM numbers

[hth]

(11-20-2019 02:46 PM)Sylvain Cote Wrote:  Synthetic Instructions XROM, where is this coming from ?
First look into bytes encoding make no sense, need to look deeper into this.
After 40 years, I still discover things on the HP-41 ... or re-discover due to ageing

When you press a key assignment, the 2-byte function code has its highest nibble inspected. If it is non-zero, it is assumed to be a 2-byte XROM.

Knowing this, we want to display the function name, but as it is an XROM it needs to scan for it using GTRMAD. For a 2-byte synthetic assignment, this will interpret the real function code (RCL M or whatever) as an XROM, extracting the ROM ID and function number (it assumes it is in A000-A7FF range, but that is not checked as it cannot happen in the normal HP-41).

GTRMAD will most likely fail to find a matching function and this is reported back. We now want to display the function anyway (the case where the key is being held for NULL test), so we go to XROMNF to display it as and XROM with numbers. This makes use of that GTRMAD always output the split up ROM Id and function code, even when it fails.

The formula used internally (in GTRMAD) for taking a two-byte instruction and getting the XROM i,j is:

Code:


i: (fcnCode & 0xfc0) >> 6
j: (fcnCode & 0x3f)

So for a 7-byte byte grabber we often use F73F (to get a question mark in the inserted alpha string literal, mainly for easy recognition):

Code:


(0xf73f & 0xfc0) >> 6 ->  28 (decimal)
(0xf73f & 03f) -> 63 (decimal)

Thus, we will see XROM 28,63.

Technically, the 0xfc0 constant should be 0x7c0 for a correct number. However, the code assumes valid input (A000-A7FF), so it makes use of that knowledge save some MCODE instructions. This is why you may see XROM Id above 31 for such synthetic instructions.