REX is great for TMPC out of the box... since you can just devote a named RAM area to it, and switch over to dedicated TMPC bank on demand. So it solves the problem.
ROM-izing programs is just another way to go probably without REX. I guess there are varying degrees of ease depending on what you find. I bet most CO programs are not really self-modifying, as in, most of the space they occupy when running is a contiguous region of code that does not get modified during execution, like a read-only "code segment." But I would guess most CO programs are not designed to use a fixed RAM region or dynamically allocated memory. Most use, effectively, a "data segment" at the beginning or end of their program. Disassembly of a program and relocating it to run from a fixed spot in low memory is the easy part, at least with a good recursive disassembler. After disassembly it would be pretty easy to see if it refers to ALT-LCD, other known hidey holes, or mostly to a data region close to the beginning or at the end of its program code. The harder part is fixing up all references into that data region to point somewhere else. If the variables are minimal, particularly if the program relies more on file access for large data, it might all fit in ALT-LCD and hidey holes. I'd guess with a good disassembly one could do that work in < day for a big program. Next would be changing all ROM calls to far calls. Again, with a good disassembler that fully disasembles all the code and is able to identify most access to the ROM entry points, that would be a rote process. The hard things bits that disassemblers will miss are computed jumps into the ROM, if any. Though a customer disassembler could be made "smart" and tuned to the problem. And of course a program reverse engineered like that becomes a more flexible, portable codebase if that's of interest. Since if you have a program in a good source condition to port to ROM, you could also port it to CP/M or Z80, or whatever. A good, ROM aware disassembler would be the key to all of it. I don't know much about the Virtual T disassembler... might already be useful for this? One unique thing about VirtualT is it is uniquely positioned to actually run the code as opposed to a traditional disassembler which, even if it's recursive is only doing a static analysis. There's always some information it cannot get at. Imagine running VirtualT in a "data collection" mode that dynamically identifies code versus data, jumps into the ROM, access to known hidey holes and ALT-LCD, etc. That would be super-cool. -- John.
