A Practical Map of the Original PlayStation
The original PlayStation is a group of specialized processors connected by narrow, explicit data paths. The CPU runs game code, the GTE accelerates geometry math, the GPU draws 2D primitives, the SPU plays sound, and the CD-ROM supplies data that cannot remain in memory.
Understanding those boundaries explains most PS1 engine decisions. The machine is fast when work is prepared for the right unit and expensive when the CPU has to compensate for a poor data layout.
The Hardware at a Glance
| Part | Relevant capability | Engine consequence |
|---|---|---|
| CPU | Customized 32-bit R3000A-class RISC processor at 33.8688 MHz | Gameplay and orchestration need short, predictable paths |
| Main RAM | 2 MB | Runtime code, scene data, meshes, Lua, collision, and transient buffers compete directly |
| GTE | Fixed-point vector, matrix, projection, and lighting coprocessor | Transform data must fit its numeric range and instruction model |
| GPU | Polygon, sprite, line, image-transfer, blending, and dithering commands | The CPU submits packets; the GPU does not consume a modern vertex buffer |
| VRAM | 1 MB, arranged as a 1024 x 512 field of 16-bit words | Display buffers, textures, and color lookup tables share one layout |
| SPU | 24 ADPCM voices with 512 KB of sound RAM | Resident effects must be compressed and budgeted separately from streamed audio |
| CD-ROM | Sector-based optical storage | Files are plentiful, but seeking and loading are not free |
The CPU also has a 4 KB instruction cache and a 1 KB scratchpad. Those numbers are small enough that code structure and data locality are part of performance work.
One Frame Crosses Several Systems
A typical 3D frame is not sent to a single graphics API. It moves through a chain:
gameplay and scene traversal on the CPU
-> world/view matrices
-> GTE transform, lighting, and perspective projection
-> screen-space triangles and quads
-> depth buckets in an ordering table
-> GPU command packets in main RAM
-> DMA submission to the GPU
-> rasterization into VRAM
-> video output from the current display area
The GTE does not draw pixels. The GPU does not transform 3D vertices. The ordering table is a CPU-side structure that decides packet submission order. Each unit solves a specific part of the frame.
This separation is why a PS1 renderer needs more than a triangle loop. It needs bounded packet memory, numeric conversion, clipping, culling, ordering policy, double buffering, and a VRAM layout that remains valid for the entire frame.
Memory Is Split by Purpose
The PS1 has no unified memory pool.
- Main RAM holds executable code and live game data.
- VRAM holds display areas, texture pixels, and CLUT data.
- SPU RAM holds resident ADPCM samples.
- CD-ROM holds the complete game but behaves as storage, not working memory.
Moving data between these domains is an operation. Textures are uploaded to VRAM. VAG samples are transferred to SPU RAM. Scene and asset files are read from disc into bounded main-memory buffers.
An engine therefore needs several budgets at once. A scene can fit in main RAM and still fail because its textures do not pack into VRAM. It can fit both and still exhaust SPU RAM with resident audio.
Fixed Point Is Part of the Architecture
The console does not include the usual floating-point coprocessor. A compiler can provide software floating point, but it is a poor default for frame-critical work. PS1 graphics code instead relies heavily on integer and fixed-point representations.
Fixed point is not merely a performance trick. It changes the failure modes:
- values have explicit scale and range,
- multiplication needs wider intermediates or careful shifts,
- projection can saturate,
- world coordinates can overflow the range expected by the GTE,
- vertices snap to the integer screen grid.
Polygon Engine keeps editor transforms convenient on Windows, then converts and validates them for the runtime. Geometry that approaches unsafe projection ranges uses a guarded clipping/projection path instead of trusting saturated GTE output.
Why Polygon Engine Does More Work Before Boot
The Windows editor has memory, file-system access, descriptive errors, and enough CPU time for conversion. The console should receive compact data that already respects runtime limits.
Polygon Engine uses that asymmetry deliberately:
Windows editor -> import, author, inspect
Build pipeline -> validate, quantize, bake, stage, package
PS1 runtime -> load bounded data and execute the game
This is the central architectural rule of the engine. Flexible source data stays on the development machine. Predictable binary data goes to the console.
The result is not an attempt to hide the PlayStation. It is a workflow that exposes the constraints early enough to act on them.