How the layers stack

At a glance

• Almost everything is in one file. PROT.DAT is the game's archive: 1233 numbered entries holding every scene, monster, tune and menu. The executable only carries the tables that tie them together.
• Each layer has one owner. One Rust crate reads the disc, one splits the archive, one sorts entries by format, and one small crate per format decodes it. That is what lets the browser pages and the native tools share code.
• The game runs on scripts. Towns, cutscenes, battle moves, menus and NPC pathing are bytecode interpreted by a family of small virtual machines. The engine port reimplements those VMs rather than emulating the CPU.
• Two tracks, one repo. Preservation (extract and document every asset) and reimplementation (a from-scratch engine) feed each other: the docs are the spec the engine is built from, and the engine is the test that the docs are right.

The pipeline

Going top to bottom: a PSX disc image, then the ISO filesystem, then the archive (PROT.DAT), then per-entry containers, then individual sub-assets, and finally the engine that brings them to life. Click any layer to read its format page or the crate that handles it.

Two tracks, one repo

The -re in the project name means both reverse engineering and reimplementation. The tracks are separate crates with a clear boundary between them.

What keeps the two honest is a set of parity oracles: the engine's video memory, sound output and game-mode trace are compared against emulator captures of the real game, so a doc that is wrong shows up as a pixel or a sample that differs. The engine page has the boundaries and the current list of enhancement toggles.

The runtime VMs

When you talk to a villager, watch a cutscene, throw a Tactical Art or open the shop, no hand-written code for that moment is running. Instead the game's engine interprets small programs stored with the data: the villager's dialogue is a script, the art is a move record, the shop window is a widget program. The five interpreters below share one actor model - the same records describe your character, an NPC, a monster and a spark of a spell - and each has its own page. Four are classic bytecode dispatchers; the effect VM is a per-slot state machine that plays the same role with a different shape.

"Five VMs" is the orientation, not the census: the field VM's menu sub-dispatcher, the move VM's overlay extension, and the battle, world-map and tile-board state machines are separate dispatchers with their own tables. The VM inventory lists every one.

How they wire together

The field VM drives the scene. When it needs an actor to perform something, it stages a move record into that actor, and the per-frame actor tick steps the move VM through it. One move-VM opcode escapes into an overlay-resident extension dispatcher that exists only while the town overlay is loaded, so battle-side move records can never reach it. The motion VMs run independently per actor for pathing and camera follow. The effect VM is battle-only, but every effect is bound to a master-slot actor that the script VM and the battle state machine can reference - the same actor model throughout. Driver addresses and traces are on the linked subsystem pages.

Where to go next