Porting Test Drive II from SNES to PC, Part 12: Closing the 1030..1037 ownership block

The previous checkpoint closed the direct bridge-extracted 1022..1029 block with live ownership evidence.

That checkpoint was interesting because the bounded producer surface had collapsed to OAM-only.

The next question was obvious:

does that stay true one block later, or does some narrower producer activity return inside 1030..1037?

This checkpoint answers that.

Why 1037 mattered

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

• 1030..1037

The late attract ownership story was already strong by this point:

• same callback family
• flat visible sprite count
• no sign of a control-flow fork

But 1029 raised a sharper behavioral question.

If bounded producer traffic had collapsed to OAM-only there, was that the new steady state, or just one local valley?

That is the kind of detail that matters when you are trying to replace sampled clips with native state playback.

The checkpoint

The workflow stayed the same:

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

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_1037_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1038 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1030 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1037 \
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_frame1037 \
  tools/out/visual_contract_frame1037_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1037_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1037_live/td2_boot_probe.json
• tools/out/visual_contract_frame1037_live_probe.json

What the trace showed

The probe recorded:

• 4948 write hits
• 0 drops
• exact trace window 1030..1037

The callback family still does not move:

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

The useful result is that the producer surface is not OAM-only anymore:

• OAM: 4368 writes across 1030..1037
• VRAM: 580 writes at 1030 and 1034

So 1029 was not the new permanent steady state.

The better reading is now:

• callback ownership still stays flat
• visible sprite count still stays flat
• but bounded VRAM activity returns as a very narrow pulse instead of staying absent

That is a more precise description of the later attract behavior than simply saying the block stays in the same family.

What changed visually

The fresh design pack for 1037 reports:

• 61 visible sprites

That is unchanged from 1013, 1021, and 1029.

So the visible overlay is still flat even though the bounded producer surface is not.

That distinction matters:

• flat visible sprites does not imply zero VRAM activity
• the late owner can stay the same while the producer mix changes inside the block

Validation

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

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01037_frame.png \
  tools/out/mesen_frame1037/main_visible.ppm \
  --diff-out tools/out/mesen_frame1037_vs_intro1037_diff.ppm

That landed at:

• 29 mismatched pixels (0.050572%)

So this frame stays very close to the screenshot-backed surface, even though it is not quite as tight as 1029.

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

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

python3 tools/compare_frames.py \
  tools/out/mesen_frame1037/main_visible.ppm \
  tools/out/mesen_frame1037_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1037_mode7ppu_vs_mesen1037_diff.ppm

That compare landed at:

• 8 mismatched pixels (0.013951%)

So the renderer path remains on the same practical surface already expected for this block.

Why this checkpoint is useful

After 1029, the repo could say:

• the block is ownership-stable
• the bounded producer surface has collapsed to OAM-only

After 1037, it can say something more accurate:

• the next block is also ownership-stable
• visible sprites still stay flat at 61
• but bounded VRAM activity returns as a narrow pulse at 1030 and 1034

That is a stronger behavioral map of the later attract path.

The late ownership chain is now closed at:

• 998
• 1005
• 1013
• 1021
• 1029
• 1037

What comes next

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

The headline for this checkpoint is simple:

the 1030..1037 block is now closed by live ownership evidence, and the useful new fact is that bounded VRAM activity returns as a narrow pulse even while the callback family and visible sprite count stay flat.