How this section is organised

Pages are grouped the way the disc is layered, outermost first: the disc and its one big archive, then how the game unpacks and routes what it loads, then the bundles a scene or a battle loads as a unit, then single assets by kind, the stat tables baked into the executable and overlays, and the archive entries that hold code. The sidebar uses the same groups in the same order. New here? Start with disc geometry and PROT.DAT - every other page assumes those two.

  1. Disc and archivesectors, PROT.DAT, CDNAME.TXT
  2. Compression and dispatchLZS, chunk streams, packs
  3. Scene and battle bundleswhat a room or a fight loads at once
  4. Textures and modelsTIM, TMD, palettes
  5. Characters and animationmeshes, clip banks, arts
  6. SoundVAB, SEQ, XA, SFX tables
  7. Textdialog, font, place names
  8. Static tablesitems, spells, equipment, move power
  9. Code overlaysMIPS code in archive entries
How the format pages stack. A disc image holds files; PROT.DAT holds numbered entries; an entry is decompressed and routed by type; scene bundles and packs hold many assets; each asset is a texture, mesh, sound bank or script. Beside that chain, the executable holds the stat tables and some archive entries hold code overlays. Disc imagesectors, ISO9660, 45 files PROT.DAT entryone of 1233, named by CDNAME.TXT Unpack and routeLZS decompression, type-byte dispatch Bundles and packsmany assets streamed as one unit Single assetTIM, TMD, VAB, SEQ, MES, ANM ... SCUS_942.54the executable Stat tablesitems, spells, equipment Code overlaysMIPS code in archive entries
The route a byte takes from the disc to something the game can draw or play. Each box jumps to its group below; read top to bottom if you are new, or jump straight to the layer you are debugging.

Each page carries a badge for how solid its decode is. The badge is a claim about evidence, not page length; a page's own confidence row is authoritative over the badge here.

  • Confirmed - traced in the game's own code and verified end-to-end against real on-disc data.
  • Inferred - deduced from byte patterns; structurally consistent but not exhaustively validated.

Disc and archive

The disc image before any in-game format is involved: the sector layout, the one archive that holds nearly everything, the text file that names its contents, and the archive slots that hold nothing. The disc map draws all of it at once - every file and every PROT.DAT entry as nested boxes sized by sector count, each linked back to its page here.

Compression and dispatch

How archive bytes become usable assets: the compression scheme, the chunk stream an entry decompresses to, the type-byte dispatcher that routes each chunk, and the one "many assets in one file" pack layout with its two readers.

Legaia LZS Confirmed
The dictionary compression around most bulk assets - a custom LZSS variant with a 4096-byte zero-initialised ring buffer. Random input decodes without error, so always magic-check the output.
DATA_FIELD streaming Confirmed
The typed-chunk multi-asset container: a chain of (type << 24) | size headers each followed by raw, uncompressed data, ended by a zero-size header. Carries the battle-form character / effect run and a family of scene bundles.
Asset type dispatcher Confirmed
How the game knows what a loaded blob is: an 8-bit type byte (0=TIM, 2=TMD, 4=MES, 5=MOVE, 6=ANM, 7=VDF, 8=SIN, 9=TMD2, B=MOVE2 - the clips ride MOVE, the "ANM" slot holds a CLUT-walk table) routes it to a handler and decides LZS-vs-raw. The type names come from the developers' own error strings.
Asset descriptor format Confirmed
The (type_byte << 24) | size calling convention the dispatcher takes, and the descriptor-pair walker that only runtime overlays call.
Pack format Confirmed
The simplest multi-asset bundle: u32 count + u32 word_offsets[count], then assets back-to-back. Used inside DATA_FIELD streaming chunks.
Standalone TIM-pack Confirmed
A near-identical multi-texture bundle in some standalone PROT entries with different header math (byte_offset = word_index*4 + 4). Includes the boot-UI bundle at the head of the archive.
“Field-pack” Confirmed
Not a format: the 0x01059B84 word is a DATA_FIELD chunk header wrapping an ordinary pack of one scene's textures. The page records how it came to look like a magic number.

Scene and battle bundles

What a scene or a battle loads as a unit - room geometry, textures, scripts and audio together - plus the records that drive encounters, scene transitions and movies, and the battle side-band slots streamed beside them.

