HP-41 instruction print bug found

[hth]

(11-05-2019 06:09 AM)Ángel Martin Wrote:  I've followed this discussion with interest, and if I understand well at the crux of it is the inability by the OS to handle some corner cases of prompting functions in plug-in ROMS, is that correct?

We know those are not supposed to be supported (HP dixit) , but I also use them profusely in my advanced modules, including the IND case, and have never encounter any glitches (ok, the printer case I have no experience with, I rarely use a printer in my system anyway).

For example in the WARP_Core module there are a dozen or so of functions used to access register's contents replacing the native RCL/STO. They can happily handle IND and IND ST, and that for all status registers as well.

You're right this is not done using the internal OS routines, which were not designed to do that (regardless of their apparent ability using the function's name characters to make them prompting) - and that's why the module handles all the prompting in dedicated subroutines (some stubs also in the Library#4 BTW), not using calls to the OS.

The upside is that the same prompting handling routines work for sub-functions as well not only for the main FAT, and that's a big plus.

Yes, all these problems comes from that built-in instructions are one byte with a second postfix byte for the register/numeric operand. This is not true for XROMs as they are two bytes and have to deal with the postfix operand on the side. Sometimes it will just execute code that was made for the one byte prefix and just do the wrong thing.

Prompting XROMs are limited by design. HP did not explore this feature so much. Alpha prompting PRP comes to my mind, and it would in retrospect have been better to take the input from the alpha register. That would have cost more code and time rather than just use the existing alpha prompt feature. The printer was written early, the Extended Functions module came out later with such code.

What I am working on is an extensible CAT function (as an XROM). It is not programmable, so it was easy to use the existing prompt functionality. When I fixed "CAT IND" I also tried "CAT IND L" and got NONEXISTENT. At that point I investigated it a bit further and found that it had put the postfix in the instruction and tried to do an XROM lookup of that malformed instruction. I then found the note in 'MCODE for beginners' about this and also remember running into this in the mid eighties when I experimented with prompting XROMs.

It is correct that you can get around it by doing your own prompt handling, but it feels a bit overkill for this situation. For the other prompting XROMs (programmable), I use a different technique. Maybe I should just switch to use that one instead, and perhaps make CAT programmable.