Microsoft
Xbox (xbox)
Memory Bank | Start | Length |
---|---|---|
RAM | 0x80000000 | 0x04000000 (64 MB) |
RAM Mirror? | 0x84000000 | - |
-
Endianness: Little
-
Pointer length: 4 bytes
Cxbx-Reloaded
Memory constants are defined in src/common/AddressRanges.h
. XBOX_MEMORY_SIZE
references the normal console's 64MB RAM size while CHIHIRO_MEMORY_SIZE
references the 128MB of contiguous RAM for dev boards. Use RangeFlags
to determine size to use (SYSTEM_XBOX / SYSTEM_128MB).
PMMPTE PointerPte = GetPteAddress(PHYSICAL_MAP_BASE);
return PointerPte; // ?
Reference material:
-
https://raw.githubusercontent.com/Cxbx-Reloaded/Cxbx-Reloaded/e6b2ed88af52207e3df544b692ee7acb2ef521f3/src/common/AddressRanges.h
-
https://raw.githubusercontent.com/Cxbx-Reloaded/Cxbx-Reloaded/e6b2ed88af52207e3df544b692ee7acb2ef521f3/src/core/kernel/memory-manager/VMManager.cpp
Xbox 360 (xbox360)
Memory Bank | Start | Length |
---|---|---|
Unified RAM | 0xA0000000 | 0x20000000 (512 MB) |
-
Endianness: Big
-
Pointer length: 4 bytes
The 512MB of unified GDDR3 RAM allows the first 10MB to be be addressed by the GPU and used as VRAM, but this behavior wouldn't require separating into its own bank.
References
-
https://free60project.github.io/wiki/Memory_MAP/
-
https://free60project.github.io/wiki/Memory/
-
https://raw.githubusercontent.com/xenia-project/xenia/8123978c498257ad9d65353bc59af3e544b4fc27/src/xenia/memory.cc
Nintendo
Nintendo 64 (n64)
Memory Bank | Start | Length |
---|---|---|
RDRAM | 0x80000000 | 0x00400000 (4 MB) |
RDRAM (Expansion Pak) | 0x80400000 | 0x00400000 (4 MB) |
-
Endianness: Big, but little in CL (see below)
-
Pointer length: 4 bytes
In most emulated cases the console will have an Expansion Pak installed, so 8MB can generally be assumed. 16MB is theoretically possible, supposedly some niche hacks and homebrew use it but through modified emulators.
Endianness is tricky on most emulators because each 32bit word is flipped to be read/written in little-endian. This causes byte strings to appear in a messy order. For example...
01 02 03 04 05 06 07 08
-> 04 03 02 01 08 06 07 05
...or even worse nonsense when the data isn't word-aligned. This may require special-casing later on if a more accurate N64 emulator gains popularity.
References
- https://github.com/project64/project64/issues/1374
GameCube (gcn) / Wii (wii)
Memory Bank | Start | Length |
---|---|---|
MEM1 | 0x80000000 | 0x01800000 (24 MB) |
MEM2 | 0x90000000 | 0x04000000 (64 MB) |
-
Endianness: Big
-
Pointer length: 4 bytes
MEM1 is recycled from the GameCube and can be accessed slightly faster, meaning most relevant gameplay data will often still be in this region while MEM2 is used for large chunks of decompressed data.
References
- https://wiibrew.org/wiki/Memory_map
Wii U (wiiu)
Memory Bank | Start | Length |
---|---|---|
MEM2 PID 7 - Foreground app | 0x50000000 | 0x40000000 (1 GB) |
-
Endianness: Big
-
Pointer length: 4 bytes
Cemu
0x7FF6A6FE6438
aka Cemu.rplModuleCount+950
is the process memory address that contains a 64bit pointer to the beginning of Wii U foreground app memory in the most recent version of Cemu (1.26.2f). For example, if this pointer has the value 0x2279A900000
and Super Mario 3D World's coins counter is at address 0x36D3EA3C
then the final address in the process is 0x227D163EA3C
.
The memory viewer in Cemu starts at 0x10000000
for some reason but extends for the full 1GB to 0x4FFFFFFF
. Not sure what's up with that; found addresses may need correction in the future.
Find this starting address in other versions by using Cheat Engine to find the coins, scan for writes, and look in R13 after getting some coins. Then, search for the value R13 has as a 64-bit integer and look at the bottom of the results list.
References
- https://wiiubrew.org/wiki/Memory_map
Nintendo 3DS (3ds)
Memory Bank | Start | Length |
---|---|---|
FCRAM | 0x20000000 | 0x08000000 (128 MB) |
FCRAM (New_3DS extension) | 0x28000000 | 0x08000000 (128 MB) |
-
Endianness: Little
-
Pointer length: 4 bytes
References
- https://www.3dbrew.org/wiki/Memory_layout