Porting Test Drive II from SNES to PC, Part 26: Tightening the SNES front-end selector cardinality

The previous checkpoint recovered the SNES preview-helper bundles.

That still left an important ambiguity in the front-end model:

• was the menu really exposing 3 cars?
• was the track surface really 4 slots?
• and was there some hidden front-end restriction on the third car?

This checkpoint narrows those questions with direct bank-1 code evidence and a
small negative WRAM probe.

The car surface is a real 3-slot loop

The strongest new proof is straightforward.

In the recovered front-end path:

• L008B3E sets $1C84 = 3
• $1C78 is copied into $0202
• L00BBCB drives the selector loop
• L00BDAC wraps $0202 from 2 -> 0
• L00BDD0 wraps $0202 from 0 -> 2

That means the current menu loop really exposes exactly 3 reachable slots.

And because those wraps are unconditional inside this loop, the old idea that
the third car might be hidden behind a front-end availability restriction is no
longer a good reading of the recovered code.

The helper side still matches that same surface:

• 0x0009 + $0202
• bundle 9
• bundle 10
• bundle 11

So the three-choice preview path and the three-slot selector loop now reinforce
each other instead of being separate hints.

The track surface is a real 4-slot top-level selector

The track side also tightened.

In the adjacent front-end path:

• L008B6F sets $1C84 = 4
• L00BE76 rotates $1C7C across 0..3
• L008B87 resolves descriptor-group rows from 01:8000/01:8008

Those tables decode to:

• bases [0, 5, 11, 18]
• counts [5, 6, 7, 8]

So $1C7C is no longer just “some four-state group candidate.”

It is now the best direct recovered top-level track surface in the SNES front
end.

What is still missing is the human-readable name mapping for those four slots.

The remaining blind spot moved to the label materializer

I also ran bounded boot probes against the menu corridor with simple start
pulses and full WRAM dumps.

Those probes were useful mostly because they failed cleanly.

Even when the front end transiently reaches 01:BAB3, the sampled runs still
leave:

• $1E80..$1FFF = 0

That matters because the nearby UI helper path still points at $1E80 through
L00179B.

So the frontier is no longer selector cardinality.

The next useful question is narrower:

which exact callback path materializes, or bypasses, the descriptor/label data
that should tie the four $1C7C slots to concrete track names?

Why this is a better DOS/SNES correlation point

The DOS side still helps here, but only at the contract level.

The SNES port is clearly reduced relative to DOS:

• 3 front-end car slots instead of the broader DOS car catalog
• 4 top-level track slots surfaced directly in the menu

That is a better model than trying to force full DOS menu fidelity onto the
SNES code.

The next checkpoint should therefore focus on the name-bearing descriptor path,
not on inventing more selector complexity than the recovered front end already
shows.