[HP41] mcode question polling point entries

[MeindertKuipers]

Hi mcode guru's,

I am struggling with some mcode using the HP41 polling entries, and I am probably messing up some registers. Is there any definition which CPU registers can be freely used and which must be restored during any of these polling entries?

[Monte Dalrymple]

(03-22-2023 04:09 PM)MeindertKuipers Wrote:  Hi mcode guru's,

I am struggling with some mcode using the HP41 polling entries, and I am probably messing up some registers. Is there any definition which CPU registers can be freely used and which must be restored during any of these polling entries?

From the comments in the HP-41 OS listing: Plug-in ROMs must preserve C[10:3] and return to RMCK10 with hex mode, P selected, Status Set 0 up, and chip 0 selected.

So, everything else is fair game, including subroutine levels. But if you're using the I/O service entry (FF8) in some case no subroutine levels are available. That's the only restriction that I sometimes forget about.

Monte

[Ángel Martin]

(03-22-2023 04:09 PM)MeindertKuipers Wrote:  Hi mcode guru's,

I am struggling with some mcode using the HP41 polling entries, and I am probably messing up some registers. Is there any definition which CPU registers can be freely used and which must be restored during any of these polling entries?

There's a set of "rules" listed in Ken Emery's book, see the Appendix D, page #151 to #153

1. Restore nybbles 10 through 3 of register C to what they were when you took control at the interrupt
2. Have P as the selected pointer
3. Load flags 48 to 55 of the user flags register into CPU register ST. This set of flags is called status set zero (SS0)
4. Have Chip 0 (the status registers) selected
5. The CPU must be in HEX mode
6. You must do a GOTO to 27F3 to end the interrupt and give control back to the calculator so that it may continue polling.

[MeindertKuipers]

Happy then that Ángel is involved here. I am using the N-register for temporary storage, and all works quite fine. The only thing that does not work as soon as I change N (in a page that is below OS/X) is the operation of Ángels OS/X, most notably I do not the get quote prompt when doing a CAT. I think this behavior is not uncommon, as the 41CL Extreme Functiosn also mess with OS/X when it is in a lower page.
I have no option to put my target in a page higher than OS/X, as this is about my modified printer ROM, which must be in Page 6, and I hate to be without OS/X ...

[MeindertKuipers]

(03-22-2023 05:13 PM)Monte Dalrymple Wrote:  

(03-22-2023 04:09 PM)MeindertKuipers Wrote:  Hi mcode guru's,

I am struggling with some mcode using the HP41 polling entries, and I am probably messing up some registers. Is there any definition which CPU registers can be freely used and which must be restored during any of these polling entries?

From the comments in the HP-41 OS listing: Plug-in ROMs must preserve C[10:3] and return to RMCK10 with hex mode, P selected, Status Set 0 up, and chip 0 selected.

So, everything else is fair game, including subroutine levels. But if you're using the I/O service entry (FF8) in some case no subroutine levels are available. That's the only restriction that I sometimes forget about.

Monte

I do not think the subroutine levels are an issue. I am patching the PRINTER ROM, and that uses at least 2 levels in the xFF8 entry. And for my application it is not an issue at all, no additional subroutines planned

[MeindertKuipers]

Getting a bit closer now.
According to the VASM listings:

Quote:** all subroutine levels are available except in I/O service entry.
** if PKSEQ is set then I/O service routines must either preserve three subroutine
** returns on the subroutine stack or else terminate the partial key sequence.

And with the quoted CAT from OS/X I guess we are in PKSEQ. But my code does not use any extra subroutines, and without using N my code works with OS/X. The moment I change N the PSEQ is disrupted, but I still have to find out how N is used and what to do about it.
Use of any other register is out of the question, these are all in use unfortunately ...

[Ángel Martin]

(03-23-2023 04:07 PM)MeindertKuipers Wrote:  Getting a bit closer now.
According to the VASM listings:

Quote:** all subroutine levels are available except in I/O service entry.
** if PKSEQ is set then I/O service routines must either preserve three subroutine
** returns on the subroutine stack or else terminate the partial key sequence.

