CDNAME.TXT - entry name map Confirmed

At a glance

Where

CDNAME.TXT at the disc root; ASCII, one #define name N per line. Retail loads it into a 16-byte-record table at RAM 0x80088758

Numbering

N is a raw TOC index; the content lives at extraction entry N − 2

Parser

crates/prot/src/cdname.rs: parse_str (tolerant), parse_retail_str / retail_name_table (byte-exact), block_for_extraction_index (applies the −2 rule)

Confidence

Confirmed - loader traced; the shift is pinned by four retail loader constants and the v12-sidecar placement (how we know)

Used by

Asset loader, prot-extract filenames, every scene window in the engine, boot

What the file says

The file looks like the top of a C header:

#define init_data 0
#define gameover_data 1
#define town01 3
#define town0b 12
#define town0c 21
...
#define vab_01 1072

Each line names a block of consecutive archive entries - usually one scene (a town, a dungeon room, a menu) plus the handful of entries reserved for its assets. Two rules do all the work:

• Names inherit forward. #define name N starts a block; every entry after N belongs to it until the next define. Entry 11 is town01 because town0b only starts at 12.
• The numbers are the game's index space. The game counts raw TOC words, header included; extraction counts payload entries, which start two words later. So #define name N names extraction entry N − 2.

Most blocks reserve 6-8 slots per scene. Unused slots hold the one-sector pochi filler, never a real asset; the edstati3 block is almost entirely filler.

Numbering space (the −2 correction)

The boot loader copies PROT.DAT verbatim - 8-byte header included - into RAM at 0x801C70F0 (PROT TOC), so raw index = extraction index + 2. The extractor's NNNN_<name>.BIN filenames apply define numbers as extraction indices directly, and are kept that way for stability - so a filename label is systematically two slots early.

A label is a hint, not a verdict. When a shift-corrected block name still conflicts with the bytes, trust the bytes: the leading magic and the loader-call constant in the executable.

What the dev names really cover

With the shift applied the developers' names are accurate far more often than not. The entries most often misread from their filename:

The music_01 block's bank map is piecewise: BGM id 2000+i is extraction 988+i for i ≤ 67 and 990+i for i ≥ 68 (music tracks).

What retail holds in RAM: long names are mangled

The boot loader copies each name into a 16-byte record and then stores the index over bytes 12-13 of the same record. The table is BSS, so it starts zeroed; there is no length check and no NUL is ever written.

Read back as a C string, a record therefore holds:

Clean C-string capacity is 11 bytes, not 12. Five shipped names exceed it and none round-trips:

• Repo tooling uses the tolerant parse_str, which keeps the full spelling. Anything compared against retail RAM must go through retail_name_table / parse_retail_str, which return names as bytes - the index bytes are routinely not valid UTF-8, and a lossy conversion prints fd for every one of them.
• The first line not starting with # ends the map; a line with an empty name still emits a record.
• Index 990 is declared twice (music_test, then music_01). Retail emits two records; the tolerant map keeps the later name. Compare the two readers by declaration order, not by index.
• Retail really does populate the table: main() sets the source flag at cold boot so the loader reads cdname.txt off the disc rather than over the developer-station link.

How we know

Source of record: docs/formats/cdname.md.

See also