PSX RAM map

At a glance

Main RAM

2 MB at 0x80000000..0x801FFFFF. Nothing above it: 0x80200000+ only mirrors RAM on a retail console.

Executable

SCUS_942.54 loads at 0x80010000 and is 0x6B800 bytes (430 KB): tables, then code from main() at 0x80015E90, then data. It ends at 0x8007B800.

gp

0x8007B318 - most globals are reached as imm(gp), which an absolute-address search never sees.

Save block

0x80084140..0x80085B57, the 0x1A18 bytes a save copies: character records at 0x80084708 + n*0x414, flag bank 0x80085758, item bag 0x80085958.

Heap

0x80091800..0x801C5FFF (InitHeap(0x80091800, 0x134800)): scene bundles, models, the battle context and actor pool.

Overlays

Slot A at 0x801CE818 (field, battle, menu, minigames - one at a time); slot B at 0x801F69D8 (summon / cast modules, world-map render).

Stack

Starts at 0x80200000 (the startup code replaces the header's 0x801FFFF0) and grows down.

Full table

docs/reference/memory-map.md - every row, in the same region order; grep it for your address

The address space

Drawn to scale, low addresses on the left. Click a region to jump to its section.

How to read an address

• Every address is a PSX virtual address. Main RAM starts at 0x80000000, so 0x80084708 is byte 0x84708 into the 2 MB. DAT_8007B83C is Ghidra's automatic label for data at that address, the way FUN_8003E4E8 labels a function (key functions).
• The executable is only the bottom of the picture. Its data holds the persistent state, but most game logic lives in overlays streamed off the disc per game mode.
• An overlay address is ambiguous on its own. Every slot-A image links at 0x801CE818 and only one is resident, so the same address means different things in field, battle and menu mode. The overlay rows below say which image they belong to.
• A heap address is a snapshot. It depends on the allocation order; the ones listed are those that stay put across the captured states.
• 0x1F800000 is not main RAM. It is the scratchpad, and a flag a script tests may live there.

Kernel and executable

The first 64 KB belong to the BIOS - exception vectors at 0x80000080, the kernel's tables and work area - and the game only reaches them through the BIOS call vectors. One kernel word is game state all the same: 0x80009010 is the BIOS rand() seed every random draw in the game steps, so a save state's word there is where the game's one random stream stands. SCUS_942.54 follows at 0x80010000: 24 KB of tables, the code from main() up, then the data segment.

Data segment and gp block

The executable's initialised data: the static game tables, then the gp small-data block from 0x8007B318, which runs past the image end into the work area. These mean the same thing in every mode.

Static work area and the save block

From the image end at 0x8007B800 to the heap base is uninitialised global storage - the executable declares no BSS, so a cell here holds only what the code stores. It holds, in order, the rest of the gp block, the actor and mesh tables, the save block and the work buffers above it.

Mode, pad and battle globals

80015f00  jal  0x8003F084      ; two-instruction leaf: returns 1
80015f04  nop
80015f08  sh   v0,0x5aa(gp)    ; gp = 0x8007B318, so EA = 0x8007B8C2

Actor and mesh tables

The save block (0x80084140..0x80085B57)

The live game state a save is composed from - the save write copies these 0x1A18 bytes, so a save-block offset is VA - 0x80084140 (save screen).

Work buffers

Heap

main() hands 0x80091800..0x801C5FFF to InitHeap, and the allocator serves scene bundles, model packs, sound banks and the battle structures out of it. A heap address belongs to the allocation order, not to the program; these are the ones that stay put across the captured states.

Resident buffers

The 34 KB between the heap and the overlay base are fixed buffers that survive every mode change - which is why an overlay can hand data to its successor here.

Overlay slot A (0x801CE818)

The per-mode code window. Every image links at 0x801CE818, each mode's INIT handler streams its PROT entry in, and only one is resident - the same address is a dialog routine in the field and the battle state machine in battle. The pause menu replaces the field overlay at the same base.

Field overlay (PROT 0897)

Battle overlay (PROT 0898)

Menu and title overlay (PROT 0899)

Boot, movies and minigames

PROT 0896 links at 0x801D4DF0, not at the slot base, and nothing on this disc loads it.

Overlay slot B (0x801F69D8)

One small module at a time above slot A: PROT 0900 (screen-effect widgets), 0901 (world-map render), 0967..0969 (battle tutorial and boss stages), 0978 (the staged background loader) and the 64 summon / cast images 0903..0966, the largest 0x4000 bytes. The band starts inside the battle image's extent, so a module loaded in the field has its head overwritten when the battle overlay comes in (cast module).

Free RAM and the stack

Above the largest slot-B image nothing is loaded. The stack starts at 0x80200000 and grows down; interrupt callbacks run on their own stack at 0x8007A7F0, and the render pass moves onto the scratchpad, so only the main thread's own calls land here. A canary fill over the band measures how deep they go: 0x801FE420 (7,136 bytes) once at boot, while FUN_8001D8FC reads CDNAME.TXT into a 4 KB stack buffer, and never below 0x801FF138 after it - the FMV decoder, which reserves a per-frame macroblock table on the stack. Battles stay above 0x801FFD30, scene loads and card saves above 0x801FFA20, the minigames above 0x801FFA88 bar the dance contest, whose hall load reaches 0x801FF9E0. 0x801FD000..0x801FE000 is therefore free, which is why the disc patcher parks injected code there (randomizer).

No code on the disc builds an address from 0x801FA9D8 up; the stack top comes from a data word. The loader reads exactly as many sectors as the PROT table of contents gives, so a larger PROT 0900 / 0901 would carry its extra bytes into this space on every field load, and they would stay until power-off. The catch is that those two entries have no spare room on the disc, so growing them means moving every later PROT entry, which a same-size patch cannot do. In the same way, while the field or menu overlay is loaded, the range 0x801F3818..0x801F69D7 only holds leftovers from whichever image last used it.

Scratchpad (0x1F800000..0x1F8003FF)

1 KB of fast on-chip RAM outside the 2 MB. Most cells from 0x1F80035C up are displacements off 0x1F800314 (lui 0x1F80; ori 0x314), so an absolute-address scan never sees them.

Above the scratchpad are the hardware registers - DMA at 0x1F801080..0x1F8010F0, GPU at 0x1F801810, MDEC at 0x1F801820, SPU from 0x1F801C00. The game reaches them through the PsyQ libraries; only the movie player keeps a pointer block to them in its own data.

How we know

Ghidra's reference manager does not resolve MIPS lui+addiu pairs or gp-relative stores, so most rows were pinned by a writer hunt (Ghidra tooling), a save-state diff, or a cheat code that names the cell. The region boundaries come from the executable's header and the overlays' own call graphs.

See also