PS1 Hardware Architecture
Polygon Engine targets the original PlayStation execution model rather than a modern renderer with a PS1 visual filter. Understanding the data path explains why the editor exposes budgets, why geometry must be segmented, and why the build creates several target-specific asset formats.
System Map
CD-ROM
-> main RAM (executable, scene data, meshes, Lua, staging buffers)
-> CPU + GTE (gameplay, fixed-point transforms, lighting, projection)
-> GPU command packets and ordering table
-> VRAM (framebuffers, texture pages, CLUTs)
CD-XA stream -----------------------------------------------> SPU output
VAG samples -> SPU RAM -> SPU voices -----------------------> SPU output
Controller / memory card <-> serial I/O <------------------> gameplay and saves
CPU and GTE
The console uses a 33.8688 MHz MIPS R3000A-compatible CPU and has no hardware floating-point unit. The Geometry Transformation Engine (GTE) is a fixed-point coprocessor for transforms, projection, clipping support, and lighting math.
Polygon Engine converts authored floating-point data into bounded runtime values and uses PS1-safe transform and clipping paths. Very large coordinates, extreme scale, and geometry crossing the camera plane can still lose precision or create unstable projections, so level scale is a production constraint, not just an artistic preference.
GPU and Ordering Tables
The GPU consumes drawing commands for triangles, quads, sprites, and other 2D primitives. It does not provide a z-buffer. A game must submit primitives in a useful order, commonly through an ordering table whose buckets approximate depth.
This has three important consequences:
- Intersecting or coplanar surfaces do not receive reliable per-pixel depth resolution.
- A large polygon can span several depths but occupy only one ordering-table bucket.
- Texture coordinates are interpolated affinely, without perspective correction, so large textured polygons distort more visibly.
Polygon Engine clips unsafe geometry against the near, far, left, right, top, and bottom view boundaries before submitting GPU coordinates, then sorts the surviving primitives. Asset authoring remains part of the solution: segment floors and walls, avoid coplanar overlays, and isolate transparent surfaces. See Rendering and Level Authoring.
Memory Domains
The three principal memory pools are independent:
| Memory | Hardware total | Main contents |
|---|---|---|
| Main RAM | 2 MB | Runtime code, scene state, meshes, Lua, CD and render buffers |
| VRAM | 1 MB | Framebuffers, texture pages, and color lookup tables (CLUTs) |
| SPU RAM | 512 KB | Resident VAG samples and audio working data |
Free space in one pool cannot compensate for an overflow in another. A small mesh does not make room for an oversized texture page, and streamed CD-XA music does not consume the resident VAG sample budget. Use the PS1 Budget Dashboard to inspect each domain separately.
CD-ROM and Runtime Data
The CD-ROM is high-capacity storage, not random-access working memory. File
seeks and transfers are much slower than RAM access. Polygon Engine therefore
stages compact paths under DATA/, writes a small manifest, groups each scene
and its ordered dependencies into a sector-aligned sequential bundle, loads
scene assets into bounded caches, and reserves transient buffers for scene
changes. Loose staged paths remain available when a bundle cannot be mounted.
Streaming music follows a separate CD-XA path. While the stream is active, the runtime coordinates CD access around scene loading and then restarts the suspended track from its beginning. Short sound effects use resident VAG data instead. See Audio Import for the authoring choice.
Scene transitions process CD reads, decoding, texture/SPU uploads, and component initialization in bounded work units while the loading display is active. See Scene Management for the user-facing transition contract.
What This Means for an Engine Project
- Treat validation limits as part of content design, not a final export check.
- Build modular geometry whose surfaces have unambiguous ordering.
- Budget main RAM, VRAM, SPU RAM, packet memory, and CD data independently.
- Test the generated CUE in DuckStation and on hardware when possible; editor Play Mode is a workflow preview, not the final renderer.
- Use post-bake reports as the authority because they measure staged PS1 data, not only source assets.
Continue with PS1 Hardware Constraints and Budgets for the current engine limits and Runtime Limits for the fixed-size runtime tables.