09-01-2019, 03:35 AM
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):
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