From the ease of use this is great, and it follows the standards set by HP with their extension modules, like the X-Functions. It needs the X register and the Alpha registers to hold the data input parameters, perhaps the only drawback.
It´s also more RPN-like that the prompting - I remember some arguments against prompting functions used when the 48SX first came out; like using SF 00 vs. 0, XEQ "SF".
Prompting functions however are more intuitive and friendlier, you don´t need to remember the input sequence - which it´s suggested by the function itself.
Alpha prompting for ROM-based functions is a bit of a tricky issue. In RUN mode it all works dandy, but in a program things get hairy. Consider that HP never implemented this in plug-in ROMS, like the X-Functions; but rather they used the ALPHA register to hold the arguments of the functions instead. Think of PASN for instance, very different from ASN.
There are a few ways around this, as follows - in order of complexity and smoothness of the integration with the OS:
1. Get two functions to do the task, one in RUN mode (prompting, non-programmable) and another in program mode (takes inputs from X/Alpha). This is the ASN vs. PASN approach. The prompting function follows the standard conventions using the prompting bits in the function name, very well documented and trivial to implement. No extra coding is required at all for numeric prompts; little code snippets are needed to handle HEX inputs (like using A,B,C...F for the pages as opposed to 10, 12, ..15)
2. Use just one function, but behaving differently depending on which mode it´s being used in. This is checked using the CPU flags 4 and 13, so a couple of tests at the very beginning of the function code will fork to either mode. This can be done in a subroutine, common to many functions in the ROM. Drawback is the blank prompt in PRGM mode that must be input but is not taken in. The parameters are still taken from the stack (X) and/or ALPHA.
3. Implement the non-merged scheme whereby in a program the arguments are taken from the next program line. Examples of this abound in the 41Z and the SandMath (for instance RCL+ 12, or ZRCL 05). The simple version of this requires adding the argument line manually by the user. Same drawback as before with the blank input.
4. A refinement of the above - whereby the argument line is automatically placed in the program by the function itself. This is the HEPAX model, also used in the PowerCL and the SandMath. No drawbacks to speak of (except a corner case when doing SST execution in-between both lines) but it requires quite a lot of code, so it´s probably out of the question.
So in summary:
- if there are enough FAT entries available then #1 above is a safe and sound approach, by far the simplest.
- #2 is also easy and halves the number of FAT entries required.
- #3 is nicer and a very good compromise, as the extra code required is small and independent.
- #4 is tough. Extensive use of the [NEXTxx] routines is required (partial key sequence), and lots of trickery to bypass the OS design limitations.
A long rant but hopefully it helps.
Best,
ÁM
Edited: 4 June 2013, 2:08 a.m.