Porting Test Drive II from SNES to PC, Part 15: Closing the 1054..1061 ownership block

The previous checkpoint closed the direct bridge-extracted 1046..1053 block with live ownership evidence.

That checkpoint showed that the narrow VRAM pulse was still alive and still moving.

The next useful question was the obvious follow-up:

does the same shape survive one block later again?

This checkpoint answers that at frame 1061.

Why 1061 mattered

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

• 1054..1061

By this point, the later attract path had become very stable in the large:

• same callback family
• same visible sprite count
• very small screenshot-backed mismatch

So the interesting information was now all in the small:

• where does the bounded VRAM pulse land now?
• does it still exist at all?

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

The checkpoint

The workflow stayed the same:

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

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_1061_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1062 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1054 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1061 \
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_frame1061 \
  tools/out/visual_contract_frame1061_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1061_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1061_live/td2_boot_probe.json
• tools/out/visual_contract_frame1061_live_probe.json

What the trace showed

The probe recorded:

• 4948 write hits
• 0 drops
• exact trace window 1054..1061

The callback family still does not move:

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

The producer shape is the useful part:

• OAM: 4368 writes across 1054..1061
• VRAM: 580 writes at 1054 and 1058

So the same narrow VRAM pulse survives again.

The better reading is now:

• late ownership identity is still flat
• visible sprite count is still flat
• the narrow VRAM pulse is still present
• its position keeps shifting one block at a time

That is a much stronger statement than simply saying the later attract window stays inside one callback family.

What changed visually

The fresh design pack for 1061 reports:

• 61 visible sprites

That is unchanged from the recent late-window checkpoints.

So the visible scene still looks practically frozen while the producer rhythm underneath it continues to move.

That is exactly the sort of behavioral nuance a producer-trace-backed contract is meant to preserve.

Validation

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

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01061_frame.png \
  tools/out/mesen_frame1061/main_visible.ppm \
  --diff-out tools/out/mesen_frame1061_vs_intro1061_diff.ppm

That landed at:

• 36 mismatched pixels (0.062779%)

So the screenshot-backed surface stays very tight.

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

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

python3 tools/compare_frames.py \
  tools/out/mesen_frame1061/main_visible.ppm \
  tools/out/mesen_frame1061_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1061_mode7ppu_vs_mesen1061_diff.ppm

That compare landed at:

• 22 mismatched pixels (0.038365%)

Why this checkpoint is useful

After 1053, the repo could already say:

• the same narrow VRAM pulse pattern survives again

After 1061, it can say something stronger:

• the next block is also ownership-stable
• the same pulse survives again
• it has shifted once more, now to 1054 and 1058

That makes the later attract path easier to describe as a real producer rhythm instead of a static image sequence.

The late ownership chain is now closed at:

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

What comes next

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

The headline for this checkpoint is simple:

the 1054..1061 block is now closed by live ownership evidence, and the useful new fact is that the same narrow VRAM pulse persists yet again while shifting to 1054 and 1058.