Post Reply 
HP-41CX w/ XF-Module - just curious
07-26-2019, 06:32 PM (This post was last modified: 07-26-2019 08:27 PM by hth.)
Post: #23
RE: HP-41CX w/ XF-Module - just curious
(07-26-2019 04:36 AM)Ángel Martin Wrote:  So when you XEQ EMROOM, the OS finds the XROM #26 first corresponding to the external X-Funct module. It scans that FAT and notices that the id# in question is not there, so it puts out NONEXISTENT - without continuing the search along the BUS and threfore never reaching page #3 (the "last" one).

The same happens if you plug two different modules with the same XROM id#, and the first one has fewer functions than the second: only functions from the first one are found.

It's all in the MCODE ;-)

Cheers,
ÁM

Technically, that is not entirely correct. Internally it actually does keep looking down the line for matching modules and this EMROOM problem is a very interesting find, as it is a to me previously not (to me) known bug in the HP-41 mainframe (firmware).

After you press something like XEQ "EMROOM", the following happens.
  1. The internal ASRCH (alpha search) routine is used to locate EMROOM, which is found as it is a textual search. The code has no idea that it is part of the extended functions or that there are two of them.
  2. Once found, the EMROOM text goes to the display. It is checked if it is a prompting function, which it is not, so no arguments.
  3. Everything is fine so far and we have a complete instruction. Now we do the NULL test. You can confirm this by keep holding ALPHA key after entering XEQ "EMROOM", the calculator displays EMROOM and after a while NULL. The EMROOM function has been found (you will not see NONEXISTENT).
  4. Now we forget the address entry point of the instruction and prepare to execute it by its corresponding XROM i,j instruction.
  5. The calculator decodes the instruction, figures out that is an XROM and goes off to the XROM search routine that calls GTRMAD (get ROM address) to locate it.
  6. This function (also) scans from page 5 to f, and on a CX it ends by trying page 3.


At this point we should find the XROM (we know it is there) and execute it, but that is not what actually happens.

But first a little bit of recap about this GTRMAD and how it is supposed to work. It looks at the first address of a ROM page to see if it has an XROM ID match, then it checks that the function number is in range. If it is not in range, it will continue the ROM page scan to see if there is another module with the same ID, but with more functions that can provide the function we are looking for.

All ROM versions up to including GFF have a subtle bug here that was fixed in the final HFF version (and 41CX NFL ROM) by none other than Bill Wickes. It would do the function range test wrong and think the first function outside the table belongs to the current module (ouch!).

Now we get to the new bug. The scan takes place and the plugged in extended functions module is found with a matching XROM ID, but the function number is out of range. So we simply prepare to keep looking, but now we have trashed the XROM ID we are comparing to (extended functions ID in A.X) and it is not restored. The effect is that we keep looking for an XROM ID matching the function number. Thus, when we finally reach page 3, we compare the XROM ID to j (of XROM i,j) and they are not the same, so we think this is not the right module and the final result is NONEXISTENT.

Here is the relevant code for the curious MCODErs:
Code:
GTRMAD:       c=0     m
              [..]
              a=c     x             ; A.X _ ROM ID
              [..]
RMAD10:       cxisa                 ; read ID from one port
              ?a#c    x             ; is the ID a match ?
              gonc    RMAD20        ; yes
RMAD15:       c=c+1   pt            ; addr _ addr + hex 1000
              gonc    RMAD10        ; check another port
#if defined(HP41CX)
; * Extend search to page 3 for HP-41CX. Note that this pushes the RMAD20
; * label down one position, but we regain sync by removing the bug fix
; * nop a few lines down.
              golong  RMAD_PAGE3    ; search page 3 FAT
#else
              rtn                   ; ROM not plugged in
#endif
RMAD20:       c=c+1   m             ; point to 2nd word of ROM
              c=b     x             ; load the FC #
              a=c                   ; <-----  trashes A.X!!!!
              cxisa                 ; load # of FC's in the ROM
#if ! defined(HP41CX)
              nop                   ;  (deleted bug) 12/8/91 WCW
#endif
              ?a<c    x             ; is the FC in the ROM ?
              gonc    RMAD30        ; no, FC # too big
              [..]

RMAD30:       c=c-1   M             ; <-- fixes C.M, but not A.X!!!!
              legal
              goto    RMAD15

There is also another bug by design here. If we enter an instruction by name and have multiple ROMs with the same ID, it will execute the first one with a corresponding XROM i,j and that may be a different instruction from the one we entered (and found in the alpha search). I suspect this may be a known problem?

And yes, you are right, it is all in the MCODE.
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: HP-41CX w/ XF-Module - just curious - hth - 07-26-2019 06:32 PM



User(s) browsing this thread: 1 Guest(s)