Curious hacker path
Memory Wars
Two megabytes is enough only after you stop spending it twice.
The PS1 has 2 MB of main RAM, 1 MB of VRAM, and 512 KB of SPU RAM. Those numbers sound generous until you try to carry a desktop interpreter, decoded art, scene state, audio, overlays, and a CD streaming buffer at the same time.
The early port treated memory like a problem to optimize later. The working port treats memory like the architecture.
The Shape Of The Budget
Main RAM holds runtime code, pack buffers, control state, captions, holiday metadata, and the current foreground replay data. VRAM holds backgrounds, sprite banks, CLUTs, and transient uploads. SPU RAM holds all VAG sound effects preloaded at boot because late audio streaming would fight the scene timing. The CD drive is slow enough that layout and prefetch matter even when a file is small.
That is why the project has separate pages for hardware, performance, audio, and formats. They are not isolated topics; they are the same budget seen from different angles.
What Worked
The big unlock was the hybrid replay pipeline. Running Sierra’s bytecode live would keep too many possibilities resident at once. Captured foreground packs turn each scene into a narrow contract: load this pack, replay these frames, fire these sound cues. The PS1 no longer needs to be a general-purpose Sierra engine.
Other practical wins were smaller:
- Preload the VAG sound set and rotate SPU voices.
- Keep overlays tiny and indexed.
- Use generated tables for holiday data and scene routing.
- Make pack formats dumpable, because “out of memory” without a file-level explanation is just folklore.
- Treat VRAM allocation as explicit state, not as a magical side effect of drawing.
- Drop optional prefetch buffers when a large
clean-rect
snapshot would otherwise fragment the heap. The
v0.8.0 clean-memory-relief drop-prefetch
pass made this a per-scene opt-in for fourteen random-position
scenes; the
v0.8.1 generalization
centralized the pressure estimator after a randomized soak found a
MARY 4scene-load freeze the per-commit matrix never reached.
The resource catalog is the public map of the files competing for space. The source library preserves the older memory notes and false starts.
The Lesson
On a small machine, “can I compute this?” is usually the wrong first question. The better question is: where does the data live when nobody is looking at it? The PS1 port started working when the answer stopped being “everywhere.”
Related pages
- Hack: start here — first-day flow if you haven’t already done the build and boot loop.
- Hack: learn C from Johnny — the ownership-and-explicit-state habits that make the budget above tractable in C.
- Hack: visual debugging — most fragmentation and clean-rect regressions surfaced through the screenshot loop, not text logs.
- Hack: performance loop — the matrix that grades every memory change against the same target-speed bar.
- Hack: port to a new platform — what changes when 2 MB / 1 MB / 512 KB becomes some other envelope.
- Hardware — the canonical envelope reference: bus widths, SPU RAM sectors, CD seek timing, VRAM frame layout.
- Performance reference
— where each
loop_vb/target_vb/blocking_vbcolumn comes from and how memory pressure shows up in those columns. - Story-loop walks — the persistent clean buffer named in the v0.8.0 / v0.8.1 Evolution-by-release section is a direct response to this page’s “VRAM allocation as explicit state” rule.
- Lab: from 87 to 99.5 — the post-validation performance retrospective whose single biggest unlock was the drop-prefetch experiment: trading streaming headroom for the clean-rect bytes the budget on this page tracks. Cited inline above; surfaced here as a Related entry too.
- v0.8.1 retrospective — the soak loop that found the clean-rect pressure freeze, driven by exactly the budget-overrun story above.
- Glossary: clean-rect · Glossary: VRAM · Glossary: SPU · Glossary: drop-prefetch