Porting Test Drive II from SNES to PC, Part 25: Recovering the SNES preview-helper extractor

The previous checkpoint left one annoying blind spot in the DOS-driven SNES menu work.

The front end already had a believable three-choice preview path:

• L00BBCB cycles $0202 over 0..2
• L008B57 commits that final choice into $1C78
• helper bundle indices 9/10/11 were already resolved from the bank-1 tables

But the ROM-side helper-scene builder still died on those bundles.

That meant we could name the table edges, but not actually materialize the assets behind them.

This checkpoint fixes that specific problem without pretending the whole preview runtime is solved.

The 26FB bulk stream was ending early

The blocker turned out to be narrow and concrete.

For the L00A9CB bulk path used by preview helper 9, strict 26FB decode still raises:

• got 11348 bytes
• expected 16640

That is still the right default behavior for a general-purpose decoder.

So I did not weaken the decoder globally.

Instead, I split the behavior:

• strict mode stays strict
• the helper-scene extraction path can opt into partial output for this specific bulk-copy use case

The extractor now records:

• declared output size
• actual decoded output size
• whether the stream length mismatched

That preserves the anomaly as evidence instead of hiding it.

The preview bundles now rebuild

With that narrow extractor change in place, the one-shot helper builder can now rebuild helper indices:

• 9
• 10
• 11

The committed summary artifact for the clean isolated-layer rebuild is:

• tools/out/bank1_preview_helper_9_11_summary.json

That closes the previous “can we even materialize these assets?” question.

The answer is yes.

What the clean model actually shows

The useful result is not just that the builder runs.

It is that the outputs are asymmetric.

In the clean isolated-layer model:

• all three BG1 renders are blank
• helper 9 produces non-backdrop BG2 content
• helpers 10 and 11 remain blank on BG2

So the next unknown changed shape.

It is no longer:

“are helper indices 9..11 blocked by a broken extractor?”

It is now:

“what extra runtime composition or callback follow-up makes helper 10 or 11 visible, if anything?”

That is a much better frontier because it moves the work from raw asset reachability into actual menu-state behavior.

Why this matters for the DOS correlation lane

This also sharpens the DOS/SNES comparison.

On the DOS side, preview assets are selected from IDs and then composed by the menu flow.

On the SNES side, we now have two stronger facts:

• the three-choice $0202 -> $1C78 path really does point at distinct helper bundles
• raw extraction is no longer the limiting factor

So if the SNES preview still looks inconsistent, the remaining explanation is more likely to be:

• follow-up animation/state
• a different live TMAIN/BGxSC/BG12NBA layer mix
• or an intentionally deferred composition step

That is exactly the kind of boundary worth tracing next.

What changed in practice

This checkpoint did not prove that $0202/$1C78 is definitively the car selector.

It did remove one weak excuse for not testing that harder.

The next pass should focus on:

• live preview-menu PPU state during helper 9/10/11
• follow-up callback activity after the one-shot helper build
• name-bearing DOS/PC-side menu data that can collapse the remaining selector-domain ambiguity