HP-41CX w/ XF-Module - just curious

[Sylvain Cote]

(07-26-2019 01:23 PM)Ángel Martin Wrote:  Somehow the external one prevails over the built-in counterpart...

That is what I was trying to resolve.

(07-26-2019 01:23 PM)Ángel Martin Wrote:  BTW this may also be taken advantage of by the CL, which comes with the Time ROM loaded but there's no TIME circuitry:
when you plug an external physical TIME module to it that's the one that gets the deal, so to speak.
Not sure it's the same mechanism but it'd make sense...

The CL CX TIME vs TIME plug-in modules does not behave like a standard 41, the CX TIME functions are still available when a TIME plug-in module is inserted.

Sylvain

[Monte Dalrymple]

(07-26-2019 01:23 PM)Ángel Martin Wrote:  BTW this may also be taken advantage of by the CL, which comes with the Time ROM loaded but there's no TIME circuitry: when you plug an external physical TIME module to it that's the one that gets the deal, so to speak. Not sure it's the same mechanism but it'd make sense...

ÁM

In the CL page 5 accesses never appear on the external bus. The hardware knows that page 5 is internal, so the address is modified before going to the bus driver. This is what prevents bus conflicts with an inserted Time Module. The ROM in the Time Module itself is never accessed, only the peripheral registers are.

[hth]

