Skip to content

EMI Files

Jump to bottom
Kevin Kline edited this page Oct 17, 2026 · 1 revision

EMI files

Almost everything in Breath of Fire III that is not the boot executable lives in .EMI files. There are 880 of them on the Japanese PlayStation disc (SLPS-00990), under BIN/, and they hold the game's code overlays, its maps, scripts, sprites, textures, sound banks and music. The 2001 Chinese PC port repackaged 742 of them as DAT/*.DAT; the PSP release carries the same data in its own containers.

An .EMI is a container of sections. Each section is a flat block of bytes with a 16-byte table-of-contents entry that says how big it is, what type it is, and (for most types) which RAM address it is to be copied to. That last field is the whole design: the PlayStation has 2 MB of RAM, the game is far larger, and so the engine streams one area, one battle, one character set at a time by reading an EMI and copying each section to the address its entry names. There is no relocation; every pointer inside a section was baked for that one address.

This set of pages explains how the containers are laid out and what each kind of section holds. It is deliberately not about tooling: nothing here says how to render a sprite or rebuild a file.

Pages

Page What it covers
EMI Container Format The 16-byte header, the TOC entries, the 2 KB padding rule, the preview check, and the type-1 compression.
EMI Section Types What each type id means: overlay code, data blocks, images in VRAM, the three-part sound banks, sequenced music.
EMI Files by Family Directory by directory: what an AREA, BOSS, PL, BPLD, MAGIC, BGM, SCENA or ETC file contains, as a signature of its sections.
DAT Files (PC port) The PC port's container: the chunk format, how it maps onto the EMI, what the port dropped, decoded or changed, and the unrelated SND/ and BGM/ directories.
Game Data for Modders Enemies and their replication across areas, encounter rows, boss and event-battle tables, the chapter chain and its state, the flag arrays, area exits and search spots, item and character records.

The one-paragraph version

The game's RAM map is fixed. The boot executable (SLPS_009.90) occupies about 268 KB of real code and leaves most of its 1.4 MB text segment as zero fill. Those zero-filled regions are overlay bands, and an EMI's type-0 sections land in them: the field engine from GAME.EMI is practically permanent; a swap slot at 0x801D0C00 holds whichever of shop, status, battle or title is running; each area, boss, scenario chapter, spell effect and party-character set has a band of its own. Below the executable, low RAM (0x80010000..0x80035800 or so) receives the per-area data: the script and message block, the enemy table, the map, the palettes, the sprite frames, and the big "arena" of animated sprites for the current party. Images do not go to RAM at all: their TOC field is a packed VRAM rectangle, and the section is uploaded straight to the GPU. Sound comes as a three-section group that the Psy-Q sound library (libsnd/libspu) installs into a numbered bank. Music is a fourth section type, a Sony SEP sequence played against that bank.

Where this comes from

Everything here was measured on the discs and the PC install, mostly in two repositories that keep the long-form evidence:

The container layout was first written up by the community in the BoF3 Data Doc; the pages here confirm it, extend it to the two section types it does not name, and correct one thing it reads too literally (the destination field is not always an address).

Conventions: numbers are hexadecimal when prefixed 0x; "u32" is a little-endian unsigned 32-bit integer; "JP", "US", "EU" name the PlayStation releases. No bytes of the game appear on these pages, only structure, offsets and counts.

Clone this wiki locally