-
-
Notifications
You must be signed in to change notification settings - Fork 4
Therons Quest Track02 Internals
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.
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.
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.
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.
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.
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.shPatch 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.shKeep traces outside the repository: they can include local media paths and are evidence artifacts, not distributable game assets.
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.
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.
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_pc34The 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.