Porting Test Drive II from SNES to PC, Part 27: Closing the SNES front-end descriptor-table base

The last SNES menu checkpoint tightened selector cardinality, but it still had
one bad assumption baked into it.

I was treating $1E80 as if the front end might be waiting for some WRAM label
table to be materialized there.

That turned out to be wrong.

This checkpoint closes that specific misunderstanding and replaces it with a
better static model.

$1E80 was not a WRAM target

The key detail is a small overlapping pointer setup used by the adjacent menu
helpers:

• lda #$1E80 ; sta $11
• lda #$8000 ; sta $10

At first glance, that looks like “something with $1E80”.

But in context, it is not building a WRAM destination.

It is building the long pointer:

• 1E:8000

That is the base later consumed by L00179B and L001662.

So the real question is no longer:

“who writes the $1E80 menu-label buffer?”

It is:

“which rows in the ROM table at 1E:8000 are the current car and track menu
descriptors?”

That is a much better question because it matches what the code is actually
doing.

L00179B was already dereferencing the ROM table directly

Once I re-read L00179B with that pointer setup in mind, the behavior became
clear.

The routine:

• treats [$10] as a long base pointer table
• reads one four-byte row at index * 4
• adds that row back to the base pointer
• then walks the resolved descriptor payload directly

So there is no missing WRAM materializer hiding behind this helper path.

The menu is already table-driven from ROM.

The current car and track rows are now pinned down

I added a small extractor for this table:

• tools/decode_frontend_pointer_table.py

and promoted the current report artifacts:

• tools/out/snes_frontend_pointer_table_1e8000.json
• tools/out/snes_frontend_pointer_table_1e8000.md

That decode now pins the adjacent menu rows used by the active selectors:

• car-facing helper surface:
  • $0202 + 0x0008
  • rows 8..10
  • targets 1E:9ACC, 1E:9C14, 1E:9D5C
• track-facing helper surface:
  • $1C7C + 0x000B
  • rows 11..14
  • targets 1E:9EA4, 1E:A374, 1E:A8CC, 1E:AD14

That does not name the tracks yet.

But it does close the old gate completely.

We are not looking for a missing writer anymore.

We are looking at concrete descriptor payloads.

Why this matters for the DOS/SNES correlation

This is also a better fit for the DOS comparison.

The DOS side already suggested compact non-graphic layout descriptors were a
higher-value search target than raw graphics alone.

The SNES side now has a much more defensible equivalent:

• a direct ROM descriptor table at 1E:8000
• adjacent selector-driven row lookups for cars and tracks

So the next useful step is not more blind WRAM probing.

It is decoding or rendering those row payloads far enough to tie the four
$1C7C slots to concrete track names, and only then checking whether a live
callback overlay still changes what the player actually sees.