Hot Wheels: Stunt Track Driver
Hot Wheels: Stunt Track Driver
- Developer
- Semi Logic Entertainments, Inc.
- Publisher
- Mattel Media (examined packaging)
- Version
- 1.0 (shipped ReadMe)
One of the most formative and meaningful games to have ever graced my own history with the medium, Stunt Track Driver might genuinely occupy the earliest conscious memory I have as a human being. From the visuals and FMVs, to the soundtrack and car roster, it's all stuck with me viscerally for my entire life, and the genuine passion and art that went into creating this game often goes massively underappreciated.
One day, I WILL find and preserve the original stereo studio masters of this game's soundtrack... "Towards thee I roll, thou all-destroying but unconquering whale; to the last I grapple with thee; from hell's heart I stab at thee; for hate's sake I spit my last breath at thee."... or whatever whale man said
Evidence key: Confirmed means traced code or byte/hash proof. Strong means converging evidence or recognition supports the identification. Each card keeps its specific limits visible. Images and audio are decoded directly from the retail disc; they are not screenshots or gameplay recordings.
Disc leftovers
Browse the 1 findings in this section
Confirmed
A car workspace shipped on the disc
Link to this discovery ↗The retail disc includes the car working directory, with named models, textures and copy scripts.
What remains unknown: Describes shipped authoring material; no claim that every file is a complete development source.
Read about how this was found: A car workspace shipped on the disc
Inspect the named car models, textures and copy scripts on the retail disc; compare palette bytes and disc inventory totals.
The retail disc includes the car working directory, with named models, textures and copy scripts. Limit: Describes shipped authoring material; no claim that every file is a complete development source.
The recorded ISO inventory identifies a retail disc with 1,694 files and no nonzero payload in the documented tail-slack sweep. Limit: Historical inventory and extraction comparison; the document review does not re-read every ISO sector. Mastering metadata is not a commercial release date.
The recorded executable sweep identifies a Watcom runtime banner but no source paths or debug-symbol residue. Limit: A bounded printable-string/PE inspection; absence of readable residue is not proof that the executable contains no dormant code.
The disc’s car directory contains a JUNK folder holding a duplicate THEPAL.BMP. Limit: The folder name is original; it does not prove deletion intent.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Inspect the named car models, textures and copy scripts on the retail disc; compare palette bytes and disc inventory totals.
Examined release and shared evidence scope · Back to section
Cars
Models are shown as plain renders of their shape; the in-game colours and textures aren't shown.
Browse the 4 findings in this section
Confirmed
Two scripts preserve different car mappings
Link to this discovery ↗The shipped CAR.BAT replaces the earlier script’s effective slots 10–12 with TWINCOM, SPECIAL and WAY2FAST.
What remains unknown: No date, author or motive for the roster change is established.
Read about how this was found: Two scripts preserve different car mappings
Read CAR.BAK and CAR.BAT in order, comparing active copy commands and overwritten car slots.
The shipped CAR.BAT replaces the earlier script’s effective slots 10–12 with TWINCOM, SPECIAL and WAY2FAST. Limit: No date, author or motive for the roster change is established.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Read CAR.BAK and CAR.BAT in order, comparing active copy commands and overwritten car slots.
Examined release and shared evidence scope · Back to section
Confirmed
Six SPECIAL names, one shared geometry
Link to this discovery ↗Four SPECIAL variants never appear in any car slot. The six SPECIAL filenames share the same local triangle geometry.
What remains unknown: Visual appearance and chronology are not inferred from the filenames. Associated BMP textures can still differ, so equal model state does not imply equal textured appearance.
Read about how this was found: Six SPECIAL names, one shared geometry
Compare the SPECIAL models and their textures, then load their records with the original game code to compare geometry and state.
Four SPECIAL variants never appear in any car slot. Limit: Visual appearance and chronology are not inferred from the filenames.
The SPECIAL family shares its coordinate floats but differs in attributes, including metadata at record offset 0x74. Limit: 0x74 is neither Z3 nor an established material selector; differences elsewhere include UV, mode, animation and an overwritten texture pointer.
Six SPECIAL-family filenames represent five source byte streams, four loaded states and one local triangle geometry. Limit: Associated BMP textures can still differ, so equal model state does not imply equal textured appearance.
Each model record supplies a real triangle from coordinate arrays at offsets 0x44, 0x54 and 0x64. Limit: The recovered vertex path is confirmed; the diagnostic preview is not a retail screenshot.
The start of each model record contains draw state, integer coordinate caches, UVs and animation state. Limit: The independent audit’s empirical read check covers the loader window; later raster/queue readers are supported by the contender trace.
All 32 shipped models use 128-byte records with a four-byte count and a four-byte trailer. Limit: Trailer semantics and several flag/metadata meanings remain unresolved.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Compare the SPECIAL models and their textures, then load their records with the original game code to compare geometry and state.
Examined release and shared evidence scope · Back to section
Strong
CAR00: a rougher Speed Blaster that never races
Link to this discovery ↗CAR00 is an alternate Speed Blaster model with different geometry that never appears in normal play.
Interpretation: It appears to be a placeholder or an earlier version.
Read about how this was found: CAR00: a rougher Speed Blaster that never races
Compare CAR00.MMD with the playable Speed Blaster model. Inspect the game’s model-number dispatch and check its selection-record handling with isolated original code.
CAR00 is an alternate Speed Blaster model with different geometry that never appears in normal play.
The 1998 model constructor handles IDs 0–12 and sends out-of-range IDs to the bare stem car. Limit: The bare default has no shipped BMP/MMD.
A modified 1998 selection record can pass model zero through the save-driven selection path. Limit: The demonstration uses an injected selection record.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Compare CAR00.MMD with the playable Speed Blaster model. Inspect the game’s model-number dispatch and check its selection-record handling with isolated original code.
Examined release and shared evidence scope · Back to section
Confirmed
The loader supports companion files that do not ship
Link to this discovery ↗The shared model loader constructs an optional .SHR filename, but no .SHR file ships on the disc.
What remains unknown: This is a static code path, not fourteen observed live opens; the corrected MMD trace connects SHR to projected-corner reuse.
Read about how this was found: The loader supports companion files that do not ship
Follow the model loader’s optional SHR filename construction, failure handling and projected-corner reuse in the game code.
The shared model loader constructs an optional .SHR filename, but no .SHR file ships on the disc. Limit: This is a static code path, not fourteen observed live opens; the corrected MMD trace connects SHR to projected-corner reuse.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Follow the model loader’s optional SHR filename construction, failure handling and projected-corner reuse in the game code.
Examined release and shared evidence scope · Back to section
Sprites
Browse the 6 findings in this section
Confirmed
Eleven missing names survive in inactive tables
Link to this discovery ↗Eleven absent sprite filenames survive in inactive executable tables, including six records outside the garage table’s counted range.
What remains unknown: A copy-paste error is only a hypothesis; this does not describe the live selection artwork.
Read about how this was found: Eleven missing names survive in inactive tables
Read the counted garage table and the dormant track-name records in the executable; compare their entries with the retail disc.
Eleven absent sprite filenames survive in inactive executable tables, including six records outside the garage table’s counted range.
The dormant track-name table uses track6.asp in both its third and sixth positions and contains no track3.asp. Limit: A copy-paste error is only a hypothesis; this does not describe the live selection artwork.
The missing garage-panel and track-thumbnail names belong to inactive table data.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Read the counted garage table and the dormant track-name records in the executable; compare their entries with the retail disc.
Examined release and shared evidence scope · Back to section
Strong
Eight sprite files the game never loads
Link to this discovery ↗Eight sprite files ship on the disc, but the game never loads them. None appear in normal play.
Read about how this was found: Eight sprite files the game never loads
Compare the retail sprite files with the game’s filename construction and loading paths. Decode the stored sprites for inspection.
Eight sprite files ship on the disc, but the game never loads them. None appear in normal play.
The sprite corpus reserves 1,594 slots, of which 625 are empty. Limit: These are declared slots, not 1,594 recovered images.
The recorded 969 decoded sprites reduce to 765 distinct index maps.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Compare the retail sprite files with the game’s filename construction and loading paths. Decode the stored sprites for inspection.
Examined release and shared evidence scope · Back to section
Strong
A second version of the stunt-score wheel
Link to this discovery ↗timee.asp is a different-sized, differently anchored version of the used stunt-score wheel animation.
What remains unknown: Different whole-frame hashes do not mean zero matching pixels, and artist/session identity is not established.
Read about how this was found: A second version of the stunt-score wheel
Decode timee.asp and tricke.asp from the retail disc. Compare dimensions, authored anchors and pixels; check all wheel frames against the game’s own drawing routine.
timee.asp is a different-sized, differently anchored version of the used stunt-score wheel animation. Limit: Different whole-frame hashes do not mean zero matching pixels, and artist/session identity is not established.
Each sprite record stores flags, authored hot spots, dimensions and row offsets.
One sprite codec writes indexed runs and leaves skipped destination pixels untouched. Limit: Transparency here means preserving the existing destination.
Sprite hot spots are authored fields read by the blitter rather than calculated from image size. Limit: Single-sprite previews do not apply these anchors; this is a code claim.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Decode timee.asp and tricke.asp from the retail disc. Compare dimensions, authored anchors and pixels; check all wheel frames against the game’s own drawing routine.
Examined release and shared evidence scope · Back to section
Confirmed
The same eleven firework frames appear twice
Link to this discovery ↗Eleven firework frames occur identically in the decoded BOLT and FWORKS sets.
What remains unknown: Confirmed decoded-pixel relationship. The codec-A path now matches original-code execution on the wheel files; these firework files were not individually emulated.
Read about how this was found: The same eleven firework frames appear twice
Decode BOLT and FWORKS and compare their indexed pixels frame by frame, separately from palette colours.
Eleven firework frames occur identically in the decoded BOLT and FWORKS sets. Limit: Confirmed decoded-pixel relationship. The codec-A path now matches original-code execution on the wheel files; these firework files were not individually emulated.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Decode BOLT and FWORKS and compare their indexed pixels frame by frame, separately from palette colours.
Examined release and shared evidence scope · Back to section
Confirmed
Sixteen fade modes, only one selected
Link to this discovery ↗Every sprite the game draws uses the full-opacity mode; the other fifteen fade modes are never used.
Read about how this was found: Sixteen fade modes, only one selected
Read the sprite fade table and the mode arguments supplied by the game’s drawing calls.
Every sprite the game draws uses the full-opacity mode; the other fifteen fade modes are never used.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Read the sprite fade table and the mode arguments supplied by the game’s drawing calls.
Examined release and shared evidence scope · Back to section
Confirmed
An unused solid-colour blitter
Link to this discovery ↗A separate solid-color sprite blitter is never used.
Read about how this was found: An unused solid-colour blitter
Inspect the separate solid-colour sprite drawing routine and the executable’s callers.
A separate solid-color sprite blitter is never used.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Inspect the separate solid-colour sprite drawing routine and the executable’s callers.
Examined release and shared evidence scope · Back to section
Sound
Browse the 6 findings in this section
Confirmed
Every sound bank carries a 1996 “trip” message
Link to this discovery ↗All 43 sound banks carry the same preamble mentioning a first pass of “trip” on June 10th, 1996.
This is first pass of trip, started approx 3pm, on June 10th, 1996What remains unknown: The text is not a recovered creation date for the game or banks.
Read about how this was found: Every sound bank carries a 1996 “trip” message
Read the null-padded ASCII preamble at offset zero in every retail TAD and TID bank and compare the bytes across all 43 banks.
All 43 sound banks carry the same preamble mentioning a first pass of “trip” on June 10th, 1996. Limit: The text is not a recovered creation date for the game or banks.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Read the null-padded ASCII preamble at offset zero in every retail TAD and TID bank and compare the bytes across all 43 banks.
Examined release and shared evidence scope · Back to section
Confirmed
The lower-resource soundtrack
Link to this discovery ↗The game ships a second, lower-quality soundtrack that only plays on low-spec machines (low RAM or a slow CD drive). On a normal setup these versions never play.
What remains unknown: The music relationship checks do not reproduce live playback or mixing.
Read about how this was found: The lower-resource soundtrack
Trace the game’s RAM and CD-speed checks and the audio filenames they select. Decode the retail music and check the decoder against isolated execution of the game’s own routine.
The game ships a second, lower-quality soundtrack that only plays on low-spec machines (low RAM or a slow CD drive). On a normal setup these versions never play. Limit: The music relationship checks do not reproduce live playback or mixing.
The music files use a SLAG-tagged container around ADPCM sample data.
The twelve SAG files declare 22,050 Hz mono audio; the eleven SIG files declare 11,025 Hz mono.
The compressed music payload occupies one quarter of the declared decoded PCM size, subject to the loader’s truncation.
The other twenty TID banks contain 11,025 Hz, 8-bit audio, while garg.tid retains its mixed formats. Limit: The distinction is measured from format fields, not assumed from extensions.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Trace the game’s RAM and CD-speed checks and the audio filenames they select. Decode the retail music and check the decoder against isolated execution of the game’s own routine.
Examined release and shared evidence scope · Back to section
Confirmed
Different music filenames contain the same bytes
Link to this discovery ↗Five SIG files are identical, and GARG.SAG is identical to menu.sag.
What remains unknown: Hardware selection is explained separately by AUDIT-001.
Read about how this was found: Different music filenames contain the same bytes
Compare complete retail music-file hashes and garage sound-bank bytes; compare extracted samples without changing their levels.
Five SIG files are identical, and GARG.SAG is identical to menu.sag. Limit: Hardware selection is explained separately by AUDIT-001.
garg.tad and garg.tid are byte-identical despite belonging to the two audio-quality sets. Limit: An unconverted low-spec companion is supported; the reason it shipped that way is not established.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Compare complete retail music-file hashes and garage sound-bank bytes; compare extracted samples without changing their levels.
Examined release and shared evidence scope · Back to section
Confirmed
The ending reuses wire-stage music
Link to this discovery ↗The latter part of the win cue reuses the wire-stage music with edits and an effects layer.
What remains unknown: The saved correlation supports reused audio; exact splice coordinates conflict between prose and JSON and are omitted. Composition history and claims that the opening is unique are not established.
Read about how this was found: The ending reuses wire-stage music
Decode the retail ending and wire-stage cues, then compare aligned audio segments and their differences. The residual is not an original audio stem.
The latter part of the win cue reuses the wire-stage music with edits and an effects layer. Limit: The saved correlation supports reused audio; exact splice coordinates conflict between prose and JSON and are omitted. Composition history and claims that the opening is unique are not established.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Decode the retail ending and wire-stage cues, then compare aligned audio segments and their differences. The residual is not an original audio stem.
Examined release and shared evidence scope · Back to section
Confirmed
The low-resource intro rearranges menu music
Link to this discovery ↗The low-resource intro cue starts with the logo sting and includes reordered menu-music sections.
What remains unknown: The reason for its 94.10-second length and the late-region alignment remain unresolved; no blanket “nothing unique” claim is made.
Read about how this was found: The low-resource intro rearranges menu music
Decode the retail intro and menu cues, then compare the logo opening and reordered music segments without retiming the samples.
The low-resource intro cue starts with the logo sting and includes reordered menu-music sections. Limit: The reason for its 94.10-second length and the late-region alignment remain unresolved; no blanket “nothing unique” claim is made.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Decode the retail intro and menu cues, then compare the logo opening and reordered music segments without retiming the samples.
Examined release and shared evidence scope · Back to section
Confirmed
Some lower-resource sounds occupy different slots
Link to this discovery ↗The low-resource banks contain displaced crash variants and a byte-level swap between near-silent Bedroom noises.
What remains unknown: No audible computer/toilet substitution is established, and live triggering of each displaced entry was not tested.
Read about how this was found: Some lower-resource sounds occupy different slots
Extract the retail sound banks and compare corresponding crash variants and Bedroom noise entries by bytes and listening.
The low-resource banks contain displaced crash variants and a byte-level swap between near-silent Bedroom noises. Limit: No audible computer/toilet substitution is established, and live triggering of each displaced entry was not tested.
Recorded check
Historical research and audit records support the statements above. This assembly verifies mapping and media hashes; it does not rerun the excavation or establish a new gameplay observation.
How to check this finding
- Use the evidence record to identify the examined files and their hashes. Compare your disc and executable SHA-256 hashes with the examined_inputs in this evidence record before following its addresses. Different builds may have different addresses or behavior.
- Extract the retail sound banks and compare corresponding crash variants and Bedroom noise entries by bytes and listening.
Examined release and shared evidence scope · Back to section
Movie presentation links
Section titled “Movie presentation links”These TVGEP channel uploads are linked for viewing; they are not embedded.
- Secret (wireframe) stage — A 24 FPS presentation of the Secret (wireframe) stage movie; not original timing or a gameplay capture.
- Sandbox — A 24 FPS presentation of the Sandbox movie; not original timing or a gameplay capture.
- Basement / Game Room — A 24 FPS presentation of the Basement / Game Room movie; not original timing or a gameplay capture.
- Greenhouse — A 24 FPS presentation of the Greenhouse movie; not original timing or a gameplay capture.
- Track editor clips (all) — A 24 FPS presentation of the track editor clips; not original timing or a gameplay capture.
- Attic — A 24 FPS presentation of the Attic movie; not original timing or a gameplay capture.
- Living Room — A 24 FPS presentation of the Living Room movie; not original timing or a gameplay capture.
- Bedroom — A 24 FPS presentation of the Bedroom movie; not original timing or a gameplay capture.
Examined release
Section titled “Examined release”The evidence concerns the 1998 Windows retail disc. The shipped README.TXT identifies version 1.0, Windows 95/98 support and a 1998 Mattel copyright. This is release identification, not a claim that a mastering timestamp is a commercial release date.
The MobyGames Windows release catalogue identifies Semi Logic Entertainments as developer. The displayed archival cover carries Mattel Media, CD-ROM, Windows 95/98, ESRB Everyone and product number 20781. Catalogues differ on exact release dates and publisher editions; only the year is displayed. The scan does not show a version number, so its match to the examined v1.0 disc remains unconfirmed.
The cover is copyrighted game packaging used to identify the subject, not public-domain artwork. No free licence or rights-holder permission is claimed. Scanner attribution was not established by the catalogue.