Assuming we make it work as envisioned, by that time I like to remove SYS_Exec_88 and replace it with something more flexible. Some thoughts about the direction where it can go:
- Name-based instead of address-based addressing of ROM files. So we can also fopen() ROM files for example, and Main.gcl doesn't need to hardcode the apps. We can even rewrite the main menu in C.
- Support of an execution start address. (So full support of GT1 format. In ROM v3, SYS_Exec_88 already supports 64K and ZP)
- Perhaps support decompression from ROM as well (pucrunch? exomizer?), so we can preload more applications
- Maybe even support unmodified Tetronis/Bricks (there is a ZP conflict now that Main.gcl works around explicitly with some hacks, but these hacks must go)
So I like to remove it from interface.json already, in preparation of total removal in a future ROM version.
The likelihood of this causing issues is low. However, if somebody is secretly developing an awesome ROM application that hinges on SYS_Exec_88 as its ROM loader, we clearly need to coordinate.
Once SYS_Exec_88 is retired, we win a lot of space in ROM page zero. We can use that as new entry points to SYS functions (new and old). The same jump table mechanism we now have in ROM page 0xb00 can be duplicated in page 0. The advantage is that their addresses can be loaded with LDI instead of LDWI, or 2 bytes instead of 3.
Any concerns about removal of SYS_Exec_88, please reply here before the end of August, and/or update in GitHub issue https://github.com/kervinck/gigatron-rom/issues/84