Pochi-filler placeholder slots Confirmed
266 of the 1233 entries in PROT.DAT (the disc's single big asset archive) are unused placeholder slots, padded with the repeating ASCII word pochi - a common Japanese dog name (ポチ), the kind of fill pattern a developer picks so that uninitialised data is instantly recognisable in a debugger. The game never loads them. The catch is what comes after the padding.
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 (likely "ending station 3", possibly cut content) has 36 of ~38 pochi entries.
The scratch tail: a working texture that was never meant to load
The padding runs 1926 bytes and ends with a DOS end-of-file marker; the bytes after it are whatever the mastering tool happened to leave in the sector. A large share of scene-block pochi slots carry a complete, well-formed 256×256 4bpp PSX TIM (the PlayStation's standard texture format, here at 4 bits per pixel) - often two, with image blocks destined for framebuffer coordinates (768, 0) and (832, 0) and palettes (CLUTs - colour lookup tables stored as rows of framebuffer pixels) at rows 473 / 479: the block's battle-side character pages, left over from an earlier mastering pass.
They parse. They upload. Retail never touches them, because the field loader dispatches the scene's asset table - an explicit list of which entries to load - rather than walking the scene's reserved slots.
A reimplementation that instead scans every entry in the scene's block for textures walks straight into the trap. Framebuffer (768, 0) is tpage 0x0C (the 64×256 slice of video memory starting at framebuffer x=768), and that is exactly 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"). The stale pochi upload lands last and erases it, and the ground quads then sample character / backdrop texels: Jeremi's floor becomes a grid of grey "tombstones", Mt. Dhini's a repeating vine/crack pattern. Rim Elm escapes only because its sibling slots are all scene_tmd_stream
entries, which the field build already excludes.
Byte layout
+0x000..0x786 ASCII "pochipochi..." (37 lines × 52 bytes + "po" = 1926 bytes)
+0x786 0x1A (DOS EOF marker)
+0x787..end scratch / leftover data (no consistent format)Detection is two checks: buf.starts_with(b"pochi") && buf[0x786] == 0x1A. Detection class: pochi_filler; detector + class enum in crates/asset/src/categorize.rs.
What a contributor must do
Treat these slots as known-empty, whatever their tails parse as:
- 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.
- Never upload their textures: any VRAM-building sweep must skip
Class::PochiFiller(the categorizer's enum variant for these slots).
The engine's field VRAM pre-pass does exactly that - it skips Class::PochiFiller entries outright (legaia_engine_core::scene_resources). The disc-gated regression field_ground_texture_pages_disc pins both halves: that the hazard exists on the disc, and that the built VRAM does not contain it.