WIP: 16C firmware hack for more memory

[brouhaha]

(03-03-2023 11:55 PM)Garry Lancaster Wrote:  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.

The 15C microcode goes to absolutely HUGE lengths to make variable-length instructions work. (And there are bugs in it on both the 15C and 41C.) While it's obviously possible to hack the 16C to do that, it would be an enormous task.

Also, going to two-byte instructions "in-place" where the one-byte instructions are stored now is also too much work. Too much of the microcode is dependent on the way the instructions are stored.

The "easy" approaches are to keep one byte where it is, and store the second byte in a parallel structure. There are two possibilities for that parallel structure:

1) keep it somewhere in the main RAM (0x10..0xff). For instance, it could be directly under the current program. This is a bit of a pain, but easier than the variable-length or two-byte-in-place options. Every time the program grows or shrinks by what would normally be one register, the ENTIRE second-byte array would have to also shift by an entire register, in addition to its own size change. The only benefit of this arrangement is that it will work even in a host environment that only implements RAM up to 0xff.

2) store the second bytes somewhere above 0xff - this is by far the easiest approach, and what I have working in an experimental build of Nonpareil. It results in 999 program steps (two-byte), and 1792 bytes of registers, with no curtain. The drawback is that it doesn't appear to work with Swissmicros ARM code.

When I started hacking the 16C microcode, I intended to run it on Swissmicros hardware, but I didn't really expect to be able to use their ARM code, for both technical and licensing reasons. I could work around the licensing, by not supplying their code, only a program to patch it.