WIP: 16C firmware hack for more memory

[brouhaha]

The occasional skipped nibble problem in register addressing turns out to be quite a bit more complicated than I expected. The problem occurs in a section of code that takes a 12-bit binary nybble offset from the base of RAM, and divides it by 14 (because there are 14 nybbles in each hardware RAM register). The quotient is the hardware register RAM address offset (still relative to the base of RAM), and the remainder is the starting digit position within that hardware register. 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.

The precision of the reciprocal was apparently chosen such that the division by 14 gets the correct quotient and remainder for input values from 0 to 405, as required by the HP-16C with 203 bytes of memory. In fact, ti works correctly up to 682. Unfortunately it winds up off by progressively larger amounts beyond that, gaining approximately a nibble for every increase of 682 of the input.

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. Luckily I just wrote one of those recently to solve a different problem with expanding the 16C memory. I can't use exactly the same routine, as the requirements are different, but I can use somewhat similar code. In fact, the new code is six words shorter than HP's ultra-clever code. It might take a few instructions longer for some input values. The HP code takes a fixed 39 cycles, which is not data dependent. My new code has data dependent timing, with a minimum of 30 cycles. I have not yet determined typical or worst case timings. Given how much other overhead there is in executing a RCL or STO instruction, the overall percentage slowdown will be very small.

Overall for this project, I expected to have to hack a whole lot of moderately tricky routines to make memory expansion work, but it turned out that a some things already worked, several things needed only trivial patches, the division for f MEM needed to be extended, and this latest find on the register addressing is the only thing that has been extremely tricky.