Extended Memory isn't deterministic

[ChrisNonyminus]

Each time the emulator is restarted, the loaded DOS process's extended memory is placed differently in the physical memory that is exposed to libretro's cheats api than the last time it was loaded. Although savestates work just fine with this quirk, I do worry this may be bad for cheats in RetroArch. I should note that if the core is unloaded and then reloaded, and the content then loaded, the memory is back to where it should be.

[schellingb]

A few weeks ago I noticed that the memory exposed to the frontend for cheats probably broke with the timing changes introduced between 0.18 and 0.21.

So the libretro API says this about the functionality which lets the core expose it's emulated memory:

This environment call lets a libretro core tell the frontend about the memory maps this core emulates.
This can be used to implement, for example, cheats in a core-agnostic way.

Should only be used by emulators; it doesn't make much sense for anything else.
It is recommended to expose all relevant pointers through retro_get_memory_* as well.

Can be called from retro_init and retro_load_game.

That last line is a bit of a problem for us... During retro_load_game (which gets called after retro_init) we don't have the DOSBox emulator fully running yet. So we don't actually know the full memory layout. Ideally the core would set the layout of the memory at the point the EXE file is started.

Now RetroArch (the libretro reference frontend) doesn't seem to enforce what's stated on the last line. So maybe it's fine if we just do that and hope any other frontend either behave the same or ignore it and generally don't crash.

For the very first release of this core cheat support was important for me but up until now I never heard of anyone actually using it. But I'd like to get back to this. I think cheats are a very cool feature of emulators. Now if only the cheat search tool built into RetroArch was a tiny bit more user friendly :-)