Porting Test Drive II from SNES to PC, Part 13: Closing the 1038..1045 ownership block

The previous checkpoint closed the direct bridge-extracted 1030..1037 block with live ownership evidence.

That checkpoint showed something useful:

the bounded producer surface was not OAM-only anymore, because a narrow VRAM pulse had returned.

The next question was whether that pulse was a one-off local blip or a stable pattern in the following block.

This checkpoint answers that at frame 1045.

Why 1045 mattered

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

• 1038..1045

By this point the late attract path already looked structurally stable:

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

But the interesting question had shifted from ownership identity to ownership shape.

Was the narrow VRAM pulse from 1037 still present one block later?

That is the kind of detail that matters when the goal is native playback backed by actual producer behavior.

The checkpoint

The workflow stayed the same:

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

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_1045_live/td2_boot_probe \
TD2_BOOT_PROBE_TOTAL_FRAMES=1046 \
TD2_BOOT_PROBE_TRACE_START_FRAME=1038 \
TD2_BOOT_PROBE_TRACE_END_FRAME=1045 \
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_frame1045 \
  tools/out/visual_contract_frame1045_live_probe.json \
  --probe-json tools/out/visual_contract_probe_1045_live/td2_boot_probe.json

The promoted artifacts are now committed:

• tools/out/visual_contract_probe_1045_live/td2_boot_probe.json
• tools/out/visual_contract_frame1045_live_probe.json

One practical note about the tooling

This checkpoint also exposed a workflow detail that is worth writing down.

The first bounded attempt tried to run the probe and the screenshot dumper in parallel against the same isolated Mesen config.

That was not useful:

• both runs ended with exit 255
• neither emitted the needed artifact

Rerunning the same steps serially worked immediately.

So for this lane, sharing the same isolated config between concurrent Mesen runners is not a reliable pattern.

What the trace showed

The valid serial probe recorded:

• 4948 write hits
• 0 drops
• exact trace window 1038..1045

The callback family still does not move:

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

The useful result is that the narrow VRAM pulse is still there:

• OAM: 4368 writes across 1038..1045
• VRAM: 580 writes at 1038 and 1042

So the 1037 result was not a one-frame anomaly.

The better reading is now:

• callback ownership stays flat
• visible sprite count stays flat
• the bounded producer surface keeps the same OAM baseline plus a narrow two-frame VRAM pulse

The only thing that moved was where that pulse lands.

What changed visually

The fresh design pack for 1045 reports:

• 61 visible sprites

That is still flat against the earlier late-window checkpoints.

So this block reinforces a useful distinction:

• visible output stays stable
• producer identity stays stable
• the bounded VRAM pulse still moves around inside the block

That is the kind of behavior you want written down explicitly instead of inferring from screenshots alone.

Validation

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

python3 tools/compare_frames.py \
  tools/out/intro_loop_frame_01045_frame.png \
  tools/out/mesen_frame1045/main_visible.ppm \
  --diff-out tools/out/mesen_frame1045_vs_intro1045_diff.ppm

That landed at:

• 34 mismatched pixels (0.059291%)

So the frame remains very close to the screenshot-backed surface.

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

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

python3 tools/compare_frames.py \
  tools/out/mesen_frame1045/main_visible.ppm \
  tools/out/mesen_frame1045_mode7ppu.ppm \
  --diff-out tools/out/mesen_frame1045_mode7ppu_vs_mesen1045_diff.ppm

That compare landed at:

• 15 mismatched pixels (0.026158%)

Why this checkpoint is useful

After 1037, the repo could say:

• the block is ownership-stable
• the narrow VRAM pulse has returned

After 1045, it can say something stronger:

• the next block is also ownership-stable
• the same narrow VRAM pulse pattern persists
• the pulse shifts to 1038 and 1042
• running probe and screenshot capture in parallel on the same isolated Mesen config is not reliable for this lane

That is both archaeology progress and workflow progress.

The late ownership chain is now closed at:

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

What comes next

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

The headline for this checkpoint is simple:

the 1038..1045 block is now closed by live ownership evidence, and the useful new fact is that the narrow VRAM pulse pattern persists one block later while the rest of the late ownership story stays flat.