Shared Formats

The five games documented on this site were built by three studios across five years, but they are not five unrelated codebases. All five ship their data in the same Mac-style resource-fork container, and four of the five store their pixels in the same two resource types — IMAG for still images and FRML for sprite animation. This section documents what they share; each game’s own section documents what it doesn’t.

Knowing that saved real work: a decoder bug found on one game’s corpus is usually a bug on all of them, and a format confirmed against one game’s disassembly is a head start on the next.

The shared layer

Format	What it is	Used by
Resource forks	The .res container: header, data section, resource map, type/reference/name lists	All 5 games, on every platform
IMAG / GAMI	Compressed bitmap images — PackBits or LZSS over Amiga interleaved bitplanes	All 5 games
FRML / LMRF	Sprite animation frames — a frame table plus per-frame planar bitmaps	All 5 games
SMUS	EA IFF 85 Simple Musical Score — the in-game music	War in Middle Earth
SampledSound	Aegis Sonix .instr/.ss instrument and sample files	War in Middle Earth

Two engine families

The shared container is not evidence of a shared engine. There are two:

• Melbourne House — War in Middle Earth (1988). Its own image header (28 bytes), its own animation header, its own scene compositor.
• Synergistic Software / “Excal” — Spirit of Excalibur (1990), Vengeance of Excalibur (1991), Conan the Cimmerian (1991) and Warriors of Legend (1993). A 6-byte image header, a type-0x05 animation header, and — in Spirit and Vengeance — a shared FSME entity-class bytecode VM.

Conan sits inside the Excal family for its containers and pixel formats but diverges sharply everywhere else, including the most hostile executable structure of the five.

The byte-order rule

The Amiga releases are big-endian; the DOS and Apple IIGS releases are little-endian, and their resource type codes are the Amiga codes byte reversed — IMAG/GAMI, FRML/LMRF, MMAP/PAMM, SCEN/NECS, CSTR/RTSC, CHAR/RAHC, FONT/TNOF. The container structure is identical across all platforms; only the byte order of multi-byte fields and the data section’s layout differ.

That symmetry is convenient and it is also a trap — see the reference-list correction, which silently mis-paired resource ids with their data on every little-endian file until it was found.

Source of truth

These pages are a curated summary of the main repository’s format specs (not part of this site) — and where they disagree, the raw notes win: docs/formats/resource-fork.md, imag.md, frml.md, smus.md and sampled-sound.md, plus each game’s own docs/<game>/ for the parts that aren’t shared.