[WIP] Achievements: Implement new memory mapping w/ extended memory support

[Souzooka]

Description of Changes

This PR implements a proposed mapping change to exposed memory for RetroAchievements.

Currently, this splits the memory map into two separate memory mappings, depending on if 128MB memory is enabled.

Extra Memory Disabled:
*0x00000000-0x01FFFFFF= 32MB Main RAM
*0x02000000-0x02003FFF= Scratchpad (Legacy)
*0x02004000-0x6FFFFFFF= Unused/(uninitialized upper 96MB Main RAM+unused)
*0x70000000-0x70003FFF= Scratchpad (Modern)

Extra memory Enabled:
*0x00000000-0x07FFFFFF= 128MB Main RAM
*0x08000000-0x6FFFFFFF= Unused
*0x70000000-0x70003FFF= Scratchpad (Modern)

The current WIP implementation for this isn't satisfactory as it only checks if the 128MB option is enabled or not, which can be changed in game. Ideally, the 0x02000000-0x02003FFF region would be removed some time in the near future, though with some pressure it could potentially just be dropped immediately. Currently, there is only one RetroAchievements set which would be affected by this change, Mega Man Anniversary Collection, which presumably just sticks emulator memory into the Scratchpad. It may be easier to quickly update this set (which could likely be done via an automated script) and request users use a minimum version for PCSX2 rather than to put a significant effort into supporting the legacy mapping.

This change requires a bit more testing and I would also like to gather feedback from RA Integration engineers and PCSX2 engineers.

Rationale behind Changes

This mapping change allows developers to access the upper 96MB of RAM when users enable the developer kit option. Some games utilize this RAM and as such it is impossible to ensure that achievements work properly if a user enables this option, as the memory is currently unexposed.

Suggested Testing Steps

To properly test this change, building a custom version RAIntegration-x64.dll and running PCSX2 with the -raintegration flag is required. Under rcheevos/consoleinfo.c, changing the rc_memory_regions_playstation2/_rc_memory_regions_playstation2[] definitions to

static const rc_memory_region_t _rc_memory_regions_playstation2[] = {
    { 0x00000000U, 0x000FFFFFU, 0x00000000U, RC_MEMORY_TYPE_SYSTEM_RAM, "Kernel RAM" },
    { 0x00100000U, 0x01FFFFFFU, 0x00100000U, RC_MEMORY_TYPE_SYSTEM_RAM, "System RAM" },
    { 0x02000000U, 0x07FFFFFFU, 0x02000000U, RC_MEMORY_TYPE_SYSTEM_RAM, "Extended RAM"},
    { 0x08000000U, 0x6FFFFFFFU, 0x08000000U, RC_MEMORY_TYPE_UNUSED, "Unused"},
    { 0x70000000U, 0x70003FFFU, 0x70000000U, RC_MEMORY_TYPE_SYSTEM_RAM, "Scratchpad RAM" },
};
static const rc_memory_regions_t rc_memory_regions_playstation2 = { _rc_memory_regions_playstation2, 5 };

should presumably give correct mappings to match the PCSX2 changes. However, for whatever reason, while RC_MEMORY_TYPE_UNUSED should add padding to that area, this did not work on my end and as such RAIntegration's Memory Viewer would place the end of memory at 0x08003FFF.

Nonetheless, I did verify that the upper 96MB of RAM appeared to be accessible. With 128MB mode disabled, the Scratchpad is also viewable at 0x02000000, and it's possible to view both the top of the 32MB of Main RAM and the beginning of Scratchpad at the same time. There likely needs to be another edit to Achievements::RAIntegration::RACallbackReadBlock so that viewing past the end of the 128MB of Main RAM doesn't cause the Main RAM section to show as all 0s, as it currently does.

Did you use AI to help find, test, or implement this issue or feature?

No.

[chaoticgd]

I can't comment on the design, however I noticed the following issues with the implementation:

• ClientReadMemory(0x100000, buffer, 0xffffffff, nullptr) results in an out of bounds read due to integer wraparound when adding the address and the size.
• ClientReadMemory(0x0, buffer, 0x70000001, nullptr) results in an out of bounds read because the start and end of the block being read are in different "segments" of the fake address space.
• ClientReadMemory(0x1fffffe, buffer, 0x4, nullptr) results in the wrong data being returned, again since the start and end of the block are in different segments.

Given the more complicated memory map, I think it may make sense to implement more general logic for handling reads that cross different segments (if we need to support that case, I'm actually not sure). For example, a loop that goes over a table of segments, and checks if each would contribute to the output.

I haven't done any testing of the system as a whole.

[Souzooka]

I made an amendment which should address the first two cases you brought up. I'm not sure that RAInt would provide such a large size, but it's fair to handle it regardless. I missed the third case when I read my e-mail but it could potentially be handled, but then again it might be easier to just drop the legacy mapping entirely based on what people think.

[chaoticgd]

Looks like no RetroAchievements developers have commented on this so far. Have you reached out to them? It would be good if they could leave their opinions here.

[Jamiras]

I can't speak to the PCSX2 changes, but here are my comments on the memory map changes:

Currently, there is only one RetroAchievements set which would be affected by this change, Mega Man Anniversary Collection, which presumably just sticks emulator memory into the Scratchpad. It may be easier to quickly update this set (which could likely be done via an automated script) and request users use a minimum version for PCSX2 rather than to put a significant effort into supporting the legacy mapping.

If that's true, that would be my preference. Unfortunately, we won't be able to support both via checking both addresses as the precense of new addresses unknown to the older client will automatically disable the achievements in the older client.

There likely needs to be another edit to Achievements::RAIntegration::RACallbackReadBlock so that viewing past the end of the 128MB of Main RAM doesn't cause the Main RAM section to show as all 0s, as it currently does.

I'm not sure I understand this. Are you saying the UNUSED memory block is showing 00s instead of --s? I thought the DLL already handled that.

However, for whatever reason, while RC_MEMORY_TYPE_UNUSED should add padding to that area, this did not work on my end and as such RAIntegration's Memory Viewer would place the end of memory at 0x08003FFF.

That doesn't sound right either. But definitely something on the DLL side of things - possibly related the the previous comment.