Porting Test Drive II from SNES to PC, Part 14: Closing the 1046..1053 ownership block

The previous checkpoint closed the direct bridge-extracted 1038..1045 block with live ownership evidence.

That checkpoint showed that the narrow VRAM pulse had not disappeared. It had simply moved.

So the next useful question was straightforward:

does the same pulse pattern persist again one block later?

This checkpoint answers that at frame 1053.

Why 1053 mattered

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

• 1046..1053

By this point the later attract path had a very clear stable shell:

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

The interesting part was no longer ownership identity.

It was ownership shape.

If the narrow VRAM pulse from 1037 and 1045 kept moving but kept surviving, that meant the late path still had internal producer rhythm even while the visible scene looked almost frozen.

The checkpoint

The workflow stayed the same:

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

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_1053_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1054 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1046 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1053 \
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_frame1053 \
  tools/out/visual_contract_frame1053_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1053_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1053_live/td2_boot_probe.json
• tools/out/visual_contract_frame1053_live_probe.json

What the trace showed

The probe recorded:

• 4948 write hits
• 0 drops
• exact trace window 1046..1053

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 1046..1053
• VRAM: 580 writes at 1046 and 1050

So the pattern from the previous two blocks survives again.

That means the better reading is now:

• the late ownership family is still flat
• the visible scene is still flat
• the bounded VRAM pulse is still present
• its position keeps shifting block by block

That is a stronger and more useful description than simply “frame 1053 still belongs to the same callback.”

What changed visually

The fresh design pack for 1053 reports:

• 61 visible sprites

That is unchanged from the recent late-window proofs.

So once again the picture is:

• same visible sprite count
• same owner
• slightly moving internal producer rhythm

That is exactly the sort of thing a producer-trace-backed contract is good at preserving.

Validation

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

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01053_frame.png \
  tools/out/mesen_frame1053/main_visible.ppm \
  --diff-out tools/out/mesen_frame1053_vs_intro1053_diff.ppm

That landed at:

• 31 mismatched pixels (0.054060%)

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_frame1053/vram.bin \
  tools/out/mesen_frame1053/cgram.bin \
  tools/out/mesen_frame1053/ppu_state.json \
  tools/out/mesen_frame1053_mode7ppu.ppm \
  --oam tools/out/mesen_frame1053/oam.bin \
  --obj-renderer mode7-ppu \
  --json-out tools/out/mesen_frame1053_mode7ppu.json

python3 tools/compare_frames.py \
  tools/out/mesen_frame1053/main_visible.ppm \
  tools/out/mesen_frame1053_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1053_mode7ppu_vs_mesen1053_diff.ppm

That compare landed at:

• 14 mismatched pixels (0.024414%)

Why this checkpoint is useful

After 1045, the repo could already say:

• the narrow VRAM pulse pattern survives one block later

After 1053, it can say something stronger:

• the next block is also ownership-stable
• the same pulse pattern survives again
• it shifts once more, now to 1046 and 1050

That makes the later attract path easier to describe in terms of actual producer behavior instead of just static screenshots.

The late ownership chain is now closed at:

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

What comes next

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

The headline for this checkpoint is simple:

the 1046..1053 block is now closed by live ownership evidence, and the useful new fact is that the same narrow VRAM pulse pattern survives yet another block while continuing to shift its position.