Skip to content

Therons Quest Track02 Internals

Daniel Nylander edited this page Jul 13, 2026 · 19 revisions

Theron's Quest Track 02 Internals

Why the Disc Is Not an ISO Filesystem

PC Engine System Card software works with record numbers relative to a CD base. Official Hu7 production places record constants in the executable; the finished disc has no runtime central directory for a game to enumerate. Firestaff uses strict CUE parsing, raw-sector layout validation, known hashes, and traced record transitions rather than filename inference.

IPL and Stage Two

For verified raw JP/US Track 02 media, the IPL executes record 0x0003e7 into local RAM $4000. The subsequent observed CD_READ loads a single sector into $3800: record 0x04df in JP and 0x04e0 in US. The receipt records variant, record, raw sector, MODE1 user-data offset/size, content hash, destination, and live record-register provenance.

The initial $3800 payload begins BRK $ff followed by $0308 and a bounded 218-entry envelope. BRK $ff is control transfer through the active HuC6280 IRQ2 protocol; the subsequent six-byte entries are not executable code merely because they share the loaded sector.

Stage Three Boundary

The stage-two runtime handoff accepts the exact traced record and structural manifest receipt, then rejects a mismatched or mutated record before startup state can advance. This is intentionally transport evidence only. It does not name a manifest entry as a level, object, bitmap, palette, sound, or script.

Raw Sector Geometry

The accepted BIN route is MODE1/2352, not a mounted file system. A physical sector is 2352 bytes; Firestaff records both the physical byte position and the MODE1 user-data span for every accepted loader transfer. An offset into the BIN is therefore not automatically an offset into the 2048-byte user-data payload.

Each accepted transfer carries Track identity, record number, raw span, user-data span, local-RAM destination, and an exact payload hash. The IPL and stage-two path currently proves record 0x0003e7 and the one-sector read at JP 0x04df or US 0x04e0. The 218-entry envelope remains structural provenance: its entries are not files, sprites, levels, palettes, or object records.

Authentic System Card Trace

Firestaff has an opt-in Mednafen capture route using an explicit hash-verified CUE/BIN pair and System Card ROM. It is a loader-observation tool, not an emulator replacement or a source of generated game data.

The latest bounded authentic capture proves this post-latch state:

Observation Meaning Status
Program counter $c8cd CD-controller polling window entered. Observed.
BNE $c897 Retry returns to the controller polling loop. Observed.
$1800..$1804 PCECD controller baseline captured. Observed.
$1802, $1804, mirrored $18c0 writes Loader programs the PCECD interface. Observed.
$2241 = $24 System Card controller state at retry boundary. Observed.
ReadRawSector and dynamic record A later physical Track 02 read. Not yet observed.
HuC6270 palette write Loader-to-palette binding. Not yet observed.

The captured state takes C8CD -> C897 while response registers remain at the baseline. It is represented as a blocked pre-read controller state. It must not imply a record number, title bitmap, palette, level, object table, or audio stream.

Promotion requires all of the following: authenticated media identity; a live controller transaction with concrete record and destination; raw-sector/MODE1 correspondence; loader ownership of the consumed payload; and a separately justified semantic binding. Until then M11 keeps the no-fallback gate closed.

Reproducing a Bounded Capture

MEDNAFEN=/path/to/mednafen \
THERON_CUE=/path/to/Therons-Quest.cue \
THERON_TRACK02=/path/to/Therons-Quest-track02.bin \
THERON_SYSTEM_CARD=/path/to/syscard3.pce \
THERON_TRACE_OUT=/path/to/theron-live.trace \
  bash scripts/capture_theron_mednafen_live_trace.sh

Patch checks establish that instrumentation applies cleanly; they do not claim that a dynamic CD read occurred:

MEDNAFEN_SOURCE=/path/to/mednafen-source \
  bash tests/test_theron_v1_mednafen_controller_wait_trace_patch.sh
bash tests/test_theron_v1_mednafen_live_capture_script.sh

Keep traces outside the repository: they can include local media paths and are evidence artifacts, not distributable game assets.

Startup and Route Transactions

M12 carries strict CUE/Track02 provenance into M11. Startup title, stage, Soul Room, forcefield, and Continue routes require all of their original bitmap and level receipts. Route assembly is candidate-first: a level/object route is committed only after every required data receipt validates. An incomplete route leaves the old runtime state unchanged and cannot fall through to a synthetic surface.

SRM Boundary

Save Disk candidates require one valid gzip member with bounded header parsing, CRC32, and ISIZE validation. Unknown original bodies can be catalogued but are not restored until their structure is independently correlated. Firestaff-native SRM export uses no-replace atomic publication so an original artifact is not overwritten by a test save.

Continue carries the accepted media route mask, checksum, and selected level bank in its receipt. Restore is atomic: bad media, bad gzip, or an unbound body cannot partly mutate the live world.

Verification

FIRESTAFF_THERON_TRACK02_US_BIN=/path/to/us.bin \
FIRESTAFF_THERON_TRACK02_JP_BIN=/path/to/jp.bin \
  ./build/firestaff_theron_v1_track02_ipl_loader_probe

./build/firestaff_theron_v1_track02_level_handoff_probe
./build/test_theron_v1_startup_save_resume_pc34

The next valid semantic step must come from an original loader read, dispatch, or layout correlation for a later record. Repeated bytes, descriptor adjacency, and guessed PC Engine data formats are not sufficient evidence.

Clone this wiki locally