WIP: 16C firmware hack for more memory

[brouhaha]

(01-28-2023 04:33 AM)brouhaha Wrote:  Since the divisor is a constant 14, this is done by multiplying by a fixed point approximation of the reciprocal of 14. There's some additional trickiness with efficiently getting a remainder of 0 to 13 out of the reciprocal multiplication, instead of a negative power of two, and I still don't really understand how they're doing that. It involves using 4688 as the approximation of 65536/14, rather than 4681, but there's more stuff going on after that which I haven't yet grasped.
...
Because of the extreme cleverness of HP's code, there's no obvious way to extend it to handling a larger input range. It's not a matter of just adding a few more digits to the reciprocal, or more loop iterations. (They aren't even using a loop.) I think the best solution is just to replace the reciprocal multiplication by a more conventional long division routine.

This was nagging at me, because the long division loop really can take significantly longer than HP's approach using the reciprocal. I've investigated it further. I still don't understand every line of code in HP's routine, but I decided to try writing my own. I've just written and tested it.

HP's routine occupies 28 words of ROM, and takes a fixed 39 instruction cycles to execute. It correctly handles input in the range of 0 to 682. (The standard HP-16C requires it to work for values of 0 to 405.)

My routine uses a higher-precision approximation of the reciprocal. My routine occupies 18 words of ROM, and takes 41 or 42 instruction cycles to execute. There's one additional goto instruction needed to skip the empty locations left by the patch, and the goto is only used in 50% of cases, due to an early exit dependent on the remainder value. Counting that goto, it is 19 words of ROM and an average of 42 instruction cycles. It correctly handles input in the range of 0 to over 10,000.