This is amazing. Well done figuring out the shared memory hack. That's a huge time saver and really makes sense from an engineering perspective. Ten dollars for the hammer and five thousand for knowing where to strike the machine, to paraphrase a trope on expertise applied correctly.
Technical question: what guarantees that the memory address is stable? It means that allocations always happen in the same order in the game ?
It needs to be a global variable in C. A variable in a function scope or runtime malloc'd spot? No chance of finding a stable spot.
Thankfully, a lot of old games love to use global variables because you can't run out of stack space or allocatable memory. Modern games shy away from that because even the tiniest consoles these days come with gigabytes worth of RAM, even a memory leak has to be a gigantic firehose to bring the system to a halt.
> A variable in a function scope or runtime malloc'd spot? No chance of finding a stable spot.
It depends, on a system with no ASLR it's potentially still deterministic, but there are a lot of potential sources of non-determinism.
Console games of that era don't usually malloc; they have globals. Entities go into pools / buffers that are allocated ahead of time
This is a fairly "common" technique for doing multiplayer randomizers. Typically on a smaller region, but you end up with some sort of scratch memory being used as a buffer for messages sent back and forth between the emulator and the network layer (or your flash cart's RAM and the network layer, in the case of FXPakPro!). It's super useful.