41 MCODE - Floating FIX Mode (Fix ALL) - Printable Version +- HP Forums (https://www.hpmuseum.org/forum) +-- Forum: HP Software Libraries (/forum-10.html) +--- Forum: HP-41C Software Library (/forum-11.html) +--- Thread: 41 MCODE - Floating FIX Mode (Fix ALL) (/thread-3099.html) |
41 MCODE - Floating FIX Mode (Fix ALL) - Ángel Martin - 02-15-2015 01:59 PM Floating FIX Mode As discussed in a forum thread, it's often valuable to see the maximum number of digits with a meaningful contribution to the result value. The idea for the 41 was to use the I/O_SVC interrupt polling point to adjust the FIX setting in a dynamic fashion, depending on the value stored in the stack register X. Some folks call this a FIX ALL mode, but I favor the Floating FIX terminology - after all a fix ALL would always be a static FIX_9, for it isn't about ALL digits but ALL NEEDED ones. Bur semantics aside, the code below shows the core of the routine, i.e. the actual determination of the FIX settings. The formulas used are as follows: Let x be represented by the following convention used in the 41 platform, with one digit for the mantissa sign, 10 digits for the mantissa, one for the exponent sign and two for the exponent. This enables a numeric range between +/-9,999999999 E99, with a "whole" around zero defined by the interval +/-1E-99. Then the fix setting to use is a function of the number in X , represented as follows: " s|abcdefghij|xyz " 1. If number >=1 (or x="0") let z# = number of mantissa digits equal to zero, starting from the most significant one (i.e. from PT= 3 to PT=12), and XP = value of exponent (yz). Then we have: FIX = max { 0 , [(9-z#) + XP } 2. if number < 1 (or x="9") let |XP| = 100 - xyz, and z# as defined above. Then we have: FIX = min { 9 , [(9-z#) + |XP| } And here is the code to be executed by the OS upon each qualifying I/O_SVC event: Code:
RE: 41 MCODE - Floating FIX Mode (Fix ALL) - Ángel Martin - 02-15-2015 04:09 PM (02-15-2015 02:29 PM)Geir Isene Wrote: Now where do I put the code and how to make the OS catch it? Ah, that's the secret sauce ;-) Stay tuned for a second part article... but in all likelihood you wouldn't want to re-reinvent this wheel so use the SandMath 4x4 instead. RE: 41 MCODE - Floating FIX Mode (Fix ALL) - Ángel Martin - 02-15-2015 06:38 PM (02-15-2015 05:16 PM)Geir Isene Wrote:(02-15-2015 04:09 PM)Ángel Martin Wrote: Ah, that's the secret sauce ;-) Stay tuned for a second part article... but in all likelihood you wouldn't want to re-reinvent this wheel so use the SandMath 4x4 instead. Page#4 does not have interrupts - sorry not a chance. Perhaps the AMC_OS/X but that'd mean serious surgery and complete rewrite of many sections - too much effort for something it's already done. Also the RCL math needs the five additional functions... and it's all connected.- See the next post. RE: 41 MCODE - Floating FIX Mode (Fix ALL) - Ángel Martin - 02-15-2015 06:42 PM Implementation Details – a MCODE digression. Taking advantage of the I/O_SVC Interrupt is not easy to implement, even if conceptually simple. For starters, one needs to keep in mind that the event is triggered after the operations have occurred – thus is not to be mistaken with a code break during the execution. Then there is also the fact that a constant polling of the I/O_SVC will introduce noticeable overhead on the system performance, thus one needs to carefully choose the instances and scenarios where the supplemental code is to be run. Doing it too often will cause annoying delays, but missing some will result in an inconsistent or incomplete implementation of the added functionality. To make it more complicated, this technique is also used by other modules that the implementation here needs to be compatible with. Not an easy task; you probably know that the ZENROM and the CCD Module are not compatible, and that the AECROM takes over all the attention to maintain the results in the chosen unit (Foot, meters, inch fractions). The criteria followed by the SandMath is full compatibility with the AMC_OS/X and CCD-style modules, regardless of the order they are plugged in the machine. That’s why the criteria needs to go to lower-level conditions (like pending addresses in the RTN stack and keycodes for the pressed keys) instead og more general events, like parsing OS routines. Here’s the conditional tree used to qualify I/O events into triggering points in the SandMath. General conditions: 1. Is Alpha ON? - Ignore if true. 2. Is the 1st. RTN address from the OS ROM_0 / ROM_1? - Ignore if False. Conditions for the Floating FIX mode: 3. Is the message flag ON? - Ignore if true. 4. Is the 1st. RTN address = 00F0 [NFRPU], or 0CCA [STO], or 10DA [AJ]? - Ignore if False Conditions for the RCL Math and Prompt Lengtheners 5. Is the 1st. RTN adr = 0CDE [PAR110]? - Mid term of a 2-digit prompt when True a. Further check on keycode to exclude XEQ, replace it otherwise. 6. Is the 1st. RTN adr = 0D22 [PARA05]? – Mid term of a 1-digit prompt when True a. Further check on keycode to exclude CAT, replace it otherwise 7. Is the 1st. RTN adr = 0DC4 [IND20] ? IND prompt situation when True a. Is the 2nd. RTN adr = 122E [RCL]? – Replace the first adr when True (IND 1_ _ ) Say what?, Not a Fool-Proof result ! One last word about the expected results:- This is a good example of the additional difficulty arising from the afterthought nature of a task that would be basically simple had it been done integrated into the OS. Coming from behind the OS to supplement/complement its doings is not the best way to implement this functionality, which ideally belongs to the OS displaying routines instead. Thus you’ll find some instances when the Floating FIX mode won’t kick in, like using STO and then numeric keys (but note that it does work using the top-two rows, A-J). I have tested the outcome of all functions within the SandMath, modifying some of them to make sure that they provide the triggering conditions for the Floating mode to operate. With other modules the implementation may have some glitches, depending on how their functions were written. There is currently a limitation for some functions when you execute them using the LASTFunction method, so be aware of that as well. |