And with the quoted CAT from OS/X I guess we are in PKSEQ. But my code does not use any extra subroutines, and without using N my code works with OS/X. The moment I change N the PSEQ is disrupted, but I still have to find out how N is used and what to do about it.
Use of any other register is out of the question, these are all in use unfortunately ...

Hmmm... I'm not aware of any register restriction in the I/O polling point - at least not in general. However there may be something else at play here if the routines use registers with system data information. If the previous module alters the system data (in its I/O polling chance) then the following module will not have the expected contents.

I suspect that in the OS/X case there is some of that going on but I should review the code again. BTW you can try with the original CCD Module and see if it shows the same issue (I bet it does, since the OS/X uses the same code for this).

I'll report what I find out, it's not the easiest piece of code (very complex indeed) and I never got the source code so will take a little effort.

PS. As far as the YFNX case plugged in a lower page than the OS/X - I believe Monte figured out the reason why that happens. I don't remember the details but I don't recall that registers were involved...

[Ángel Martin]

(03-24-2023 07:18 AM)Ángel Martin Wrote:  I'll report what I find out, it's not the easiest piece of code (very complex indeed) and I never got the source code so will take a little effort.

PS. As far as the YFNX case plugged in a lower page than the OS/X - I believe Monte figured out the reason why that happens. I don't remember the details but I don't recall that registers were involved...

At first glance I don't see any utilization of the N register in the OS/X I/O polling point code.
Unfortunately tracing the MCODE execution n auxiliary banks is not working anymore on V41 R9I, so I cannot check the complete code segments though.

I was looking in my YFNX files for Monte's comments on the I/O issue but could not locate them either, hopefully he'll see this thread and chime in - it may have some clues to investigate your issue with this ROM

[MeindertKuipers]

(03-24-2023 07:18 AM)Ángel Martin Wrote:  

(03-23-2023 04:07 PM)MeindertKuipers Wrote:  Getting a bit closer now.
According to the VASM listings:

And with the quoted CAT from OS/X I guess we are in PKSEQ. But my code does not use any extra subroutines, and without using N my code works with OS/X. The moment I change N the PSEQ is disrupted, but I still have to find out how N is used and what to do about it.
Use of any other register is out of the question, these are all in use unfortunately ...

Hmmm... I'm not aware of any register restriction in the I/O polling point - at least not in general. However there may be something else at play here if the routines use registers with system data information. If the previous module alters the system data (in its I/O polling chance) then the following module will not have the expected contents.

I suspect that in the OS/X case there is some of that going on but I should review the code again. BTW you can try with the original CCD Module and see if it shows the same issue (I bet it does, since the OS/X uses the same code for this).

I'll report what I find out, it's not the easiest piece of code (very complex indeed) and I never got the source code so will take a little effort.

PS. As far as the YFNX case plugged in a lower page than the OS/X - I believe Monte figured out the reason why that happens. I don't remember the details but I don't recall that registers were involved...

I will do some testing with the original CCD later. So far I have been looking in the VASM listings, and only found a hint of using N at label PAR005 (at address 0C24). This is in the Key Parsing section, but this is really complicated indeed.
So far I am out of trouble. After fixing something else I simply removed the IO Service entry from the ROM, and so far everything still works without any problems (yet).

[MeindertKuipers]

(03-24-2023 09:46 AM)MeindertKuipers Wrote:  

(03-24-2023 07:18 AM)Ángel Martin Wrote:  Hmmm... I'm not aware of any register restriction in the I/O polling point - at least not in general. However there may be something else at play here if the routines use registers with system data information. If the previous module alters the system data (in its I/O polling chance) then the following module will not have the expected contents.

I suspect that in the OS/X case there is some of that going on but I should review the code again. BTW you can try with the original CCD Module and see if it shows the same issue (I bet it does, since the OS/X uses the same code for this).

I'll report what I find out, it's not the easiest piece of code (very complex indeed) and I never got the source code so will take a little effort.

PS. As far as the YFNX case plugged in a lower page than the OS/X - I believe Monte figured out the reason why that happens. I don't remember the details but I don't recall that registers were involved...

I will do some testing with the original CCD later. So far I have been looking in the VASM listings, and only found a hint of using N at label PAR005 (at address 0C24). This is in the Key Parsing section, but this is really complicated indeed.
So far I am out of trouble. After fixing something else I simply removed the IO Service entry from the ROM, and so far everything still works without any problems (yet).

