DEV Community

Nivando Soares
Nivando Soares

Posted on

Porting Test Drive II from SNES to PC, Part 30: Closing the SNES BG2 CHR-region delta

Porting Test Drive II from SNES to PC, Part 30: Closing the SNES BG2 CHR-region delta

The last checkpoint had already narrowed the visible difference across the
three front-end anchors at frames 1500, 1640, and 1780.

At that point the exact-frame read was:

  • BG1 stayed flat
  • BG2 tilemap changes had collapsed to the top row
  • visible-union BG2 CHR was already at zero

There was still one obvious escape hatch left:

maybe the full BG2 CHR region was changing even if the currently visible
tiles were not.

That escape hatch is now closed.

The full inferred BG2 CHR region is flat

I promoted a dedicated raw-frame region comparer and ran it against the three
pairings:

  • 1500 -> 1640
  • 1500 -> 1780
  • 1640 -> 1780

For BG2, the inferred CHR region is:

  • 0x3000 .. 0x5FFF
  • 12288 bytes total

Across all three pairings, that full region reports:

  • 0 changed bytes
  • 0 changed ranges

So this front-end difference is no longer explainable by “hidden CHR churn just
outside the visible union”.

It is currently a tilemap-only exact-frame difference.

The three anchors are still useful

These are still the committed frame anchors for the corridor:

Frame 1500 front-end corridor anchor

Frame 1640 front-end corridor anchor

Frame 1780 front-end corridor anchor

What changed is not the existence of the corridor.

What changed is the explanation of the bytes behind it.

The top menu and the $0202 corridor are now explicitly separate

I also tightened the code-side reading so the front end does not get collapsed
into one vague “menu”.

The top-level three-option gate is handled first by L00BAE8 on $1C6A.

Only later does control move into the downstream three-slot $0202 corridor
through L008B31 -> L008B3E.

That matters because it keeps two different surfaces separate:

  • the top-level signboard menu
  • the later downstream front-end corridor using $0202

So the current frame trio should not be carelessly relabeled as the initial
menu itself.

What this changes next

The next step is no longer “find the CHR delta”.

That question is closed for the exact-frame BG2 region.

The next step is:

  1. explain why L00A9CB is still a real reload path if the whole inferred BG2 CHR region is identical across the three anchors
  2. reconcile the timing mismatch between mesen_dump_bg_range and mesen_ppu_extract
  3. keep the top menu and the downstream $0202 corridor documented as separate front-end surfaces

Top comments (0)