At a glance

In the game
Never. No retail code path opens the file.
Magic / marker
None - a small offset table at the start, then fixtures.
Lives in
Disc root, next to PROT.DAT: 18,054 Form 1 sectors at the end of the disc (LBA 180228 on the USA image).
Parser
None needed; crates/prot walks its TOC, the categorize pipeline skips its contents. Patcher side: legaia_patcher::disc::DiscPatcher::annex_blob.
Confidence
Confirmed - no reference to the file exists in SCUS_942.54 or any overlay, and the fixture patterns are visible in the bytes.

Contents

Three discernable patterns:

  1. A memory-bus test pattern (alternating bit-walk values used to validate RAM during development).
  2. Paired random blobs (used as test inputs for the audio / video pipelines).
  3. A small offset table at the start.

No part of the file is referenced by retail gameplay code; the file is included on disc but never loaded. This is one of the few “dead” claims in the project that rests on no reference existing rather than on “no static caller” - see the address reference scan for the difference.

Treatment

Skipped by the categorize pipeline (the sweep that classifies every archive entry by format). Not interesting for either preservation or the engine port - but knowing it is inert saves anyone else from digging through it, and it keeps the pochi-fill slots company as the disc's other developer-placeholder pattern.

The DMY.DAT annex - spare room for patched discs

Because nothing reads it, DMY.DAT is the largest stretch of the disc a patch can overwrite without breaking anything. The patcher's equipment editor uses it when a rebuilt player battle file outgrows its PROT.DAT slot - a weapon model transplanted into another character's file, or the Super Arts Pack's animation block.

The file's first 0x8000 bytes (header, record[0], descriptor table) stay in the PROT entry; the grown slot region is parked here, with the descriptor offsets pointing into DMY.DAT. The retail loader streams by offset from the entry's start LBA and never bounds a file by its TOC span, so it follows the offsets across without modification.

  • A bump-allocator marker (LGAX, version, sectors used) in the file's last sector records what an earlier patch already placed, so a second patch of the same disc allocates past the first.
  • The first sector (its own offset table) is left alone so the archive still parses.
  • The image keeps its size, so a PPF carries the annex.

See also