You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In issue #293, I learned that the current mGBA core might have a bug causing its search space to be only from 0x00000000 to 0x00007FFF. I have the same problem on my end, but it was also mentioned that after switching to the vba-m core, the search space expanded to 0x0003FFFF.
However, I want to know whether having a maximum cheat search memory space of 0x0003FFFF is normal for GBA games. I found that the GBA memory map is as follows:
General Internal Memory
00000000-00003FFF BIOS - System ROM (16 KBytes)
00004000-01FFFFFF Not used
02000000-0203FFFF WRAM - On-board Work RAM (256 KBytes) 2 Wait
02040000-02FFFFFF Not used
03000000-03007FFF WRAM - On-chip Work RAM (32 KBytes)
03008000-03FFFFFF Not used
04000000-040003FE I/O Registers
04000400-04FFFFFF Not used
Internal Display Memory
05000000-050003FF BG/OBJ Palette RAM (1 Kbyte)
05000400-05FFFFFF Not used
06000000-06017FFF VRAM - Video RAM (96 KBytes)
06018000-06FFFFFF Not used
07000000-070003FF OAM - OBJ Attributes (1 Kbyte)
07000400-07FFFFFF Not used
External Memory (Game Pak)
08000000-09FFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 0
0A000000-0BFFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 1
0C000000-0DFFFFFF Game Pak ROM/FlashROM (max 32MB) - Wait State 2
0E000000-0E00FFFF Game Pak SRAM (max 64 KBytes) - 8bit Bus width
0E010000-0FFFFFFF Not used
Unused Memory Area
10000000-FFFFFFFF Not used (upper 4bits of address bus unused)
I tested "Metroid Zero Mission" and "Metroid Fusion", and within the 0x0003FFFF memory space, I could not find the player HP; it seems they are stored in memory beyond this range. From 0x00000000 to 0x0003FFFF is only 256KB. I am not sure how this memory space is mapped in the GBA, but it seems that it cannot include both the On-board Work RAM (256KB) and the On-chip Work RAM (32KB), because together they require 288KB. In the standalone version of mGBA, I can correctly locate the HP at an address within the On-chip Work RAM region, which seems to indicate that the On-chip Work RAM is not included in the current search space supported by RetroArch (256KB).
I am not sure whether this is a bug or an intentional feature. If it is a bug, I hope it can be fixed. If it is intentional, I hope the memory space can be increased to 288KB, so that it can completely include both the On-board Work RAM and the On-chip Work RAM. Because the cheat functions provided by the emulator core are limited, only allowing setting fixed values and cannot perform logical judgments and other operations, and currently the "make controller rumble" feature provided by RetroArch cannot be set to functions such as rumbling when taking damage because the search space does not include the HP address.
Thank you for your attention to this issue. I look forward to your feedback and any potential fixes or enhancements. If needed, I would be happy to provide any assistance I can.
The text was updated successfully, but these errors were encountered:
In issue #293, I learned that the current mGBA core might have a bug causing its search space to be only from 0x00000000 to 0x00007FFF. I have the same problem on my end, but it was also mentioned that after switching to the vba-m core, the search space expanded to 0x0003FFFF.
However, I want to know whether having a maximum cheat search memory space of 0x0003FFFF is normal for GBA games. I found that the GBA memory map is as follows:
I tested "Metroid Zero Mission" and "Metroid Fusion", and within the 0x0003FFFF memory space, I could not find the player HP; it seems they are stored in memory beyond this range. From 0x00000000 to 0x0003FFFF is only 256KB. I am not sure how this memory space is mapped in the GBA, but it seems that it cannot include both the On-board Work RAM (256KB) and the On-chip Work RAM (32KB), because together they require 288KB. In the standalone version of mGBA, I can correctly locate the HP at an address within the On-chip Work RAM region, which seems to indicate that the On-chip Work RAM is not included in the current search space supported by RetroArch (256KB).
I am not sure whether this is a bug or an intentional feature. If it is a bug, I hope it can be fixed. If it is intentional, I hope the memory space can be increased to 288KB, so that it can completely include both the On-board Work RAM and the On-chip Work RAM. Because the cheat functions provided by the emulator core are limited, only allowing setting fixed values and cannot perform logical judgments and other operations, and currently the "make controller rumble" feature provided by RetroArch cannot be set to functions such as rumbling when taking damage because the search space does not include the HP address.
Thank you for your attention to this issue. I look forward to your feedback and any potential fixes or enhancements. If needed, I would be happy to provide any assistance I can.
The text was updated successfully, but these errors were encountered: