WIP: 16C firmware hack for more memory

[brouhaha]

(03-03-2023 06:44 PM)Garry Lancaster Wrote:  Was it easy to find the ROM image within the DM firmware?

In terms of difficulty level, I'd say it was moderately hard, but having the right tools helps tremendously.

In terms of time, with the right tools I was able to figure out what needed to be done in about 45 minutes. Actually writing custom Python scripts to deal with it, and in the process validate my analysis, took about two hours. Then, since I had to insert a bigger microcode ROM image into the DM16 firmware than it was designed to accomodate, I spent roughly four hours writing more scripts, trying several approaches, and debugging. About another half hour was spent testing the registers and finding out that one low-numbered register wasn't working correctly, but a different register depending on word size. Figuring out that the problem was caused by using memory that would be the second R2D2 in the 15C took perhaps 15 minutes, and fixing it took another 15 minues (mostly updating comments in my code; the actual code change was just one line).

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.

Quote:

Quote:I've been thinking about expandnig the 15C and 16C memory even further, but that would probably NOT work with the SwissMicros firmware, because I doubt that SwissMicros supports RAM above 0xff. (To be fair, I haven't actually tried.). I'd have to write my own ARM code, which I've been considering doing anyhow, but if I did that I probably wouldn't support multiple fonts, the RTC, and other nifty features that SwissMicros provides.

Seems to make more sense to leverage the facilities the SwissMicros firmware provides rather than rolling your own. 1547 available bytes seems plenty for 16C usage, although maybe 15C users are more demanding.

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. That means that without expanding the memory, you can have either:

1) 999 program steps and 548 bytes of registers, but no new labels

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.