Grand Theft Auto: Vice City – The Definitive Edition (PPSA03530)

[akkadbakkad89]

Grand Theft Auto: Vice City – The Definitive Edition (PPSA03530)

Title bring-up notes. Decrypted v01.00 dump, APS5_PLAYGO_UNLISTED_CHUNKS=installed. Relinks cleanly (6 modules, ~8800 imports) and starts UE4 init — currently blocked during early memory setup. Sharing findings so far; work in progress.

Boot chain (what works)

• eboot + sce_module SELFs unwrap and relink with no missing-import errors.
• sceKernelOpen /app0/ue4commandline.txt → ../../../Gameface/Gameface.uproject; the dump ships gameface/ (content + platforms) but no Gameface.uproject — the title logs Project file not found and continues anyway, so this is probably not fatal.
• All guest memory activity is direct memory, memory_type=12 — zero flexible-memory calls, zero anon mmaps. The whole heap lives in the direct pool.

Blocker 1 — contiguous arena grab

The game's very first big call is sceKernelAllocateDirectMemory(0, GetDirectMemorySize()) — it wants the entire reported size (13.5 GiB) as one contiguous phys block. With pool == reported (13.5 GiB), the early allocs it makes first (32 KiB + ~300 MiB + a few MiB, all low phys) fragment the range → the ask fails → it bisection-probes, drains ~13.2 GiB into fragments, then its own arena OOMs on a ~5.2 GiB request (Ran out of memory allocating 5565054976).

