The CD-ROM Is Not Extra RAM

A PlayStation disc can hold hundreds of megabytes while the console has only 2 MB of main RAM. That contrast defines the asset pipeline: the disc stores the game, but the runtime still needs explicit loading, bounded buffers, and a plan for seek latency.

The CD-ROM is capacity, not working memory.

Sector-Based Storage

Data files are read in sectors. A common data-sector payload is 2,048 bytes, so runtime reads naturally operate in sector-sized units even when a file is not an exact multiple of that size.

This has practical consequences:

• small files still require directory lookup and sector access,
• unrelated files placed far apart can increase seeking,
• loading directly inside a frame update can create visible stalls,
• buffers need room for aligned reads and decoded output,
• filenames must match the disc filesystem and toolchain rules.

Polygon Engine uses short, deterministic disc names and an ISO-friendly directory layout. Human-readable source paths remain in the project; staged runtime paths are compact.

The Staged Disc

The build output is organized around a small runtime manifest:

disc_root/
  SYSTEM.CNF
  POLYGON.EXE
  DATA/
    MANIFEST.JSN
    S/  binary scenes
    L/  Lua scripts
    M/  meshes
    R/  materials
    T/  textures
    A/  resident audio
    X/  XA music

SYSTEM.CNF identifies the executable and boot settings. MANIFEST.JSN maps scene names and asset GUIDs to their final disc paths.

The manifest prevents the runtime from reproducing editor logic. It does not scan Assets/, parse import metadata, or guess which file belongs to a GUID. The Windows build resolves those relationships and fails before packaging when a required reference is missing.

Loading Is a Runtime State

Reading a scene is not a normal pointer lookup. The runtime has to:

1. find the manifest entry,
2. locate the disc file,
3. read it into a bounded buffer,
4. validate its header and size,
5. rebuild runtime tables,
6. upload textures or audio to their dedicated memory,
7. resume gameplay only when the state is coherent.

Polygon Engine uses an explicit loading screen during scene transitions. This makes the stall visible and gives the CD subsystem room to complete work without pretending that arbitrary asset access is instantaneous.

The current binary scene read buffer is 160 KB; the manifest text buffer is 16 KB. Those limits are shared by build validation and runtime code.

Resident VAG vs Streamed XA

The PS1 offers two different audio paths that solve different problems.

Resident effects are imported from WAV, converted to VAG ADPCM, copied into SPU RAM, and played through SPU voices. They have low playback latency but compete for the 512 KB sound buffer.

Streaming music is encoded as CD-XA data and read from the disc while it plays. It avoids storing an entire music track in SPU RAM, but it occupies the CD data path.

Polygon Engine exposes both paths:

Use	Import/runtime path	Main constraint
Short effects, loops, voices	WAV -> VAG -> SPU RAM	Sound-memory budget and voice use
Long music	WAV -> XA -> CD streaming	Disc bandwidth, seeking, and track limit

The current runtime supports up to 16 resident audio clips and 8 XA music tracks. These are bounded engine tables.

During a scene load, Polygon Engine suspends XA playback, performs the disc work, and then restarts the suspended track from its beginning. That policy avoids making the CD-ROM serve two incompatible access patterns at the same moment.

Packaging Is Part of Correctness

The staged files still need a valid disc image. Polygon Engine uses mkpsxiso to generate the package artifacts, including .bin, .cue, and .iso outputs.

The .cue describes the track layout used with the binary image. It is the primary artifact for emulator testing and physical-disc workflows. The standalone .iso is useful for inspection and compatible tools, but it does not replace every track-layout use case.

The package also includes burn guidance because file generation and hardware use are separate concerns. A build that boots in DuckStation proves that the executable and disc structure are coherent. Real hardware remains the final check for media, timing, and drive behavior.

The Engine Lesson

Disc architecture reaches far into the editor:

• stable GUIDs make renaming source files safe,
• import metadata records the compiled artifact,
• build validation catches missing references,
• the manifest keeps runtime lookup small,
• loading screens acknowledge physical latency,
• XA streaming and scene loading coordinate access to the same device.

On PS1, the asset database is not only an editor convenience. It is the front end of a storage system that ends at an optical drive.

Continue Reading

• From Editor JSON to PS1 Runtime Data
• Assets, Audio, Lighting, and the Budgets Behind Them
• What It Takes to Ship a PS1 Project from an Editor

Updated for Polygon Engine 0.1.0-ea.2.