Porting Test Drive II from SNES to PC, Part 28: Closing the SNES car-select BG2 mutability lane

#gamedev #c #sdl #emulation

Porting Test Drive II from SNES to PC, Part 28: Closing the SNES car-select BG2 mutability lane

The previous SNES front-end checkpoint pinned the frame-1500 car-select
panel to helper bundle 10.

That was useful, but it still left one important ambiguity open.

Was the visible lower panel really a mutable per-car BG2 surface?

Or was I just staring at one lucky static frame while the real per-car changes
lived somewhere else?

This checkpoint closes that ambiguity.

A real second car-select state was needed

The first step was to stop reasoning from one frame only.

I reused the same no-input path into the front end and added one short
navigation input:

1200:start
1280:start
1505..1510:right

That probe changed state_0202 from 1 to 2 at frame 1537.

The matching capture later lands on a stable second panel at frame 1640, and
that panel is clearly:

Lamborghini Diablo

So now there are two live menu anchors in the same corridor:

frame 1500: Porsche 959
frame 1640: Lamborghini Diablo

That alone already made the next comparison meaningful.

Here are the two committed frame artifacts that anchor this checkpoint:

The code path is more specific than I had before

The static read around L00BC0F also tightened the model.

The per-car panel reload is not some vague shared front-end refresh.

It does this:

lda $0202
adc #$0009
jsr L00A9A0
jsr L00A9CB

And that matters because it closes two things at once:

the per-car panel helper selection is derived directly from $0202
the inner loop does not pair that reload with a per-car L00A9F2 palette reload

So the current best reading is:

tilemap/layout changes through L00A9A0
CHR changes through L00A9CB
palette is not the primary moving piece on that per-car switch

That is a much tighter search surface than “something in the menu changes”.

The visible diff is now explicit

I promoted a small design-pack layer comparer and used it against the two live
car-select states:

frame 1500
frame 1640

The result is clean:

BG1: 0 changed visible cells
BG2: 256 changed visible cells
changed screen bbox: x=0..247, y=128..223
all changed BG2 cells are nonzero -> nonzero

That is the important part.

The wallpaper layer is stable.

The player-visible mutation is concentrated in the lower BG2 panel, not in a
coarse full-screen redraw, not in OAM-only composition, and not in a simple
blank/unblank event.

So the car-select archaeology is now materially narrower:

the visible car sprite still comes from the per-car OBJ catalogs
the mutable title/stats panel is a helper-driven BG2 tilemap/CHR rewrite

The car OBJ catalogs are now named locally

I also promoted a thin canonical manifest for the three 01:9C77 car OBJ
catalogs so later asset work does not keep drifting between ad hoc names:

p959 -> 1A:97D8
diablo -> 11:A578
f40 -> 1A:8000

That is not the main result of the checkpoint, but it removes a lot of future
naming friction.

What this changes next

The next useful step is no longer “prove the car-select panel is not OAM”.

That part is done.

The next useful step is:

land the third live Ferrari F40 panel
compare that BG2 surface against the two current anchors
map the mutable panel bytes against the helper payload pairs:
- 00:B6B2 vs 00:BCBA
- 0E:91FE vs 0E:A428