Confirmed, same behavior with the original CCD ROM (in the HP41CL)

[Ángel Martin]

(03-24-2023 11:58 AM)MeindertKuipers Wrote:  Confirmed, same behavior with the original CCD ROM (in the HP41CL)

Sorry I can't find any clear reason for what you're experiencing.

Indeed the RTN address is relevant to the OS/X I/O_flag code, as it is the way to determine which native function has been executed prior to the partial_data_entry halt. So if your ROM alters the RTN stack then the OS/X will miss the chance to act upon the triggering event...

but this has nothing to do with the N register, or with any other register except the RTN address stack (i.e. if used PUSHADR, POPADR); however you're reporting that the issue appears only if you use N, right?

The obvious question is: can you use other register instead of N to avoid the problem?

[MeindertKuipers]

(03-26-2023 04:43 PM)Ángel Martin Wrote:  

(03-24-2023 11:58 AM)MeindertKuipers Wrote:  Confirmed, same behavior with the original CCD ROM (in the HP41CL)

Sorry I can't find any clear reason for what you're experiencing.

Indeed the RTN address is relevant to the OS/X I/O_flag code, as it is the way to determine which native function has been executed prior to the partial_data_entry halt. So if your ROM alters the RTN stack then the OS/X will miss the chance to act upon the triggering event...

but this has nothing to do with the N register, or with any other register except the RTN address stack (i.e. if used PUSHADR, POPADR); however you're reporting that the issue appears only if you use N, right?

The obvious question is: can you use other register instead of N to avoid the problem?

I suspect that the use of N is somewhere in de HP41 code. I will try to setup a simplified test to find out.
And I have no alternative register that I can use, for now removing the entry at xFF8 resolves the issue, and the ROM does not seem to need it anyway. This is a patch for the PRINTER 1E ROM, and the entry checks for the keys on the printer. Since we have an emulated printer we have no keys, and no need to check these.

[MeindertKuipers]

I have just created the simplest of all entry routines, accessed from xFF8 (IO Service):

Version 1:
NOP
?NC GO RMCK15 (27F4)

Version2:
N=C
?NC GO ROMCK15 (27F4)

The ROM sits in a lower page than Ángels OS/X. Version 1 leaves the double quoted CAT intact, version 2 falls back to the normal CAT.

I did a trace with V41 doing a CAT" 0 G, and found that in the OS/X ROM (in Page 9) entry xFF* does a relative long goto to 9892, runs through some other code an finally, at 98E0 does C=N and seems to check a value originating from N.
Doing a search backward in the trace for a N=C instruction shows this at 0C24, right in the partial key sequence code, long before going into the polling loop.

Without looking at the HP41 ROM in detail I suspect that upon doing the IO service polling the HP41 system puts a key value in N to be used by the entry in the ROM. When this value is changed by another polling point before the ROM really using it things go wrong.

This again shows how clever the HP41 system ROMS were written, and one can only wonder if all this stuff was ever really documented internally at HP. And many thanks for the tracing function in V41!

[MeindertKuipers]

In hindsight, we could have known this all. When writing HP41 mcode I usually have the HP41CX Programming Handbook open, and take a look at page 16 (in the attachment). So this info was very close to me all the time (.. sigh ..). It cleary says the logical keycode is in nybble 1 and 2 of N. Now maybe find a way to save just these two nybbles.

[Ángel Martin]

(03-28-2023 02:34 PM)MeindertKuipers Wrote:  In hindsight, we could have known this all. When writing HP41 mcode I usually have the HP41CX Programming Handbook open, and take a look at page 16 (in the attachment). So this info was very close to me all the time (.. sigh ..). It cleary says the logical keycode is in nybble 1 and 2 of N. Now maybe find a way to save just these two nybbles.

I agree Poul Kaarup's manual is an excellent reference for MCODE as well.
The use of N for the logical keycode was always clear, the question was whether this information was used. I was trying to find where exactly in the OS/X I/O poll code the N register was read, but did not succeed - but it's quite logical to assume there's some usage somewhere given the impact it has when modifying it.