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). 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.
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 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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)