WIP: 16C firmware hack for more memory

[brouhaha]

(03-04-2023 04:43 AM)Paul Dale Wrote:  Two-bytes vs one-byte opcodes? I'm not concerned. Move most of the one-byte codes into the 0-127 space. Put the rest in the 128-255 space.

I don't think I fully understand.

On the 15C, they use variable length instructions. They needed to be able to reliably distinguish any given byte in the program as being:
1) a single-byte instruction
2) the first byte of a two-byte instruction
3) the second byte of a two-byte instruction

They accomplished that by not allowing any single-byte instructions, or any second bytes, from having a 0xf in the least signficant digits, and requiring that all first bytes have 0xf in the least significant digit.

By making the program encoding unambiguous (never requiring looking back more than one byte), they make BST and label searches very fast.

The HP-41C has much more complicated rules for instruction length, and arbitrary bytes in memory are ambiguous, so BST and label search are expensive. They make up for the label search cost by inserting the target of a local GTO and XEQ instruction into that instruction the first time the search for the target is done, and then they have to do a "decompile" pass every time the program gets edited. (The 41 also runs the Nut CPU at nearly twice the speed of a Voyager.)

Quote:Alternatively, all op-codes are sixteen bits wide. Problem solved.

The easiest solution, and the one I want to use. The "extra byte" for all current instructions will be zero. If it's non-zero, then it's a new instruction.

The trick is where to store the second byte.

Quote:With modern ICs memory is simple not an issue.

Sure, but I'm not trying to write a 16C-equivalent calculator from scratch. (An argument could easily be made that I should.) I'm trying to hack up HP's 16C microcode. If I stay within certain bounds, such as only using registers from 0x10 through 0xff, then it will run on existing simulation code on existing ARM-based calculators from both HP/Moravia/Royal and SwissMicros. If I write my own simulator (which as everyone here knows, I've done before), then I could run it on pretty much any hardware, but I'd have to write specific code for each hardware platform to deal with its keyboard, display, etc. Even that's not a huge deal, except that on SwissMicros, I'd be giving up the fonts, real-time-clock, and other features they have, unless I went to the trouble of writing equivalents to all that myself. I did that on the series of prototypes that Richard Ottosen and I built; we had two prototypes that had functionality similar to the DM41X and the DM42. But in the limited time I can devote to this, I enjoy hacking the HP microcode more than I enjoy dealing with new ARM hardware.

As with everything, it's a tradeoff, and there's no correct answer.