Memory Insector issues with later Raizing games

[leonardotc]

The problem

The memory inspect on RALibretro doesnt seem to work with batrider and barkraid properly when using the FBNeo core. The game is recognized by RetroAchievements and the hash matches the one on the website but the inspector just doesnt seem to work. The only weird thing that there is some strange memory check before the game starts and I also noticed that the Log.txt is different from that of Sorcer Striker for exemple (another legendary game from the same manufacturer and on the same board).

RALibretro log:

180232.456 [INFO ] [MEM] no change detected. using existing memory map
180232.463 [INFO ] [FBNeo] Unknown device type for port 0, forcing "Classic" instead
180232.463 [INFO ] [FBNeo] Unknown device type for port 1, forcing "Classic" instead
180232.463 [WARN ] [COR] Unimplemented env call: GET_AUDIO_VIDEO_ENABLE (47)
180518.786 [INFO ] [MEM] no change detected. using existing memory map

I checked out the ralibretro repository and was able to build and debug in my machine. It seems that the call to the core returns an empty data set. The numbers are not hardcoded. I changed them to give runtime context.

core->getMemoryData(2);
core->getMemorySize(2);

The Diagnose

These seems to be wrappers to the system calls of retro_get_memory_data and retro_get_memory_size which is part of libretro interface (implemented on fbneo fork).

In this case both calls just return the previously set value (I am guessing during CheevosInit)

void *retro_get_memory_data(unsigned id)
{
    return id == RETRO_MEMORY_SYSTEM_RAM ? pMainRamData : NULL;
}

size_t retro_get_memory_size(unsigned id)
{
    return id == RETRO_MEMORY_SYSTEM_RAM ? nMainRamSize : 0;
}

I believe the core of the issue is related to this

src\burn\drv\toaplan\d_bbakraid.cpp

    if (nAction & ACB_VOLATILE) {        // Scan volatile ram
        memset(&ba, 0, sizeof(ba));
        ba.Data        = RamStart;
        ba.nLen        = RamEnd - RamStart;
        ba.szName    = "RAM";
    }

src\burn\drv\toaplan\d_batrider.cpp

    if (nAction & ACB_VOLATILE) {        // Scan volatile ram

        memset(&ba, 0, sizeof(ba));
        ba.Data        = RamStart;
        ba.nLen        = RamEnd - RamStart;
        ba.szName    = "RAM";
    }

src\burn\drv\toaplan\d_battleg.cpp

    if (nAction & ACB_VOLATILE) {        // Scan volatile data
        memset(&ba, 0, sizeof(ba));
        ba.Data        = RamStart;
        ba.nLen        = RamEnd-RamStart;
        ba.szName    = "All Ram";
        BurnAcb(&ba);
    }

We do have a set for garegga on RetroAchievements so I imagine that problem is not applicable there. It also satisfies the default condition on the retro_memory.cpp.

default:
    // For all other systems (?), main ram seems to be identified by either "All Ram" or "All RAM"
    if ((strcmp(pba->szName, "All Ram") == 0) || (strcmp(pba->szName, "All RAM") == 0)) {
        pMainRamData = pba->Data;
        nMainRamSize = pba->nLen;
        bMainRamFound = true;
    }
    return 0;

I used you guys mingw image https://git.libretro.com/libretro-infrastructure/libretro-build-mxe-win64-cross to build the core and test. Changing the condition seems to have solved the issue. While I cannot say this will be the solution, I believe that is a strong evidence for a causal relationship.

src\burner\libretro\retro_memory.cpp

case HARDWARE_TOAPLAN_RAIZING:
    if ((strcmp(pba->szName, "All Ram") == 0) || (strcmp(pba->szName, "All RAM") == 0 || (strcmp(pba->szName, "RAM") == 0)) {
        pMainRamData = pba->Data;
        nMainRamSize = pba->nLen;
        bMainRamFound = true;
    }
    return 0;

I hope you dont mind that I broke down the issue in two segments. Its just that, since I dont know the codebase, the analysis could be completely wrong so I prefered to separate the potentialy biased part (the diagnose).

OS: Windows 10 Version: Latest downloaded via RaLibRetro Source: RaLibRetro 1.6

Excerpt from the indes @ core: 2023-08-12 001e915d fbneo_libretro.dll.zip

[barbudreadmon]

Your analysis looks correct, can you send a PR for this ?

[leonardotc]

Will do!