Porting Test Drive II from SNES to PC, Part 17: Closing the 1070..1077 ownership block

The previous checkpoint closed the direct bridge-extracted 1062..1069 block with live ownership evidence.

That checkpoint showed the same thing the recent late-window proofs had been showing:

• same owner
• same visible sprite count
• same narrow VRAM pulse

The next useful question was whether that shape would survive again once the block reached 1077, and whether the small renderer-side gap would stay small too.

This checkpoint answers that.

Why 1077 mattered

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

• 1070..1077

At this point, the late attract lane is not about proving ownership identity anymore.

That is already stable.

The real question is now about how much variation can appear inside the same ownership family before the renderer-side gap starts to matter.

This block is useful because it pushes exactly on that edge.

The checkpoint

The workflow stayed the same:

1. extract frame 1077
2. build a design pack
3. run a bounded write-point probe across 1070..1077
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=1077

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_1077_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1078 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1070 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1077 \
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_frame1077 \
  tools/out/visual_contract_frame1077_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1077_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1077_live/td2_boot_probe.json
• tools/out/visual_contract_frame1077_live_probe.json

What the trace showed

The probe recorded:

• 4948 write hits
• 0 drops
• exact trace window 1070..1077

The callback family still does not move:

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

The producer shape still survives:

• OAM: 4368 writes across 1070..1077
• VRAM: 580 writes at 1070 and 1074

So the narrow VRAM pulse is still there, and it has shifted again.

That means the better reading is now:

• ownership identity is still flat
• visible sprite count is still flat
• the narrow VRAM pulse is still alive
• but the renderer-side error budget is no longer staying in the same tiny band

That last point is the new useful one.

What changed visually

The fresh design pack for 1077 reports:

• 61 visible sprites

So the visible-sprite count is still flat.

The screenshot-backed comparison also stays tight:

• 36 mismatched pixels

But the Python mode7-ppu comparison rises more noticeably here:

• 52 mismatched pixels

That is the new contour worth documenting.

The scene still sits inside the same late ownership family, but the renderer-side gap is no longer growing only by a handful of pixels.

Validation

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

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01077_frame.png \
  tools/out/mesen_frame1077/main_visible.ppm \
  --diff-out tools/out/mesen_frame1077_vs_intro1077_diff.ppm

That landed at:

• 36 mismatched pixels (0.062779%)

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

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

python3 tools/compare_frames.py \
  tools/out/mesen_frame1077/main_visible.ppm \
  tools/out/mesen_frame1077_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1077_mode7ppu_vs_mesen1077_diff.ppm

That compare landed at:

• 52 mismatched pixels (0.090681%)

Why this checkpoint is useful

After 1069, the repo could already say:

• the same narrow VRAM pulse survives again

After 1077, it can say something sharper:

• the next block is also ownership-stable
• the same pulse survives again
• it shifts again, now to 1070 and 1074
• the screenshot-backed surface stays tight
• but the Python mode7-ppu gap now rises materially inside the same callback family

That is exactly the kind of nuance that prevents “same owner” from being mistaken for “same solved renderer surface.”

The late ownership chain is now closed at:

• 998
• 1005
• 1013
• 1021
• 1029
• 1037
• 1045
• 1053
• 1061
• 1069
• 1077

What comes next

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

The headline for this checkpoint is simple:

the 1070..1077 block is now closed by live ownership evidence, and the useful new fact is that the same narrow VRAM pulse survives again while the Python mode7-ppu gap rises materially inside the same callback family.