Pochi-filler placeholder slots Confirmed

At a glance

In the game

Never loaded. Reserved slots a scene's asset block set aside and never filled.

Magic / marker

ASCII pochi at offset 0 and a DOS end-of-file byte 0x1A at +0x786

Lives in

266 PROT.DAT entries, each exactly one 2048-byte sector, clustered at fixed positions inside scene CDNAME blocks

Parser

Detection class pochi_filler (legaia_disc_audit::categorize::is_pochi_filler)

Confidence

Confirmed - measured over the whole corpus: every slot is one sector, none carries a parseable TIM.

Byte layout

The fill is one 1927-byte text file, byte-identical in every slot; 0x1A is the DOS end-of-file marker that closes it. The two bytes before it are the empty line, not a truncated po (both readings give 0x786 = 37 × 52 + 2; the bytes say \r\n). pochi (ポチ) is a stock Japanese dog name, a common developer fill pattern.

The last 121 bytes are not fill. In all 266 slots they are byte-identical to what some other, non-filler entry holds at the same file offset - usually the previous entry in archive order. The mastering buffer is indexed by file offset and not cleared between writes, so a 1927-byte file in a 2048-byte sector leaves 121 bytes of the previous write showing through. They say nothing about this slot.

Detection is two checks: buf.starts_with(b"pochi") && buf[0x786] == 0x1A.

The same 1927-byte file appears again on the disc, LZS-compressed to 239 bytes: as the trailing type-0x14 descriptor of 28 of the 105 count-prefixed scene bundles - not only the count-4/5 ones, but 9 of 10 count-4, 4 of 4 count-5, 3 of 8 count-6 and 12 of 80 count-7 - and as the leading type-0x0A descriptor of three more. The asset dispatcher answers those types without reading the payload, so those bytes are never decompressed at runtime - the authoring tool filled a reserved descriptor with the same file it fills a reserved archive slot with.

Why 266 of them exist

The archive's entries are grouped into named blocks, one per scene, by CDNAME.TXT (the disc's plain-text map of entry names). Each scene's block reserves a fixed run of 6-8 slots for asset variants, but most scenes only fill some of them; whatever a scene didn't use got pochi-filled. That's why the filler slots cluster at fixed offsets within their CDNAME block - typically positions 2, 4, 5, 6.

Some scene blocks are almost entirely pochi. The edstati3 block (the ending's station-gondola scene in the scene-name table) has 36 of ~38 pochi entries.

What a contributor must do

Treat these slots as known-empty:

• Don't run format detectors against them.
• Don't include them in TMD/TIM bulk-scan totals.
• Skip them in any "what's still uncategorised" tally.
• Size every entry as the sector gap to its successor (PROT TOC) - a pochi slot then has no reach into its neighbour at all.

In the port, the field VRAM pre-pass skips these entries outright (legaia_engine_scene::scene_resources).

The ground-atlas hazard belongs to the next entry

A rendering bug is worth keeping on this page precisely because its symptom points at the wrong entry. Two 64 x 256 texture pages land at framebuffer (768, 0) and (832, 0) - a scene block's battle-side character pages, CLUT rows 473 / 479 - and fb (768, 0) is tpage 0x0C, where most field scenes put their ground-tile atlas (the per-cell page in the .MAP object record's +0x15; see world-map "Ground texturing"). Uploaded last, they erase the atlas and the ground quads sample character / backdrop texels: Jeremi's floor becomes a grid of grey "tombstones", Mt. Dhini's a repeating vine/crack pattern.

Those pages are the scene_tmd_stream entry that follows the pochi slot - its FUN_8001FE70 type-0x01 chunks. A "scan every entry in the CDNAME block for TIMs" sweep reached them by standing on the pochi slot and reading past its end. Rim Elm escapes because its sibling slots are all scene_tmd_stream entries, which the field build already excludes - which is the same statement about the neighbour, read as a statement about the slot.

See also