Memory Display Issues with Megadrive Cores about ralibretro HOT 6 CLOSED

RAGens exposes 64 KiB of SRAM in addition to the 68K system RAM, which is the only range that RALibretro exposes for the Mega Drive. I don't know what this SRAM should map to.

from ralibretro.

If i remember correctly someone mentioned on discord that 0x10000 - 0x1FFFF is related to battery save data.

from ralibretro.

Hm, libretro ports of both PicoDrive and Genesis-Plus-GX implement RETRO_MEMORY_SAVE_RAM, so all it's needed is to register it in RAIntegration.

It should be only a matter of moving the Emulator::kPicoDrive and Emulator::kGenesisPlusGx case in this switch a bit down so they're together with the Emulator::kSnes9x and Emulator::kMednafenVb ones.

from ralibretro.

RAGens maps "RAM_68K" (64KB) to $0000-$FFFF and "SRAM" (64KB) to $10000-$1FFFF. These are emulator specific buffers and don't represent the actual layout of the Genesis's memory. The Genesis's memory exposes the "RAM_68K" every 64KB from $E00000-$FFFFFF. It's normally accessed from $FFxxxx, and the other addresses serve as echo RAM. SRAM, when present, is accessed from $200000-$20FFFF, which is in the middle of the block reserved for the ROM data ($000000-$3FFFFF). Titles larger than 2MB with SRAM have to toggle some system bits to indicate whether $200000 points at the SRAM or the ROM. Because the emulator stores it as a separate buffer, we don't need to worry about that.

In general, direct access to external storage should be avoided. Almost everything that's stored in SRAM is also stored in general RAM, and only written to SRAM when the player uses a save point. Since we expect the achievement to trigger when the player accomplishes it, instead of when they next save the game, the trigger should not rely on SRAM. Additionally, SRAM can typically hold multiple save slots, so relying on the SRAM would require multiple alts to handle addresses for each of the multiple save slots.

Very few commercial Genesis games even have SRAM, and from what little documentation I could find, none have more than 32KB. Despite that, 64KB is exposed by the emulator as that's the maximum value allowed by the system design. The portion not filled by the SRAM is 0'd out (at least by Gens).

Having said that, the implementation is definitely system dependent, and I don't claim to have knowledge about how any particular system manages its SRAM. For NES games that I worked on (Dragon Warrior III/IV), many of the important flags were found in the SRAM region ($6000-$7FFF) and addresses did not differ regardless of which save slot was being used. Quick testing did indicate when the player chooses to save, it also writes to this region (but at different addresses). In this case, it's important to expose the SRAM region because it's being used both for persistence and runtime functionality.

As best as I can tell, there aren't any Genesis games currently relying on addresses greater than $FFFF. Brief testing in Phatasy Star IV indicates addresses greater than $FFFF only change when the player saves, so it's probably unnecessary to expose the SRAM directly. There's a common block in the first 100 bytes or so for things like which slots are used and the last slot saved in, then there's larger blocks for each of the save slots. Using all three slots consumes about 16KB of the 64KB block.

Based on my experience with NES, I would vote to expose the SRAM. It may be getting used for things other than purely save data. And exposing it just provides more memory to search through when looking for important addresses. Not exposing it would make searching easier unless the SRAM were being used as additional RAM.

The only issue that might occur with @leiradel 's proposed solution is if the emulator reports accurate SRAM sizes. A ROM without SRAM might report an SRAM size of 0, in which case, the memory viewer will still stop at $FFFF, whereas RAGens would still provide 64KB of 0s.

from ralibretro.

Thanks for the details, I didn't know SRAM in Mega Drive games had a fixed address when present.

SRAM is exposed by both cores, so it's possible to add it to the memory inspector. If SRAM has less than 64 KB or is absent, we can fill in the region with zeroes similar to what we do with Gambatte at https://github.com/RetroAchievements/RALibretro/blob/develop/src/Application.cpp#L761

from ralibretro.

This no longer appears to be a problem. I can get all the way to $1FFFF in every Genesis game that I tried. Shining Force has a set (apparently created before this ticket), and does not use any addresses in the SRAM space. I did, however, verify that once a new game is started, memory is modified in the SRAM space, so it appears to be exposed correctly.

from ralibretro.