HP41 and MCODE XKD instructions in program mode

[hth]

XKD, or Execute Key Direct, is a feature of the HP41. Keys like R/S, SST and uses this to perform their actions immediately without going through the NULL test.

What is interesting is the routine NAME4E in QUAD 3. It inspects MCODE instructions for their execute direct status and this is what happens.

First it checks if we are in run mode, then it goes to normal NULL test, key debounce and execution. If we are in program mode, it reads the first instruction to see if it is a NOP, then it is a non-programmable operation and it is to be executed, not inserted in program. What happens next is interesting, it reads the following instruction and checks if that is also a NOP. If it is, then the instruction is XKD, and it will immediately go and execute it (no NULL test).

So, in program mode, a single NOP gives a non-programmable XROM instruction, two NOPs is a non-programmable, execute direct instruction. Meaning it will execute on key down, but only in program mode. Outside program mode, it will do a NULL test first.

What were they thinking here?

I have no idea, obviously it is possible to have instructions that can be assigned to keys and have behavior similar to SST, execute immediately. I kind of wonder if it should not also have been like this in run mode.

Has this feature ever been used by some MCODE instruction?

[Ángel Martin]

(07-26-2016 03:49 AM)hth Wrote:  ......
Has this feature ever been used by some MCODE instruction?

Yes, I've seen that in a couple of functions from the NFCROM and others, where the documentation states its immediate execution character. But I didn't expect this not to be the case in RUN mode, which to me defeats the purpose of the setting.

Is that tested checking F13 only or both F13 and F4?

Edited: I just tried with functions SST^ and BST^ from the TOOLBOX module.

If you execute them in PROGRAM MODE (but non in a running program) they are executed non-stop, i.e. no return to the OS upon completion.

What I'm not sure is whether this is due to the dual NOP at the beginning, or due to the final call to [DFRST8]...
probably both?

[hth]

(07-26-2016 08:26 AM)Ángel Martin Wrote:  

(07-26-2016 03:49 AM)hth Wrote:  ......
Has this feature ever been used by some MCODE instruction?

Yes, I've seen that in a couple of functions from the NFCROM and others, where the documentation states its immediate execution character. But I didn't expect this not to be the case in RUN mode, which to me defeats the purpose of the setting.

Is that tested checking F13 only or both F13 and F4?

It has nothing to do with if your program is running or not. If you are in program edit mode (entering programs), the XKD test is right after the test for if the instruction is programmable (the first NOP). If it has a double NOP, it will GOTOC to the second of them (the intention being that it should happen immediately, like SST or RCL).

Outside program mode (the mode where we do normal calculations), this test is not done, so the XKD feature does not work. Instead you get the usual NULL test.

A small curiosity is that NFRPU is pushed on the stack after the NULL test, so a non-programmable XKD instruction will execute without NFRPU on the stack and cannot return using an RTN instruction, it must jump back.

To me, it looks like a nice feature that was not fully completed. It really should be XKD also outside program edit mode.

[Ángel Martin]

(07-26-2016 05:06 PM)hth Wrote:  To me, it looks like a nice feature that was not fully completed. It really should be XKD also outside program edit mode.

So what could have been done with it, if the functionality was also available in RUN mode?
Entering multiple letters without releasing the keys, but this is exactly what debounce avoids so it'll be tricky to have those two active simultaneously.

[hth]

(07-26-2016 06:16 PM)Ángel Martin Wrote:  So what could have been done with it, if the functionality was also available in RUN mode?
Entering multiple letters without releasing the keys, but this is exactly what debounce avoids so it'll be tricky to have those two active simultaneously.

I think it would make it easier to implement an instruction that when assigned to a key act like any other prompting instruction, but with its own custom prompting layout. You are probably more experienced on this than me...