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

Also, SRAM banks greater than 0 should now be mapped at offset 0x16000 following a change, see RetroAchievements/rcheevos#329

from mgba.

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

from mgba.

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???)

from mgba.

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).

from mgba.

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

from mgba.

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.

from mgba.

You're right, I forgot to change that.

from mgba.