Porting Test Drive II from SNES to PC, Part 29: Reframing the SNES front-end car-presentation diffs

The previous checkpoint proved something useful, but I had gotten one label too
confident.

The 1500/1640 frame corridor was being described as a car-select surface.

The stronger wording, for now, is narrower:

it is a front-end car-presentation or preview corridor driven by the same
three-slot $0202 domain.

That wording change matters because it keeps the evidence honest while still
letting the archaeology move forward.

The third live anchor is real

I ran one more bounded probe with a second right input:

• 1200:start
• 1280:start
• 1505..1510:right
• 1645..1650:right

That probe changes state_0202 from 2 to 0 at frame 1677.

So the current live front-end trio is:

• frame 1500: state_0202 = 1
• frame 1640: state_0202 = 2
• frame 1780: state_0202 = 0

These are the three committed frame anchors:

That does not yet prove which exact menu or intro state machine owns the trio.

It does prove the three reachable front-end anchors on the same selector path.

Raw exact-frame dumps beat the looser extractor here

I also hit a useful correction boundary.

At frame 1780, the mesen_ppu_extract result did not agree with the raw
mesen_dump_bg_range dump.

So for this lane, I promoted a raw-frame comparer and treated the runner dump
as the source of truth for exact-frame analysis.

That tighter pass changes the read materially.

Across 1500, 1640, and 1780:

• BG1 stays unchanged in all three pairings
• BG2 tilemap changes are limited to the top screen row
• the changed-cell counts are only:
  • 27 for 1500 -> 1640
  • 11 for 1500 -> 1780
  • 27 for 1640 -> 1780

So the visible panel difference is no longer best described as a broad lower
screen tilemap rewrite.

It is a much smaller exact-frame tilemap delta.

Visible BG2 CHR is flat

The next obvious hypothesis was:

maybe the visible panel delta was mostly CHR rather than tilemap.

The raw visible-union CHR summary falsified that.

For the visible BG2 tile union, the exact-frame CHR delta is:

• 0 changed CHR tiles for 1500 -> 1640
• 0 changed CHR tiles for 1500 -> 1780
• 0 changed CHR tiles for 1640 -> 1780

So the best exact-frame reading is now simpler:

• stable BG1 wallpaper
• small top-row BG2 tilemap change
• shared visible glyph/panel CHR across the three anchors

That still leaves L00A9CB as a real per-car reload path in code.

It just means the currently visible exact-frame delta is not where that helper
is showing up yet.

What changed next

The next useful step is no longer “prove more BG2 mutability”.

That part is already much narrower.

The next useful step is:

1. measure the full BG2 0x3000 CHR-region diff, not just the visible tile union
2. explain whether L00A9CB is reloading non-visible tiles or reloading tiles that stay identical across the visible union
3. keep the wording conservative until the interactive menu ownership is explicit in code or trace evidence