Scene bundles Confirmed
The family of per-scene container shapes, each read off its retail walker: battle backdrops, BGM streams, town asset tables, move-VM stager scripts.
Per-scene field map Confirmed
Slot 0 of every scene block, exactly 0x12000 bytes: object descriptors, the collision and floor grid, the per-tile object map and the trigger block.
scene_v12_table Confirmed
Per-scene .PCH walk-on trigger sidecar: a four-kind sub-table directory plus inline 4-byte trigger records, exactly one sector in all 97 scenes. The stager prescript is the next PROT entry.
Encounter record Confirmed
Which monsters you can meet where: three header bytes, a count, and up to four monster ids, armed on a field actor and copied into the battle loader's formation cell.
MAN relocation Confirmed
How to safely resize a record inside a scene's script bundle: fix the partition tables, the section-0 offset, intra-record jump deltas and the external descriptor size. Powers the door randomizer and translation packs.
World-map slot-4 records Confirmed
Slot 4 of each kingdom bundle: the world-map scene's ANM animation bank, the same clip container every field scene carries. Not a mesh library and not the continent terrain.
STR FMV table Confirmed
How the game finds its movies: a 23-slot dispatch table in the cutscene overlay, nine retail slots covering every movie on the disc; per-scene triggers are literal operands in the scene scripts.
Effect bundles Confirmed
The hit sparks and spell flashes of battle: the runtime efect.dat 2-pack (extraction 0873) - a sprite atlas, frame-animation batches and spawn scripts indexed by effect id.
summon.dat / readef.DAT Confirmed
Battle side-band streaming slots (extraction 893 / 894), 0x10800 bytes each: per-special-attack palettes, texture pages, summon-creature actor records and the player art-animation "ME" archives.
Per-scene primitive scratch buffer Inferred
A negative finding: the RAM cluster once read as a navmesh is a per-scene scratch buffer the renderer fills with GPU primitive data on scene entry.

Textures and models

What a single texture or mesh looks like once unpacked, and the palette and picture formats that ride beside them.

Characters and animation

How the party and the monsters are built and moved: the character meshes, the per-character battle files, the animation clip banks, and the art records that drive a Tactical Art.

Sound

Instrument banks, music sequences, streamed CD audio, and the tables that route a sound-effect cue to a bank.

Text

Dialog containers, the proportional font they are drawn with, and the place names the map screens show.

Static tables

The game's numbers - item names, spell stats, equipment bonuses, steal chances, move power - are static tables inside SCUS_942.54, the main executable, or the data segment of the battle and menu overlays, not in the asset archive. Each is byte-pinned against its image.

Item-name table Confirmed
256 item ids, 12-byte stride - the id space monster drops, steals and equipment all index. Parser legaia_game_tables::item_names.
Item-effect table Confirmed
What each usable item does: 130 4-byte descriptors - effect class, tier, party / field / battle usability flags. Literal HP / MP restore amounts are a separate tier-indexed table beside it; stat-up magnitudes are handler immediates.
Equipment stat-bonus table Confirmed
8-byte records per equippable item: INT / ATK / UDF / LDF / SPD bonuses, equip-character mask, slot type, Ra-Seru flag. Parser legaia_game_tables::equip_stats.
Accessory passive table Confirmed
64-slot passive-index space mapping accessories ("Goods") to per-character ability bits, with stat-percent magnitudes inline. Parser legaia_game_tables::accessory_passive.
Spell table Confirmed
Static spell stats + name pointers, 12-byte stride. Player Seru-magic block 0x81..=0x8B; named monster attacks from 0x25. Parser legaia_game_tables::spell_names.
Steal table Confirmed
Per-monster [chance, item] pairs - chance first, the reverse of the drop fields. What the Evil God Icon steals. Parser legaia_game_tables::steal_table.
Move-power table Confirmed
Per-move power + behaviour records (26-byte stride, PROT 0898): damage roll, homing, hit reaction, sound cue and spawned-effect lists, in the same id space as the spell table.
Battle attack-camera table Confirmed
Twenty rows of two signed halfwords in the battle overlay: the per-art swing camera offsets. The two columns are alternatives the game coin-flips between.
New-game starting party Confirmed
Four 26-byte records (Vahn / Noa / Gala / Terra) that seed the live character records; opening scene town01. Parser legaia_game_tables::new_game.
Per-character save record Confirmed
The in-RAM record holding one party member's whole state: 0x414 bytes per slot. Cheat-database-pinned offsets for stats, level, magic rank, spells, summons and equipment.
Window widget scripts Confirmed
The bytecode behind the UI's window choreography - the shop's slide-in, the menu's staged windows. Fixed 4-byte instructions [opcode][window id][operand] in the menu overlay's data segment.

Code overlays

Archive entries that hold code, not assets: overlays are chunks of MIPS machine code the game loads into RAM on demand, and most of the game's logic lives in them.

The port's own formats

Formats the port defines rather than decodes. They carry no disc bytes, so they have no confidence level: each page is the specification. Start from the expansion packs hub for the tour.