WIP: 16C firmware hack for more memory

[Garry Lancaster]

(03-03-2023 10:33 PM)brouhaha Wrote:  I'm not sure why they've made it difficult to access the microcode image, but it's clear that it was done deliberately. I don't think I should make the details public, because that might lead to it being made even more difficult in the future, although that's already a possibility now that I've revealed that I've figured it out.

Interesting, and somewhat odd considering they seem to welcome alternative firmwares running on their DMCP platform. Still, good that you were able to figure it out.

Quote:If you want more labels on the 16C, there's no choice but to increase the memory. There are only 13 unused codes for program steps, whereas I need 720 additional codes for LBL, GTO, and GSB with extended labels. The size of a program step has to get bigger, and for various reasons it's only practical to extend it from 8 bits to 16 bits.

I assume this means you plan to make all steps 2 bytes in size? Is it feasible to keep the existing 1-byte codes, taking 3 unused ones for extended LBL/GTO/GSB, with just those requiring an additional byte for the label id?

This would presumably require reimplementing GTO . nnn to always search from the start of the program, if it's currently done by straightforward calculation. And BST to effectively do a GTO . (current step - 1). But as these are interactive, performance isn't too important.

Maybe 15C already does something similar, as I understand it has a mixture of 1- and 2-byte step encodings.

Quote:2) a smaller number of program steps (perhaps up to 884 but with NO registers), but with more labels.

With memory expansion (beyond what the SwissMicros ARM code is known to support), you could have 999 steps with extra labels, and 1792 bytes of registers, simultaneously. Those sizes would always be available, with no moveable partition boundary.

884 steps with no registers is still a massive improvement on what we currently have. But more would of course be welcome!