MCODE: XKD another bug fixed

[hth]

I found and fixed another bug in the HP-41 firmware. The XKD feature is partially broken for XROMs.

XKD stands for eXecute Key Direct and is used by instructions such as R/S and SST. Such instructions are executed on key down, before showing its name and doing a NULL test when key is held. Looking at comments in the source, this feature was also intended to work for plug-in XROM instructions, but it turns out that it only works in program mode. In run mode the XKD ability is silently ignored and behaves as any other XROM instruction (with NULL test).

Apparently, no one has ever felt a need for having XKD for XROM as I do not think this has been discussed in the past.

For an XROM, XKD requires two NOPs as the first instructions at its entry point. The first NOP signals that the instruction is non-programmable, the second that it is XKD. This is also described in comments in the HP-41 firmware. But it does not work as the branch after testing for program mode skips the XKD test for the run mode case. The fix is trivial.

Why I need this you might wonder. Well, my semi-merged prompting XROM instructions used in Ladybug (LDI - load integer, SL - shift left and so on) are actually non-programmable XKD instructions. They take control immediately and provide the illusion that they are plain programmable prompting instructions, as such instructions are not supported by the HP-41.

So there we have it. Now these semi-merged prompting instructions no longer perform any NULL test in run mode if key is held, instead they immediately put up the prompt like all the built-in prompting instructions (both in run mode and program mode).

The changed source (just a changed branch destination):

Code:


              ?s3=1                 ; program mode?
              gonc    NAME4E        ; no    !!! WAS  NAME4F 
              cxisa
              ?c#0    x             ; programmable?
              gonc    NAME4E        ; no
              lc      3             ; set XROM bit(5)
                                    ; & insert bit(4)
              goto    NAME4G
; * For microcode FCNs in plug-in ROMs, if C(XADR)=0 then we look
; * at C(XADR+1) to determine whether the FCN should be executed on
; * key down.  If C(XADR+1)=0 then the FCN is XKD else the FCN is
; * a normal non-programmable function.
NAME4E:       c=c+1   m
              cxisa
              ?c#0    x             ; is C(XADR+1) non-zero?
              goc     NAME4F
              gotoc                 ; XKD FCN - go do it

NAME4F:       lc      2             ; set XROM bit(5) only

[Ángel Martin]

Neat finding and clever trick Håkan. Does this means that Ladybug could not require a page#4 aid if this patch was made to the OS?

[hth]

The page 4 trick is unfortunately still needed to maintain the changed keyboard and display behaviour in Ladybug, which is unrelated to semi-merged prompts and XKD.

The changed keyboard and display trick is really done by the I/O poll vector (and partial key sequence parsing), but unfortunately the HP-41 firmware skips calling the I/O poll vector when it is in the hurry, so the changed behaviour needs page 4 to make it reliable.

What this correction does is that if you press a semi-merged prompting function on the keyboard, the prompt now always come up, even if you keep the key pressed. Try the ordinary RCL key, press and hold. The prompt comes up immediately, no "NULL" or cancellation.

This bug causes the corresponding prompting semi-merged LDI instruction to only have that behavior in program mode. In run mode it will show "LDI" followed by "NULL". This bug fix makes it work in a consistent way, always immediate prompting no matter what mode the calculator is in.

I find it interesting that they thought of this, provided functionality for it and even commented on it, but unfortunately managed to screw it up slightly and no one ever seem to have noticed. I mean, this functionality can be used for other things, it just happened to be the perfect match for my stuff.

XKD is used by the built-in mode shifting keys, ordinary SHIFT, BST, SST and R/S instructions. This feature means that other special behaviours on key down can be implemented by XROMs, at least that was the thinking when the firmware was originally created.

[Ángel Martin]

(09-01-2019 08:01 PM)hth Wrote:  The changed keyboard and display trick is really done by the I/O poll vector (and partial key sequence parsing), but unfortunately the HP-41 firmware skips calling the I/O poll vector when it is in the hurry, so the changed behaviour needs page 4 to make it reliable.

That's quite something, I'd've thought the I/O_Standby event was infallible!
Also there's no I/O poll from page 4, so your solution really feels mysterious (as well as fantastic!) to me ;-)

[hth]

(09-06-2019 07:36 AM)Ángel Martin Wrote:  

(09-01-2019 08:01 PM)hth Wrote:  The changed keyboard and display trick is really done by the I/O poll vector (and partial key sequence parsing), but unfortunately the HP-41 firmware skips calling the I/O poll vector when it is in the hurry, so the changed behaviour needs page 4 to make it reliable.

That's quite something, I'd've thought the I/O_Standby event was infallible!
Also there's no I/O poll from page 4, so your solution really feels mysterious (as well as fantastic!) to me ;-)

I was also under that impression for many years, and that after studying the code and also trying it out for a while. But the venerable HP-41 managed to prove me wrong here.

After fixing it with the quick page 4 hack, it was stable for 2 years. Unfortunately, the HP-41 I use for this has now managed to become somewhat glitchy recently, even with this hack. I do not know what is going on with it now. I hope it is the Clonix module in some way, but I have not had time to investigate it yet.

Well, if I ever find some spare time I will probably go back to this and a more proper page 4 solution, but it is really a lot of work and there is just too little time at the moment.