Ok, thank you for that explanation, that’s made that a lot clearer.
This is the case where the file system would be useful.
Instead of having to set the address in the program,
the address would be stored in the ‘file’ table at the start of the FX chip and then looked up dynamically by matching the program ID to an entry in the table.
(Note that when I talk about ‘files’ I mean it in the sense of a block of uniquely identifiable external data, explicitly without the implication of using a URL to identify the ‘file’.)
Basically the table would look like this:
Either for some fixed size, or with a prefixed length.
‘Game Id’ would probably be an (unsigned) integer of at least 16 bits.
‘Offset’ would probably be either a page index or a byte index.
‘Size’ would probably be either a quantity of pages or a quantity of bytes.
So a structure representing a table entry might be:
And then the start of the chip contains the equivalent of either:
constexpr TableEntry table[someFixedSize];
constexpr uint16_t someVariableSize;
constexpr TableEntry table[someVariableSize];
(And then the table could be sorted so that a binary search could be used instead of a linear search, unless that’s going to cause too much wear on the chip.)
The important thing is that this way the program itself doesn’t change after being compiled,
the only thing that changes is the data on the FX chip.
This way it’s possible to rewrite the chip without reflashing the Arduboy itself.
It also allows people to identify data from other games,
which could be useful for some cross-game trickery,
like migrating character profiles from old games to new games.
I realise this would probably be a burden on the bootloader,
but to be honest if we’re giving games access to that much external data I don’t think having a small bootloader is particularly important.
I can’t remember either way, so I’ll just ignore it for now,
I’m not awake enough to work that one out as well.