Porting Test Drive II from SNES to PC, Part 16: Closing the 1062..1069 ownership block

The previous checkpoint closed the direct bridge-extracted 1054..1061 block with live ownership evidence.

That checkpoint kept the same story alive:

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

The next useful question was whether that pulse would survive yet another block and keep moving again.

This checkpoint answers that at frame 1069.

Why 1069 mattered

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

• 1062..1069

At this point, the later attract lane is stable enough that the interesting changes are no longer the big ones.

The questions are now:

• does the same producer shape survive?
• where does the narrow VRAM pulse land next?
• does the screenshot-backed surface stay practically tight while that happens?

Those are better questions than simply asking whether the frame still belongs to the same callback family.

The checkpoint

The workflow stayed the same:

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

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_1069_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1070 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1062 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1069 \
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_frame1069 \
  tools/out/visual_contract_frame1069_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1069_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1069_live/td2_boot_probe.json
• tools/out/visual_contract_frame1069_live_probe.json

What the trace showed

The probe recorded:

• 4948 write hits
• 0 drops
• exact trace window 1062..1069

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 1062..1069
• VRAM: 580 writes at 1062 and 1066

So the better reading is now:

• the late ownership family is still flat
• visible sprites are still flat
• the same narrow VRAM pulse survives again
• and it shifts one block later again

That is a stronger and more precise statement than “frame 1069 is still in the same scene.”

What changed visually

The fresh design pack for 1069 reports:

• 61 visible sprites

That stays flat against the recent checkpoints.

The screenshot-backed mismatch did rise a little:

• 48 mismatched pixels

But that is still a very small gap for this late window, and it still happens without any callback-family fork.

Validation

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

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01069_frame.png \
  tools/out/mesen_frame1069/main_visible.ppm \
  --diff-out tools/out/mesen_frame1069_vs_intro1069_diff.ppm

That landed at:

• 48 mismatched pixels (0.083705%)

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

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

python3 tools/compare_frames.py \
  tools/out/mesen_frame1069/main_visible.ppm \
  tools/out/mesen_frame1069_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1069_mode7ppu_vs_mesen1069_diff.ppm

That compare landed at:

• 25 mismatched pixels (0.043597%)

Why this checkpoint is useful

After 1061, the repo could already say:

• the same narrow VRAM pulse survives again

After 1069, it can say something stronger:

• the next block is also ownership-stable
• the same pulse survives again
• it has shifted again, now to 1062 and 1066
• the screenshot-backed gap is still small even though it is gradually rising

That keeps the later attract path legible in producer terms instead of reducing it to image comparisons.

The late ownership chain is now closed at:

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

What comes next

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

The headline for this checkpoint is simple:

the 1062..1069 block is now closed by live ownership evidence, and the useful new fact is that the same narrow VRAM pulse survives once more while shifting to 1062 and 1066.