Skip to main content
How Can We Help?
< All Topics
Print

PSP Memory Model for Static Recompilation

Posted
Updated
ByJstar269

Type: REFERENCE   Status: MAINTAINED   Scope: PSP address spaces, memory regions, and host translation

A static recompiler needs a platform memory model before it needs a clever allocator. The PSP exposes main RAM, VRAM/eDRAM, scratchpad, aliases, privileged regions, and device/MMIO boundaries. A host arena can implement a useful subset, but it is an implementation technique—not the PSP physical map.

How We Know

guest address
   |
   +--> PSP RAM / VRAM / scratchpad / privileged region
   |
   +--> validate whole span and permissions
   |
   '--> host pointer translation
          |
          '--> CPU-visible bytes
          '--> GPU-visible resource / ownership transition
Source-owned conceptual memory-ownership diagram.

Named regions, not one flat “RAM”

PRIOR ART: current public PSP hardware references document a 16 KiB scratchpad around 0x00010000, a 2 MiB GE VRAM/eDRAM range around 0x04000000, and the baseline kernel/user RAM ranges beginning at 0x08000000. Later PSP models have different physical RAM capacity; a title’s observed address use and firmware/model scope matter.

Do not collapse VRAM into ordinary user RAM in the explanation. CPU-visible framebuffer bytes, GE render targets, depth buffers, textures, and host GPU images can require explicit ownership and synchronization.

Aliases and privilege

High address bits can select cached/uncached and privilege mappings of the same physical memory. A runtime may normalize accepted aliases into one arena, but it must define that normalization instead of blindly masking every 32-bit address. Kernel-only or MMIO addresses should not become accessible merely because the host process can dereference them.

Whole-span validation

IMPLEMENTATION FACT: the current Nakagawa helpers validate the complete multi-byte span with overflow-safe arithmetic. A starting-address check alone is insufficient: a 4-byte read near the arena end can pass the first-byte test and still cross the allocation boundary.

  • Validate readable/writable extent before copying.
  • Check size arithmetic before computing the end address.
  • Keep zero-size behavior explicit.
  • Reject invalid input before partial guest or host side effects where the PSP contract permits.

See Failure Atomicity in Guest Memory Access for the failure-atomicity engineering pattern.

VRAM and cache ownership

VRAM coherency and CPU cache coherency are related but distinct. The CPU can write guest-visible bytes while a host GPU image still contains an older snapshot; a GPU render can become visible to the CPU only after a readback/ownership transition. Likewise, cached/uncached aliases and DMA visibility can affect what a real PSP observes.

The current runtime keeps CPU-visible guest memory and the optional GPU backend in explicit cooperation. The public VRAM/Framebuffer Coherency article documents that boundary without claiming a complete PSP cache oracle.

MMIO and unsupported regions

Hardware registers are not ordinary memory. If a title reaches an MMIO region, the runtime needs a named HLE/device model or a deliberate unsupported result. Mapping the address into the general arena hides the semantic gap and can create unsafe host behavior.

Do Not Infer

  • A host arena does not prove the PSP physical map.
  • One PSP-3001 measurement does not establish every model or firmware.
  • VRAM being addressable does not mean CPU/GPU ownership is automatically coherent.
  • A valid pointer base does not prove a valid bulk span.

Related pages and open questions

Continue to Allegrex Execution Model, PSP Module/PRX Loading, Static Recompilation Architecture, and Open Research Questions. Open gaps include model-specific RAM/alias matrices, cache/DMA visibility, MMIO policy, and safe behavior outside the mapped arena.

Primary sources

Table of Contents