Retroarch: We need an api for nonlinear cheevos memory access.

[meepingsnesroms]

I am proposing an environment callback named RETRO_ENVIRONMENT_SET_MEMORY_ACCESSOR and it will pass RetroArch a function pointer of:
uint64_t (*accessor)(uint64_t console_memory_address, uint32_t size, bool is_write, uint64_t value);

Size is in bits not bytes and non multiples of 8 can be considered invalid.
Using non stdint.h types is OK too for compatibility I just wrote the example with them for clarity.

Some cores like nestopia dont have a fixed buffer for each memory section(for nestopia its per hardware chip in the cartridge) or its not accessible.

This would allow the libretro interface to read or write from a specific memory address from the point of view of the consoles cpu, the only exception is invalid access which will return 0x00000000.

[fr500]

@leiradel @Alcaro

Since there are two APIs already to get memory data I asked @meepingsnesroms to post an issue before doing any changes to the API, maybe it can be covered with the memory descriptors API.

[leiradel]

Some cores like nestopia dont have a fixed buffer for each memory section

You mean the memory pointers change during the emulation? If they're fixed, RETRO_ENVIRONMENT_SET_MEMORY_MAPS or retro_get_memory_data/size will work without issues, but if they change all of our memory access methods will fail.

If the memory is split into multiple different buffers, the memory map interface can still be used. FCEUmm has 64 buffers with 1 Kb each, they're all mapped and the cheevos work just fine.

This would allow the libretro interface to read or write from a specific memory address from the point of view of the consoles cpu

I think this will fail as soon as we have to deal with banked RAM, which will happen sooner or later.

[leiradel]

There was someone on IRC designing a different API to access the cores' memory. It was also based on calling functions to read/write from memory. His design included different views, so the same memory could appear in different views, i.e. on MSX:

• "slot3" is all the memory in this slot. It can have nothing, 16 or 32 Kb of cartridge ROM starting at 0x4000, 32 Kb of RAM starting at 0x8000, 64 Kb... It depends on the particular machine
• "cart1" could be the ROM of the first cartridge, if any
• "sys" is the visible memory from the CPU perspective

and so on. I don't remember why he needed something different from what we already have, but I remember something related to the complexity of the memory map interface.

[meleu]

Hello friends.

@leiradel brought to my atention this commit on nestopia repo by @meepingsnesroms and that Nestopia was tagged as supporting cheevos on the docs (an info added by @Hedonium).

But I checked today and Nestopia still doesn't support cheevos. I submitted a PR on docs repo fixing this info: https://github.com/libretro/docs/pull/10

By the way, I hope to see Nestopia supporting cheevos soon! :slightly_smiling_face:

[meepingsnesroms]

It allows cheevos to access the cpu ram, the ram in the cartridge is still inaccessible and some cheevos cant be unlocked.

So cheevos is not officially supported yet.

[SourMesen]

Just stumbled on this while looking into fixing this part of retroachievements in Mesen. With the current API, I can make a large chunk of games work relatively easily, but in other cases, it makes things a lot harder than they could be.

Having the ability to define a callback that RetroArch could use to read any byte in the CPU's address space (i.e what was suggested above) would be a lot easier (from my code's point of view) than having to define the entire memory map and having to expose the emulator's internal arrays (esp. when it comes to cartridges that have the ability to bankswitch RAM at any time, potentially doing so several times per frame).

The current API is good enough to make it work with little effort for most games (e.g Metroid), so I'll implement that for now. Just wanted to let you guys know this would be a feature that would help on my end, too.