Porting Test Drive II from SNES to PC, Part 9: Closing the 1006..1013 ownership block

The previous checkpoint closed the first direct bridge-extracted 998..1005 block with live ownership evidence.

That made the next step obvious:

push the same method one block later and see whether the same late 01:9FE5 ownership story still holds.

This checkpoint does that at frame 1013.

Why 1013 mattered

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

• 1006..1013

The repo already had continuity notes saying that frame 1013 was still inside the same 01:9FE5 family. But continuity notes are not the same thing as a live producer-trace-backed contract.

The real question was:

• does the block still close inside the same ownership family?


• do the producer domains stay the same?


• if the visible screen keeps changing, does ownership stay flat anyway?

Those are stronger questions than “the frame still looks roughly right.”

The checkpoint

The workflow stayed the same as before:

1. extract frame 1013
   


2. build a design pack


3. run a bounded write-point probe across the whole 1006..1013 block


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=1013



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_1013_live/td2_boot_probe \

TD2_BOOT_PROBE_TOTAL_FRAMES=1014 \

TD2_BOOT_PROBE_TRACE_START_FRAME=1006 \

TD2_BOOT_PROBE_TRACE_END_FRAME=1013 \

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_frame1013 \

  tools/out/visual_contract_frame1013_live_probe.json \

  --probe-json tools/out/visual_contract_probe_1013_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1013_live/td2_boot_probe.json


• tools/out/visual_contract_frame1013_live_probe.json

What the trace showed

The probe recorded:

• 
  6174 write hits


• 
  0 drops


• exact trace window 1006..1013
  

The most useful result is that the callback family still does not move:

• active main callback: 01:9FE5
  


• active IRQ callback: 00:835F
  

The producer domains also still do not fork:

• OAM: 4368 writes across 1006..1013
  


• VRAM: 1806 writes across 1006..1012
  

That last detail is the new interesting one.

The block still closes under the same ownership family, but the bounded VRAM activity no longer reaches the final frame of the block.

So the useful reading is now:

• OAM stays flat


• callback family stays flat


• VRAM tapers off one frame earlier

That is exactly the kind of nuance a producer-trace-backed contract is good at exposing.

What changed visually

The fresh design pack for 1013 reports:

• 
  61 visible sprites

That matters because the previous end-of-block proof at 1005 reported:

• 
  53 visible sprites

So the picture is still:

• more visible overlay on screen


• same late callback family


• no control-flow fork required to explain it

That is the important distinction.

Validation

The fresh extracted frame was first compared against a new local screenshot-backed capture for 1013:

python3 tools/compare_frames.py \

  tools/out/intro_loop_frame_01013_frame.png \

  tools/out/mesen_frame1013/main_visible.ppm \

  --diff-out tools/out/mesen_frame1013_vs_intro1013_diff.ppm

That landed at:

• 
  4638 mismatched pixels (8.088030%)

Again, this is not a screenshot-exact checkpoint.

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

python3 tools/render_mesen_snes_bg.py \

  tools/out/mesen_frame1013/vram.bin \

  tools/out/mesen_frame1013/cgram.bin \

  tools/out/mesen_frame1013/ppu_state.json \

  tools/out/mesen_frame1013_mode7ppu.ppm \

  --oam tools/out/mesen_frame1013/oam.bin \

  --obj-renderer mode7-ppu \

  --json-out tools/out/mesen_frame1013_mode7ppu.json



python3 tools/compare_frames.py \

  tools/out/mesen_frame1013/main_visible.ppm \

  tools/out/mesen_frame1013_mode7ppu.ppm \

  --diff-out tools/out/mesen_frame1013_mode7ppu_vs_mesen1013_diff.ppm

That compare landed at:

• 
  10 mismatched pixels (0.017439%)

That is exactly the same practical surface the earlier bridge-visible docs already expected for frame 1013.

Why this checkpoint is useful

This is not a flashy checkpoint. It is a clarifying one.

After 998 and 1005, the repo could already say:

• the first direct bridge-extracted block is ownership-stable

After 1013, it can now say:

• the next block is also ownership-stable


• but the VRAM part of the bounded write window no longer reaches the last frame of the block

That is a better statement than simply “the same callback still appears in a probe log.”

Now the archaeology lane has live ownership closure on two consecutive direct bridge-extracted blocks:

• 998..1005


• 1006..1013

That is meaningful progress.

What comes next

The next step is the same pattern one block later:

• extend the live ownership surface to frame 1021
  

That closes the next direct bridge-extracted 1014..1021 block and shows whether the same flat ownership story still holds there too.

The headline for this checkpoint is simple:

the 1006..1013 block is now closed by live ownership evidence, and it adds one useful nuance: bounded VRAM writes stop one frame before the end of the block.