Porting Test Drive II from SNES to PC, Part 11: Closing the 1022..1029 ownership block

The previous checkpoint closed the direct bridge-extracted 1014..1021 block with live ownership evidence.

That left one obvious follow-up:

push the same proof surface to frame 1029 and see whether the late 01:9FE5 path is still stable once the bounded write surface gets even thinner.

This checkpoint does that.

Why 1029 mattered

1029 is the end of the next direct bridge-extracted block:

• 1022..1029

The earlier checkpoints had already shown a pattern:

• callback ownership stayed flat
• OAM stayed flat
• bounded VRAM activity kept thinning out

So the real question here was not just “does the same callback still show up?”

It was:

• does the block still close under the same owner?
• does bounded VRAM disappear entirely in this window?
• if that happens, what does the screenshot surface look like?

That is a better archaeology question than simply checking whether the extracted frame still renders.

The checkpoint

The workflow stayed the same:

1. extract frame 1029
2. build a design pack
3. run a bounded write-point probe across 1022..1029
4. merge that probe into a visual contract

The exact commands were:

MESEN_RELEASE_DIR=/home/nivando-soares/Mesen2/bin/linux-x64/Release \
make -C tools mesen-design-pack MESEN_FRAME=1029

MESEN_RELEASE_DIR=/home/nivando-soares/Mesen2/bin/linux-x64/Release \
MESEN_TIMEOUT_SECONDS=150 \
TD2_BOOT_PROBE_OUTPUT_PREFIX=tools/out/visual_contract_probe_1029_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1030 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1022 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1029 \
TD2_BOOT_PROBE_TRACE_WRITE_POINTS='objsel=00:2101,oamaddl=00:2102,oamaddh=00:2103,oamdata=00:2104,vmaddl=00:2116,vmaddh=00:2117,vmdatal=00:2118,vmdatah=00:2119,cgadd=00:2121,cgdata=00:2122' \
TD2_BOOT_PROBE_WRITE_POINT_MAX_HITS=8192 \
./validation/run_mesen_probe_boot.sh

python3 tools/build_mesen_visual_contract.py \
  tools/out/design_frame1029 \
  tools/out/visual_contract_frame1029_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1029_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1029_live/td2_boot_probe.json
• tools/out/visual_contract_frame1029_live_probe.json

What the trace showed

The probe recorded:

• 3822 write hits
• 0 drops
• exact trace window 1022..1029

The callback family still does not move:

• active main callback: 01:9FE5
• active IRQ callback: 00:835F

The new useful result is the bounded producer surface:

• OAM: 3822 writes across 1022/1023/1024/1025/1027/1028/1029
• no bounded VRAM, CGRAM, or OBJSEL writes observed

That is the real change in this checkpoint.

At 1021, bounded VRAM traffic was already sparse. By 1029, it disappears entirely inside the observed block, but the same ownership family still holds.

So the better reading is now:

• callback ownership stays flat
• visible sprite count stays flat
• bounded producer traffic collapses to OAM-only

That is a much stronger behavioral statement than “frame 1029 still belongs to the same scene.”

What changed visually

The fresh design pack for 1029 reports:

• 61 visible sprites

That is the same count already seen at 1013 and 1021.

So the visible overlay is not growing anymore.

That makes the ownership reading cleaner:

• sprite count is flat
• bounded VRAM traffic is gone
• OAM traffic is the only remaining live producer surface in the block

Validation

The extracted frame was compared against a fresh local screenshot-backed capture for 1029:

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01029_frame.png \
  tools/out/mesen_frame1029/main_visible.ppm \
  --diff-out tools/out/mesen_frame1029_vs_intro1029_diff.ppm

That landed at:

• 1 mismatched pixel (0.001744%)

This is the first checkpoint in this later ownership chain that is practically on top of the local screenshot surface.

The bounded renderer-side validation stayed on the stable Python mode7-ppu surface:

python3 tools/render_mesen_snes_bg.py \
  tools/out/mesen_frame1029/vram.bin \
  tools/out/mesen_frame1029/cgram.bin \
  tools/out/mesen_frame1029/ppu_state.json \
  tools/out/mesen_frame1029_mode7ppu.ppm \
  --oam tools/out/mesen_frame1029/oam.bin \
  --obj-renderer mode7-ppu \
  --json-out tools/out/mesen_frame1029_mode7ppu.json

python3 tools/compare_frames.py \
  tools/out/mesen_frame1029/main_visible.ppm \
  tools/out/mesen_frame1029_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1029_mode7ppu_vs_mesen1029_diff.ppm

That compare landed at:

• 11 mismatched pixels (0.019182%)

So the renderer side stays on the same practical bridge-visible surface, while the screenshot-backed comparison becomes almost exact.

Why this checkpoint is useful

After 998, 1005, 1013, and 1021, the repo could already say that the late direct bridge-extracted blocks were ownership-stable.

After 1029, it can say something sharper:

• the fourth consecutive direct block is also closed by live ownership evidence
• visible sprites stay flat at 61
• bounded producer traffic has collapsed to OAM-only
• the screenshot-backed comparison is now effectively solved

That is a better description of what the later attract path is actually doing.

The late ownership chain is now closed at:

• 998
• 1005
• 1013
• 1021
• 1029

What comes next

The next step is to extend the same proof surface to frame 1037 and close the next direct bridge-extracted 1030..1037 block.

The headline for this checkpoint is simple:

the 1022..1029 block is now closed by live ownership evidence, and the useful new fact is that the bounded producer surface collapses to OAM-only just as the screenshot-backed surface becomes practically exact.