Empirical: physical pool > reported size lets the contiguous ask succeed (physical 14–16 GiB with reported 13.5 GiB — matching a real console's 16 GiB RAM vs ~13.5 GiB reported).

Blocker 2 — guest phys-page bitmap fencepost

With pool > ~15.7 GiB the guest crashes at read of 0x9000008000 — one page past the 32 KiB block it mapped at 0x9000000000. Disassembly shows libc.guest's phys-page bitmap (64 KiB granule, window addend +65 qwords): it frees the unused tail [top_alloc, ceiling) where its ceiling is ~0x3F0000000 — the bitmap buffer covers exactly 4096 qwords and it accesses index 4096. A console-compatible workaround that got past it: minimum direct-alloc granule 64 KiB + remap covering the whole phys block, so the guest's own bitmap storage is 64 KiB.

Blocker 3 — remap storm (performance, fixed)

The guest then builds its arena alias by re-mapping a sliding 64 KiB-stepped window: ~216k remap fixed calls each covering ~13.5 GiB (va_i..end ← phys_i..end). Each call is semantically a no-op for the sub-range (phys already aligned) but our per-page phys bookkeeping walked ~880k std::map nodes per call — O(n²), effectively a hang.

Two fixes got this from ~40 calls then death → storm completes:

• block-level phys index (g_physBlocks, one entry per _commit with split-on-partial-free) so ValidatePhysicalRange/AddMapping run O(#blocks) instead of O(#16K-pages); per-page map stays only for the Linux shared-backing paths.
• no-op shortcut: skip the OS teardown/rebuild when the target range is already covered by a mapping with identical phys alignment.

Current wall — guest-internal OOM

Arena builds fine now; the guest then dies inside its own sub-allocator:

AvailablePhysical: 10616176640
UsedPhysical:      6249054208
Ran out of memory allocating 2943483904 bytes with alignment 0

Used is constant (5.8 GiB) across pool sizes 14/15/16 GiB; Available scales with the pool — i.e. these are the guest's internal arena numbers, not kernel answers (it never calls sceKernelAvailableDirectMemorySize). The 2.7 GiB request never reaches a kernel API — its free space exists but is fragmented across the bisection-fill blocks. Under investigation: whether a different phys layout (console hands out different base addresses) or the fill pattern is what makes its largest contiguous run ≥ 2.7 GiB on real hardware.

Call trace (compressed, pool=16 GiB, reported=13.5 GiB)

alloc direct len=0x8000   type=12 -> phys=0x0          # phys-page bitmap
remap fixed 0x9000000000+0x10000 phys=0x0            # (with block-cover fix)
alloc direct len=0x12c00000       -> phys=0x10000    # ~300 MiB early grab
alloc direct len=0x360000000      -> phys=0x12c10000 # contiguous 13.5 GiB arena
alloc direct (bisection fills: 0x6c000000, 0x36000000, ... down to 0x10000)
release physical 0x10000+0x12c00000                  # frees the 300 MiB
remap fixed 0x1000000000+0x360000000 phys=0x12c10000 # arena alias storm begins
... ~216k sliding remaps ...
remap fixed <scattered> prot=0xf2 phys=<various>     # heap commits
-> guest abort: Ran out of memory allocating 2943483904

Working branch carries diagnostics + the block-index/map-cover changes; nothing is upstream-ready yet — the remaining question is whether the current OOM is a real guest-fragmentation limit that console layout avoids, or still a kernel-semantic gap on our side.

[akkadbakkad89]

Status update + the questions I'd like reviewed before I build more on top of this.

The remap-storm blocker turned out to be a real kernel-side scalability bug — filed as #10521 with the fix direction (block-level phys index + identical-mapping no-op). With that in, the title now completes its entire arena setup and reaches UE4 init.

Where it stands now — guest-internal OOM

AvailablePhysical: 10616176640   (pool=16 GiB run)
UsedPhysical:      6249054208
Ran out of memory allocating 2943483904 bytes with alignment 0

These numbers are the guest's own arena ledger, not kernel answers — it never calls sceKernelAvailableDirectMemorySize. UsedPhysical is constant (~5.8 GiB) across every pool size I tried; AvailablePhysical scales with the pool. The 2.7 GiB request never reaches a kernel API — its internal free space exists but no single contiguous run ≥ 2.7 GiB survives its own probe/bisection fill.

Levers tested (all reproduce the same OOM)

lever	result
pool 13.5 GiB (=reported)	contiguous ask fails → bisection fill → OOM on 5.18 GiB (worse)
pool 14/15/15.75/16/20 GiB, reported 13.5	contiguous ask succeeds → arena builds → OOM on 2.7 GiB
reported 20 GiB, pool 16	contiguous ask scales up → OOM
phys floor 1 GiB (low phys reserved)	ledger shifts (used 5.8→4.6) → still OOM on 2.7 GiB
no flexible calls at all	heap is 100% direct-memory-backed (type=12), ruled out

What I'd like reviewed

1. Pool vs reported semantics. The guest's first move is alloc direct len = sceKernelGetDirectMemorySize() — it wants the reported size as one contiguous phys block. That only works if the physical pool exceeds the reported size. Is the intended model here "physical = 16 GiB real RAM, reported = 13.5 GiB game-visible"? If so DIRECT_MEMORY_SIZE should probably be the physical size and sceKernelGetDirectMemorySize() report something smaller — but which value does the console actually answer (is it title-dependent)?

2. The phys-bitmap fencepost workaround — currently I carry two hypothesis-level changes: a 64 KiB minimum alloc granule, and remap fixed/direct-map covering the whole phys block when the guest maps a sub-range. That got the guest's own phys-page bitmap (fixed ceiling ~0x3F0000000, 32 KiB buffer, reads index 4096) past the crash. Do we know console's real minimum direct-alloc granule and whether sceKernelMapDirectMemory maps the block or the asked len?

3. The remaining OOM. Either (a) the guest's own allocator fragmentation — meaning some input we're giving it steers its fill pattern wrongly, or (b) a kernel-semantic gap I haven't found yet (e.g. it expects a phys ceiling, a second type-range, or an aliasing call to behave differently — sceKernelEnableDmemAliasing is currently a stub returning 0). Open to pointers on which direction to dig before more guessing.

Full call trace and per-blocker evidence in the top comment. Working tree carries the diagnostics + block-index/map-cover changes — nothing upstream-ready yet pending the answers above.

[rezesferi]

Hey, I'm also testing this game: with APS5_PLAYGO_UNLISTED_CHUNKS=absent it launches and plays for me, but without it - doesnt even start.

[akkadbakkad89]

Confirmed on our side — RTX 3070 (driver 617.42), Windows 11, main-era lib build, same dump (PPSA03530).

With APS5_PLAYGO_UNLISTED_CHUNKS=absent the title ran 3+ minutes straight: Vulkan device up, ~2400 shader-disk-cache writes, steady ~5.2 GiB host RSS, no OOM, no fatal exit (I stopped it manually). That matches your result — it gets well past startup.

The contrast is diagnostic: our earlier runs used =installed, which reports all chunk ids 0–999 as installed, and the title died in <1 s on the guest-internal 2.7 GiB contiguous arena alloc (UsedPhysical ~5.8 GiB). So the OOM we documented is triggered by the all-chunks-installed answer — the title presumably enumerates that full id set and sizes/reserves its streaming accordingly. With =absent the chunk-id walk ends early (BAD_CHUNK_ID) and the title never takes that allocation path.

So: the 2.7 GiB guest OOM is not a hard blocker — it's contingent on the playgo answer. Whether the =installed arena behavior is itself a kernel-emulation bug or correct UE4 behavior on console remains open, but =absent unblocks gameplay testing for this dump. Thanks for the datapoint — re-running the memory-lever matrix under =absent now.

[ashwin280802]

Controlled Resume Game A/B (2026-10-26)

I ran the same existing Resume Game save in two isolated Vice City stage folders. Both used the same eboot.elf (SHA-256 E124D368711E89C0B0801B8C9A148A8280ED7A177399C3E4040F3D7A92FF3119); the six converted guest PRX inputs were byte-identical between stages. Both relinks used --windows --registry --frame-red-zone, the same runtime-library build (0119103fa9ed), and the same environment, including APS5_PLAYGO_UNLISTED_CHUNKS=absent. This A/B compares the relinker output; it does not compare the separate installed PlayGo setting discussed above.

Machine: Windows 10.0.26300; Intel Core i5-14600K; NVIDIA GeForce RTX 5070, driver 617.42; 3840x2160. Deep tracing was enabled in both runs: all import calls, memory, GPU, draws, and draw profiling. No trace records were dropped.

Baseline

• Relinker: origin/main at 7a25f87620a9b862dc194dd0f659686b0f6cc8b0.
• Executable SHA-256: 8AC15DB3B38DBB79D29B664C72BC6A2CC3FA48D86EA1C4C069A2E0D44665AA71.
• After selecting Resume Game, it failed before gameplay with 0xc0000005 on PoolThread 2: write to address zero at app.exe+0x1819e. The dump also showed invalid distance code; a nearby return-address candidate was app.exe+0x1684b.
• The run produced about 7.1 MiB of traces, with summaries through 180.6 seconds.

Red-zone branch

• Relinker: fix/relinker-frame-red-zone-trailing-branch at 060a8a5db78f7eac67eb7101349ebfea593cdca5.
• Executable SHA-256: A16D12B52BF76FF3DB544176D898260D0F66EEA80BA27E50B3658891D1702F86.
• After selecting Resume Game, it reached gameplay (observed around frame 180). I left it running for about 32 minutes, then exited normally; the process returned code 0. The completed stderr has no fatal exception, access-violation, or invalid distance code signature.
• The run produced about 65.3 MiB of traces. The final summary interval recorded one present in 31.9 seconds; deep tracing made the game unusably slow. This is not a performance comparison or a claim that normal-speed gameplay is validated.

Relinker report and interpretation

For this same ELF and --frame-red-zone, the baseline relinker scanned 253,364 functions and 1,447 red-zone leaves, and framed 323. The red-zone branch scanned the same counts and framed 1,142. This shows that the branch applies substantially broader red-zone framing to this executable. Combined with the baseline crash and the fix build reaching gameplay on the same save, this is strong evidence that the previous Resume Game blocker did not reproduce with the fix build. It is one A/B run; it does not establish the precise instruction-level root cause or prove stability through extended, normal-speed play.

The PlayGo setting was absent in both runs. The separate behavior when all chunks are marked installed, including the guest-internal OOM described in the opening post, was not retested or resolved by this experiment. The full trace folders were subsequently removed during stage cleanup; the measured results above remain in this comment, but the raw trace logs are no longer retained locally.

No PR is being opened at this point; I will wait for the overlapping red-zone PRs to settle before proposing any follow-up.