modules with duplicate labels (Aviation and Navigation)

[twdeckard]

Greetings,

what is the consequence of having two modules with duplicate labels? Example the *T function shared between the Aviation and Navigation pacs. Assuming I don't want to call the function using its mnemonic and the XROM numbers don't conflict is there any other side effect to having both plugged in. Any issue with which port # you choose for each?

Regards
Todd

[Sylvain Cote]

Hello Todd,

When both modules are plugging in, the 41 will
always choose the label of the lowest port number.

One way to solve this, is to ...
01) power off the calculator
02) remove the aviation module if present and insert the navigation module
03) power on the calculator
04) ASN "*T" to eˆx -> XROM 14,34 to key -15 (or to any other key)
05) power off the calculator
06) remove the navigation module and insert the aviation module
07) power on the calculator
08) ASN "*T" to 10ˆx -> XROM 19,21 to key -14 (or to any other key)
09) power off the calculator
10) insert both modules
11) power on the calculator
12) activate USER MODE
now you can execute both labels any time you want through those two keys.

There are also several other ways to do this with synthetic programming, PPC ROM, CCD, a small program, etc.

Sylvain

[twdeckard]

Is there any way to determine the calling address in a subroutine? Peek at the return stack?

I could write a *T routine in user memory to execute the correct xrom function if I could infer which ROM made the call?

Todd

[Sylvain Cote]

Hello Todd,
I am not sure I understand your questions.
Well, not really, I actually understand yours questions, it's just that I am not sure where you want to go with this.
Could you explain what you are trying to do with more details so I can give the good answer(s).
Best regards,
Sylvain

[Ángel Martin]

(05-27-2014 03:48 AM)twdeckard Wrote:  Is there any way to determine the calling address in a subroutine? Peek at the return stack?

I could write a *T routine in user memory to execute the correct xrom function if I could infer which ROM made the call?

Todd

You can find out the address but that's not going to be of much help if it is a MCODE routine (cannot copy it in RAM). If it's a FOCAL program you can always COPY it - no need to know its address for that.

I think Sylvain's procedure described above really is the most practical approach to deal with your request.

[twdeckard]

Greetings, thank you all for the quick replies.

My question was based on a flawed assumption and I retract it (I think).

It was my belief that if two modules contained duplicate alpha labels for utility subroutines then executing a parent function from the ROM in the higher number port would incorrectly call the subroutine from the lower number port.

I was intending to overload the subroutine in question with one I wrote. In homage to the Apple Lisa, I would execute different operations based on the calling address and disambiguate the conflict.

However, it appears the modules address their subroutines with explicit XROM calls so I do not need to worry execution inadvertently jumps from one ROM to another?

Todd

[Sylvain Cote]

Hello Todd,

As long as you do not plug 2 modules with the same XROM ID (1..31) you will never have problems.

Simplified, when an FOCAL application is moved from RAM to ROM, all global labels become an entry
into the module FAT (1..64 entries) and all globals XEQ are converted into XROM (ID:ENTRY).

After that the label string is not important anymore because the XEQ "ABC" has been converted to XROM ID:ENTRY.

Matthias Wehrli has compiled an extensive list of modules created for the HP-41 with their XROM ID's.
link: http://www.hp-collection.org/Modulliste.pdf

Best regards,

Sylvain

[rprosperi]

(05-28-2014 02:58 AM)twdeckard Wrote:  ...I would execute different operations based on the calling address and disambiguate the conflict.

Todd

Awesome phrase! Gotta find a way to use that this week...