Redefine keys to "SHOCKED<ENTER>" to activate test/cheat mode.

The eight bytes at 8008 are labelled unused, but three of them ($C3,$D6,$A0) decode as JP $A0D6 (the keyscan routine) starting at $800E, six bytes into the block. CALL $800E is therefore equivalent to CALL $A0D6 — the disassembly has to spot this by decoding the data as code, since nothing points at $800E directly. Two call sites use it this way, at $C647 (in C59E) and $C1D7 (in C16A).

The three instructions at rps_dead_code (labelled rps_dead_code) can't be reached: every jump into the block above it either loops back to run_pregame_screen_loop or falls straight through to RET a few bytes earlier. Kept in the disassembly as found, not trimmed.

In the drum-noise burst routine (FA3A, at $FA67), AND A unconditionally clears the carry flag immediately before RET C, so that RET can never actually trigger early. The frame-flag byte it loads is never used for anything. Preserved as an apparent dead check in the original code, not a translation artefact.

Object scripts on the title screen use opcode $D1 for an initial constant-velocity burst, but $D1 is never tested by either of the two dispatch chains that drive object movement ($C70E onwards, in C59E). Every one of the five title scenes hits this: once $D1 is latched as the active opcode, the object can never reach the countdown that would let it fetch a new instruction, and it freezes in place for the rest of the scene. A genuine quirk of the original interpreter, not a disassembly error — see $CCF2 (in CCB7) for object 0's case.

There is no hardware scaling on the Spectrum, so roadside objects like trees, lamp posts and buildings can't just be one bitmap stretched to size. Instead draw_stretchy_object_common (draw_stretchy_object_common, reached via draw_stretchy_object_left or draw_stretchy_object_right) builds each object from a stack of small bitmap "bands": some bands are drawn at a fixed height regardless of distance, anchoring the object's basic shape; others are scaled to a percentage (25% to 200%) of a base height looked up in the shared persp_y_scale table, and it's these bands that actually shrink and grow as the object approaches or recedes. Each band picks its own bitmap variant for the current depth from a small per-band table, so a fixed foot or a stretched trunk can look subtly different up close without needing a whole extra full-size sprite. Five ~32-byte bands per object is far cheaper than one full bitmap per depth level.

bitmap_turnsign_6 defines a 16x10 "turn right" sign, complete with a pre-shifted copy at bitmap_turnsign_6s, but nothing in the disassembly references either bitmap. Whatever used it (perhaps an earlier version of the fork-in-the-road warning) was cut before release.

The cornering-direction check at $B2C7, in move_hero_car, tests bit 7 of H twice on the same branch of the decision tree ($B2CD and $B2D5) — the second test can never come out differently from the first, since nothing changes H in between. Marked "bug?" in the disassembly; behaviourally harmless, but almost certainly an accidental duplication rather than an intentional recheck.