(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.

[Sylvain Cote]

(07-26-2019 06:32 PM)hth Wrote:  Here is the relevant code for the curious MCODErs:

Great investigation Håkan, it explains the observed behaviour and goes well beyond.

(07-26-2019 04:36 AM)Ángel Martin Wrote:  It's all in the MCODE ;-)

(07-26-2019 06:32 PM)hth Wrote:  And yes, you are right, it is all in the MCODE.

I agree that it is all in the MCODE.

Thank you Robert, Ángel, Håkan & Monte for discovering and documenting this behaviour/bug.

Sylvain

[Ángel Martin]

(07-26-2019 03:23 PM)Monte Dalrymple Wrote:  In the CL page 5 accesses never appear on the external bus. The hardware knows that page 5 is internal, so the address is modified before going to the bus driver. This is what prevents bus conflicts with an inserted Time Module. The ROM in the Time Module itself is never accessed, only the peripheral registers are.

Good design indeed!

[rprosperi]

Well, long ago it would have been quite exciting to find a new 41CX bug, but at this stage it's likely to be of interest to only about a dozen users, LOL.

Maybe I should report the bug to HP to see if they will fix it...

Thank you to all that helped explore and explain it, and to JurgenRo for asking the question that led to this short trip down the rabbit hole.

[hth]

(07-27-2019 01:44 PM)rprosperi Wrote:  Well, long ago it would have been quite exciting to find a new 41CX bug, but at this stage it's likely to be of interest to only about a dozen users, LOL.

Maybe I should report the bug to HP to see if they will fix it...

I have already fixed it.

If you talk to HP, you can let them know they can have the fix for free. While you are at it, please also ask if they are going to open source the HP-41 firmware.

[Ángel Martin]

(07-26-2019 06:32 PM)hth Wrote:  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?

Well I'd argue that's not necessarily a bug but an implementation choice: what's the point of continuing the search for another ROM with the same XROM id#; just for the "excess" functions in the second instance of that ROM? I would have done the same and save a few bytes in the OS.

ÁM

[hth]

(07-28-2019 04:27 AM)Ángel Martin Wrote:  

(07-26-2019 06:32 PM)hth Wrote:  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?

Well I'd argue that's not necessarily a bug but an implementation choice: what's the point of continuing the search for another ROM with the same XROM id#; just for the "excess" functions in the second instance of that ROM? I would have done the same and save a few bytes in the OS.

ÁM

Yes, by design. However, you spelled the name and if you hold down ALPHA at the end the instruction, what you spelled is even displayed (acknowledged) and when you let go of ALPHA it goes ahead and does something else!

In program mode you will see the other instruction as the program step and if you assign it to a key you sort of put it there for the future and have the chance to see it does something else (if you press and hold).

When executed directly you have no chance to see it will do anything but what you entered, there is no mercy.

I have not investigated what it would be take to fix it, but I did put it down for the future. It is not a high priority and it needs to be a rather trivial and safe fix, otherwise I will leave it as is.

[hth]

Just one further comment on this GTRMAD bug.

The bug mentioned in "Extend your HP-41" on page 633, which talks about some XROM nn,25 being turned into INSREC is just one example of how this GTRMAD bug can strike. If you execute XROM nn,25 and the plugged in module with identity nn has fewer than 25 instructions, GTRMAD will after visiting the nn module switch to looking for XROM 25,25 and that is INSREC, which will always be found on an HP-41CX as it is one the last page searched (page 3).

[Ángel Martin]

(08-11-2019 11:07 PM)hth Wrote:  If you execute XROM nn,25 and the plugged in module with identity nn has fewer than 25 instructions, GTRMAD will after visiting the nn module switch to looking for XROM 25,25 and that is INSREC, which will always be found on an HP-41CX as it is one the last page searched

Very true, but again it's very unlikely that another ROM with id#25 AND fewer functions than the CX/X-Functs is present, right?
If it were, the user wouldn't have access to any of the X-Functs above that number, which is more dramatic perhaps.

So I'd call this a "benign bug: the OS doesn't find your target and then offers you a "consolation prize" ;-D

[hth]

There are quite a lot of discussions about this bug in "Extend your HP-41" on page 633-634. The most common way according to the book is to use the FMT (XROM 29,25) in the HP-IL module, then later use the HP82143A printer instead and this turns the FMT into INSREC.

There is further discussion on page 637-638. "This could be quite dangerous; it is entirely possible that a CX user will get a program from someone who has an IL printer, and will try to run it with an old printer. A novice would certainly not expect their Extended Memory to be altered by this."

I had not made the connection before about this INSREC issue on the HP-41CX. Now it all fell into place (I am not that quick to grasp matters and I never owned any printer). In any case, I do not think the root cause of this problem was properly understood before, but maybe it is somewhere deep in these old calculator journals?

[hth]

(07-28-2019 06:04 AM)hth Wrote:  Yes, by design. However, you spelled the name and if you hold down ALPHA at the end the instruction, what you spelled is even displayed (acknowledged) and when you let go of ALPHA it goes ahead and does something else!

In program mode you will see the other instruction as the program step and if you assign it to a key you sort of put it there for the future and have the chance to see it does something else (if you press and hold).

When executed directly you have no chance to see it will do anything but what you entered, there is no mercy.

I have not investigated what it would be take to fix it, but I did put it down for the future. It is not a high priority and it needs to be a rather trivial and safe fix, otherwise I will leave it as is.

I have now had the chance to study it a bit more and think I will leave it as-is. Fixing it looks non-trivial and would probably end up being a kludge.

[floppy]

What would be the interaction with a Nov64d/ClonixD setup or influence of it? (I try to identify the rules and facts and/or interactions between Nov64d setup and presence of other modules):
A) CV: an X-function and X-Memory (or double-X-memory) can be recognized as full memory size only if the Nov64d kept 2 (or 3) pages are identified as free from page 8 on? (the MCODE will scan and make the free page busy if found; whatever low or high; not contiguous?)
B) CX: X-Memory (or double-X-memory) can be recognized as full memory size only if the Nov64d kept 1 (or 2) pages free from page 8 on?
Any hint is welcome.

[Sylvain Cote]

Register type memory (Status, Main & Extended, 56-bit registers) is accessed like a peripheral and thus not mapped into the 64K address space.
Mapping for 56-bit register based memory:

• Inside the HP-41, P.18
• Memory Maps Article
• HP-41 - Memory modules thread
  

RAMBox, HePaX, MLDL, NoV, etc. units/modules simulate 10-bit word ROMs with either EPROM/Flash and/or RAM (aka QROM), these devices memory are mapped to the 64K address space.
Mapping for 10-bit word based memory:

• Inside the HP-41, P.28 to 33
• Clonix & NoV HPCC 2020 Presentation, P.12
  

Edit:
Some of Diego modules can simulate Extended Memory, but when doing it you lose all the other functionalities.
So, yes, with that configuration you are conflicting with X-Memory modules.
Otherwise, Clonix & NoV modules are simulating 10-bit word memory thus never conflicting with register based memory type.