WRAM2-7 seems to be incorrectly mapped for libretro.c, and addition of paged SRAM1-15

[GauChoob]

The memory map that is exposed to libretro does not seem to correctly define the zone for WRAM2-7

https://github.com/mgba-emu/mgba/blob/1d2b8bf918890e4e71957a1677a7bee72c796c08/src/platform/libretro/libretro.c#L819

When opening RALibRetro, the following debug information appears: [INFO] [MEM] Registered 0x0100 bytes of SYSTEM RAM at $000000 (descriptor 1, offset 0x000000) [INFO] [MEM] Registered 0x0050 bytes of SYSTEM RAM at $000100 (descriptor 1, offset 0x000100) [INFO] [MEM] Registered 0x3EB0 bytes of SYSTEM RAM at $000150 (descriptor 1, offset 0x000150) [INFO] [MEM] Registered 0x4000 bytes of SYSTEM RAM at $004000 (descriptor 2, offset 0x000000) [INFO] [MEM] Registered 0x1800 bytes of VRAM at $008000 (descriptor 3, offset 0x000000) [INFO] [MEM] Registered 0x0400 bytes of VRAM at $009800 (descriptor 3, offset 0x001800) [INFO] [MEM] Registered 0x0400 bytes of VRAM at $009C00 (descriptor 3, offset 0x001C00) [INFO] [MEM] Registered 0x2000 bytes of SRAM at $00A000 (descriptor 10, offset 0x000000) [INFO] [MEM] Registered 0x1000 bytes of SYSTEM RAM at $00C000 (descriptor 4, offset 0x000000) [INFO] [MEM] Registered 0x1000 bytes of SYSTEM RAM at $00D000 (descriptor 5, offset 0x000000) [INFO] [MEM] Registered 0x1000 bytes of SYSTEM RAM at $00E000 (descriptor 4, offset 0x000000) [INFO] [MEM] Registered 0x0E00 bytes of SYSTEM RAM at $00F000 (descriptor 5, offset 0x000000) [INFO] [MEM] Registered 0x00A0 bytes of VRAM at $00FE00 (descriptor 6, offset 0x000000) [INFO] [MEM] Registered 0x0060 bytes of UNUSED at $00FEA0 (descriptor 10, offset 0x005EA0) [INFO] [MEM] Registered 0x0080 bytes of SYSTEM RAM at $00FF00 (descriptor 7, offset 0x000000) [INFO] [MEM] Registered 0x007F bytes of SYSTEM RAM at $00FF80 (descriptor 8, offset 0x000000) [INFO] [MEM] Registered 0x0001 bytes of SYSTEM RAM at $00FFFF (descriptor 9, offset 0x000000) [INFO] [MEM] Registered 0x2000 bytes of SYSTEM RAM at $010000 (descriptor 10, offset 0x006000) [INFO] [MEM] Could not map region starting at $012000 [INFO] [MEM] Registered 0x4000 bytes of SYSTEM RAM at $012000 (null filler)

I think the issue could be with this line, but I'm not 100% sure descs[i].select = 0xFFFFA000;

[GauChoob]

Also, SRAM banks greater than 0 should now be mapped at offset 0x16000 following a change, see https://github.com/RetroAchievements/rcheevos/pull/329

[endrift]

I'm not really sure how the memory mapping subsystem works; Any idea @CasualPokePlayer?

[CasualPokePlayer]

The idea of libretro's memory maps is you give it a ton of pointers with buffer lengths according to those pointers and tell libretro what the ""real"" address here is (so more or less creating a "System Bus" like map). However, since that isn't actually sufficient for exposing all useful memory, libretro has to go do a hack where it maps memory past the addressing limit of the console (so for GB/C that's >0xFFFF). I have no idea how this "select" thing in libretro's memory maps actually works (is it some kind of mask???)

[Jamiras]

select specifies which bits need to match start to be considered part of the block. disconnect specifies bits to ignore. Here's my attempt to explain this back in 2022: https://discord.com/channels/184109094070779904/876520593636335646/946233105654628452

If select is 0, start and len represent the full region of memory (i.e. 0x4000 and 0x2000 would be $4000-$5FFF), and the memory being read is accessible at ptr + (address - start).

Otherwise, select and disconnect are used to map an address to a memory block. If the bits of the address masked by the select value match the start value (i.e. address & select == start & select), then the address could be read from the associated block. disconnect is used to mask off bits that don't apply to the block, so the actual memory being read is ptr + (address & ~disconnect) - start.

For example, on NES: $0800-$0FFF, $1000-$17FF, and $1800-$1FFF are all the same memory as $0000-$07FF. If the top 3 bits are 0, the fourth and fifth bits are ignored, and the remaining 11 bits determine where to actually read from RAM. Since the top 3 bits indicate a memory address in RAM, select would be 0xE000, or 0xFFFFE000 if extended for 32-bit. And since only the 11 lowest bits are significant, the other 5 bits are "disconnected", so disconnect would be 0xF800, or 0xFFFFF800 if extended for 32-bit.

Carrying this further, if you tried to read $193A, it would match the RAM block (address 0x193A & select 0xFFFFE000 = 0x0000, start 0x0000 & select 0xFFFFE000 = 0x0000, 0x0000 == 0x0000), and (address 0x193A & ~disconnect 0x000007FF = 0x013A), so reading $193A would return whatever is at ptr + 0x013A. if you tried to read $793A, it would not match the RAM block (address 0x793A & select 0xFFFFE000 = 0x6000, start 0x0000 & select 0xFFFFE000 = 0x0000, 0x6000 != 0x0000).

[endrift]

Gosh that's confusing. Can you confirm if this is fixed? I'll reopen if not.

[Jamiras]

I think descs[i].start for the new block should be 0x16000 to line up with the virtual address similar to the one assigned to 0x10000 a few lines below.

[endrift]

You're right, I forgot to change that.