Repository navigation
EMI Section Types
Every TOC entry carries a type id at +0x0C. Seven values occur on the Japanese disc. Census over all 880 files, 6,344 sections:
| type | sections | what it is |
|---|---|---|
| 0 | 2,623 | untyped: overlay code or data, copied to the RAM address in +0x04
|
| 1 | 65 | a compressed party sprite arena, decompressed to 0x80033800
|
| 3 | 593 | an image, uploaded to the VRAM rectangle packed in +0x04
|
| 6 | 1,020 | sound bank: the VAB header |
| 8 | 904 | sound bank: the cue table entries |
| 7 | 1,020 | sound bank: the VAB body (the samples) |
| 10 | 119 | a sequence (SEP), the music |
The community doc names 0, 3, 6, 7 and 10; types 1 and 8 were identified in this work. Nothing of value lives in the type id beyond this: in particular it does not separate code from data, since every game-logic table ships in a type-0 section beside the code that reads it.
A type-0 section whose destination lies inside the boot executable's zero-filled text segment is a code overlay. 527 sections are code by a word-statistics test, 405 distinct by content (the battle engine, for example, is shipped 42 times, identically, in every battle and boss file). They land in exactly ten RAM bands:
| band | occupants | distinct | what |
|---|---|---|---|
0x80093800 |
42 | 1 | the battle engine (BATTLE.EMI, every BOSS*.EMI) |
0x800C1800 |
40 | 35 | the boss modules, BOSS/BOSSnnn.EMI
|
0x800F5000 |
3 | 1 | |
0x80117000 |
1 | 1 | |
0x80196800 |
1 | 1 | the field engine, GAME.EMI section 0 (227 KB) |
0x801CE400 |
19 | 19 | the party-character modules, PLCHAR/PLPnnn.EMI
|
0x801D0C00 |
63 | 18 | the game-mode swap slot: SHOP, STATUS, BATTLE, START, MTEST, the COMMU* village modules, SCE*
|
0x801EEC00 |
157 | 128 | the spell and effect modules, BMAGIC/MAGICnnn.EMI (and a few areas) |
0x801F2C00 |
181 | 181 | one module per area, WORLDnn/AREAnnn.EMI
|
0x801F6C00 |
20 | 20 | the scenario chapters, SCENARIO/SCENAnn.EMI
|
The bands are mutually exclusive by game mode. The engine knows which file to request by arithmetic on a game variable (file id = area + 0x2AB for an area, chapter + 0x295 for a scenario, a table lookup for a boss) and where to enter the loaded image by a record kept in the engine's own data: an area's descriptor sits at the end of its section and lists its init routine and handler table; the scenario table and the boss table point at vtables and entry routines inside the image. None of this is in the container. See LOADER_RECORDS.md.
Every overlay opens with the same two-part header ahead of its first function:
+0x00 u32 registry id unique across all 405 overlays, 0x010..0x1BF
+0x04 u32[] entry pointers 0 to 59 of them, each an aligned address inside this image
... code
The id is a global identity, assigned in blocks that roughly follow the directory (PLCHAR 0x021..0x033, SCENARIO 0x105..0x11D, BOSS 0x11E..0x140, BMAGIC 0x144..0x1BF) but not derivable from the filename. The pointer run is consumed by the overlay's own code, not by the loader. See OVERLAY_HEADERS.md.
Code sections also carry fixed-stride name tables for things that are not dialogue: the five item tables (consumables 92 x 14 bytes, key items 16 x 12, weapons 83 x 20, armour 68 x 18, accessories 52 x 16, each record an 8-byte name plus flags, a description id and a price) and the 227-entry ability table sit in GAME.EMI section 0; the 200 area names for the debug map select are in MTEST.EMI; the roster names are in COMMU02.EMI; the eight new-game character templates are in START.EMI. The record index is the id that saves and RAM hold. See TEXT_TABLES.md.
A type-0 section whose destination is below the executable (0x80010000..0x80035800) or in a data gap is a data block. What it holds depends on the address, and the addresses are fixed per build. The Japanese addresses:
Every area file carries one. The word at +0x04 is an offset from the block's start to a table of u16 message offsets, 256 slots per area; a message id becomes a string pointer by base + u16[base + 2 * id]. Messages are byte strings in the game's own encoding: single-byte codes for kana, Latin letters, digits and symbols, two-byte codes with lead bytes 0x12, 0x13, 0x15 for kanji, and control codes below 0x12 (0x00 end, 0x01 newline, 0x02 page break, 0x03/0x04 insert a character's name, 0x05/0x06 colour, 0x08 insert another message by id, 0x0A play a sound, 0x0C box type, 0x0F text effect, 0x14 a choice menu, 0x16 a timed page break). This is the one section replaced wholesale between languages: comparing the English, French and German discs, about 93 % of its bytes differ and it is the only area section that changes size, while everything else stays byte-identical. Capcom's localisations grew it freely. See TEXT_ENGINE.md.
Carried by FIRST.EMI, BATTLE.EMI and every BOSS*.EMI (44 files; two variants, identical in 42). Same shape as the area block but with several header words selecting sub-tables: word 0 addresses 176 messages, word 1 addresses 455, and the ref field of every item and ability record is an id into that second table, which is where the item descriptions live.
1,160 bytes in every area file: eight 9-byte encounter rows (which enemies appear together), then eight enemy records of 0x88 bytes each. A record holds the enemy's stats, its 8-byte name at +0x48, the attack type and skill-rate bytes, and four AI rows at +0x38, each a condition code and a change to apply (the five-section AI scheme that the fan Enemy Database describes). Sound for the same eight enemies ships separately in BENEMY/ENEMYnnn.EMI. Outside the name fields this block is byte-equal across every build held, Japanese, Western, PSP and PC. See enemy_ai_data.md.
The field map proper: the map header, the cell grid, the runs of cells the view is built from, and the wall data the draw walks. In AREA004 it is 60,600 bytes. A few areas carry a second block at 0x80117000.
Two blocks every area carries. 0x800D3800 holds the map's sprite frames (on the world maps, the painted place-name plates sized to each name live here); 0x800E3800 is its companion, whose block order changes with the plates when a Western disc rearranges them. The exact record layouts are not written up yet.
The small blocks at 0x8002xxxx carry CLUT strips and small lookup tables. The one at 0x8002D800 in an area file is the area's palette section, whose first CLUT paints the world-map plates; the one at 0x8002B800 in FIRST.EMI is the font's CLUT strip, a grey ramp per colour (index 1 the body, 2..6 anti-aliasing, 7 the drop shadow). The others (0x8002BA00, 0x8002BC00, 0x8002EC00, 0x8002EE00, 0x8002D7E0 in the battle and menu files) have not been read individually.
The big one: 124 to 332 KB, in PLCHAR/PL*.EMI, BPLCHAR/BPL*.EMI, BRT*.EMI and START.EMI, shipped compressed (type 1) or plain (type 0). The layout, as the code reads it:
| level | layout |
|---|---|
| arena | three u32 offsets from the arena's start, one bank per party member, in the order the file name's three digits list them |
| bank | four u32 offsets from the bank's start: the image table, the palette, the animation scripts, the 3-byte frame entries |
| scripts | a u16 offset table, one script per entry; the first entry is the table's own size |
| script | a frame count and a step count; steps x (hold ticks, frame) or a jump (>= 0x80); frames x u16 offsets; then the frames |
| frame | a count byte, then that many 5-byte parts (the sprite pieces a frame is composed of) |
Every level is reached through an offset the data carries; no address inside an arena is a constant of the engine. The DRG*, RYU*, REI*, RT*, PAPY* and CRYU* files in BPLCHAR carry a single bank-shaped block at a party slot's address (0x8003380C, 0x8005780C, 0x8007280C) rather than a whole arena. See arena-edits.md.
The same arena, LZ-compressed. Format and proof on EMI Container Format. 44 of the 65 files also carry a small type-0 block for the same address.
593 sections, every one in VRAM rather than RAM. The destination word is a packed rectangle:
dest = (vram_x / 32) << 24 | (vram_y / 32) << 16 | (bytes / 16K) << 8 | flag
The data is the raw VRAM contents of that rectangle, stored as 32 x 32-halfword tiles, left to right then down. A 256 KB section is a whole texture page: 512 halfwords wide, 256 rows, which is 1,024 texels at 8 bits or 2,048 at 4 bits. The section itself does not say what pixel depth the picture is; that is decided by the drawing code's texture-page word, and the palettes it indexes travel separately in the small type-0 CLUT blocks above. Pages seen often:
| dest | VRAM | what |
|---|---|---|
0x0E001000 |
(448, 0), 256 KB | the area's texture page (the map's tiles and sprites) |
0x0A081000 |
(320, 256), 256 KB | the world-map page: the dial, gauges and controls |
0x1E000200 |
(960, 0), 32 KB | the system glyph page (4 bpp): the 12-pixel font and the title's mark |
0x1A080200, 0x1C080200
|
(832, 256) and (896, 256), 32 KB | battle and menu pages |
0x080F0201 |
(256, 480), 32 KB | the item-type icons (FIRST.EMI) |
0x1A080400 |
(832, 256), 64 KB | the copyright notice on the title (DEMO.EMI) |
ENDKANJI.EMI is two images: the single-byte font sheet (4 bpp, 128 pixels wide, 512 rows, stored as two interleaved streams of 32-row chunks that de-interleave to a 252-pixel-wide sheet of 12-pixel cells, 21 to a row) and the kanji sheet. On the US disc the same page also carries the 8 x 12 and 8 x 8 Latin dialogue fonts, 31 cells to a row.
Between the Japanese disc and the Chinese PC port, 47 images differ, every one a whole-tile replacement of at least two tiles: Capcom's localisers repainted tiles, they did not shift palettes.
Every sound-bearing file carries one or more runs of three consecutive sections with the same bank id in +0x04:
| type | content | what the engine does with it |
|---|---|---|
| 6 | a VAB header (pBAV): programs, 32-byte tones, and a 256-entry table of sample sizes in 8-byte units |
registered as that bank's VAB in libsnd; a tone maps to a sample, a centre note and a volume |
| 8 | the cue-table entries: 4 bytes per cue, {flags, 0x80 | program, tone << 4 | priority, chord << 4 | first voice}
|
copied to the head of the bank's 31-entry cue table; a 24-byte section is 6 cues, a 64-byte one 16. Entries past the record are not cleared, so a previous occupant's cues stay reachable |
| 7 | the VAB body: the VAG samples back to back | uploaded to the bank's slot in SPU RAM |
The game plays a sound by a 16-bit cue word, bank in the high byte and entry in the low: 0x2xx is bank 2, the field and battle effects; 0x1xx bank 1, the system set (menu blings, and each spell's own samples over 0x100); 0x3xx..0x5xx banks 3..5, the three party members' voices; 0x6xx bank 6, the eight creature slots of the current area's enemy group. Bank 0 is the music's. Three of the 904 type-8 sections follow a type 10 instead of a type 6.
A VAG sample is 16-byte blocks of 28 ADPCM samples: a shift/filter byte, a flags byte (end, repeat, loop start), then 14 bytes of signed nibbles; the five filter pairs are the SPU's. Full detail in SOUND_CUES.md and sound-import.md.
The music is not streamed; it is sequenced. A type-10 section is a Sony SEP (pQES, version 0) holding four sub-songs of MIDI-style events, and it always travels in a bank-0 group with its own VAB header and body (types 6 and 7), so the file is the song and its instruments together. 81 BGM*.EMI files carry one, as do the battle, boss and demo bundles (119 sections in all). A song table in the boot executable maps a song number to a file and a sub-song index. The loop is in the data, as libsnd's own convention: controller 99 = 20 at the loop start and 99 = 30 at the loop end; 156 of 165 songs loop. The player is Psy-Q 3.7's LIBSND, matched function by function in the boot executable, and its timing is in VSync ticks with integer arithmetic, which is why a rendered loop never quite equals the sequence's ticks times its tempo. See sequenced-music-plan.md.
The PC port dropped every type-10 section and ships MP3 renders instead (DAT Files (PC port)).