Porting Test Drive II from SNES to PC, Part 6: When the bridge regresses

This iteration did not close a new scene window.

It closed something else that matters just as much in a project like this: an undocumented regression.

The new checkpoint, 8afadba on 2026-03-20, records that the planned Lane 2 interior carry check for the later 7051/7059/7064 scene is blocked again by the Mesen bridge in the current local environment.

That is not glamorous progress, but it is real progress.

The plan was simple

The repo had already recovered a later direct-hit cluster on the timed-input scenario:

6800:start;6900-6920:start,a

The exact anchors were already in place:

• 7051 -> 0D:C4DC
• 7059 -> 07:BF49
• 7064 -> 07:C112

The next step in the roadmap was intentionally small:

• extract 7055
• extract 7061
• check whether those interior frames keep the same visible tile block
• promote the scene to a contiguous provenance window only if the carry really holds

That is good archaeology discipline. Do not promote a contiguous claim until the interior frames are checked.

What actually happened

The first retry rebuilt the committed bridge extractor and then ran the planned range extraction:

python3 tools/extract_mesen_scene_range.py \
  --rom game.smc \
  --start-frame 7055 \
  --end-frame 7061 \
  --step 6 \
  --out-dir tools/out/mesen_range_7055_7061_inputfix_v1 \
  --ld-library-path /home/nivando-soares/Mesen2/bin/linux-x64/Release \
  --input-windows '6800:start;6900-6920:start,a' \
  --frame-timeout-seconds 180

It failed before the late input window even mattered.

The bridge timed out waiting for frame 1762 while trying to reach target frame 7055.

So I spent the bounded retry on the supported wrapper path with a longer timeout and a fresh output directory:

MESEN_RELEASE_DIR=/home/nivando-soares/Mesen2/bin/linux-x64/Release \
./tools/run_mesen_ppu_extract.sh \
  --rom game.smc \
  --frame 7055 \
  --out-dir tools/out/mesen_frame_7055_inputfix_retry_v1 \
  --frame-timeout-seconds 300 \
  --input-windows '6800:start;6900-6920:start,a'

That failed too, and it failed even earlier:

• timeout boundary: frame 411
• result: no extracted frame assets
• only scratch .mesen-home directories were created

At that point the right move was not "try again a few more times." The right move was to record the blocker.

Why this matters

The important point is not just that a command failed.

The important point is that it failed against a path the repo had already recovered earlier.

That means the later-scene timed-input extractor lane is currently environment-sensitive again. In other words:

• the archaeology claim is still valid at the direct-hit anchors
• the planned interior promotion step is not valid yet
• the bridge surface is no longer reliable enough to carry that claim forward automatically

If the repo ignored that distinction, it would start overstating its confidence.

That is exactly the kind of failure this project is trying to prevent.

This is where cleanup and archaeology meet

The current execution reset in asmdump treats Mesen compatibility and validation-output discipline as first-class work.

This checkpoint is a good example of why.

When a bridge path is unstable, the repo needs to say so clearly:

• which scenario was attempted
• which command variants were used
• where the timeout happened
• what artifacts did or did not appear
• what claim is still allowed
• what claim is not allowed yet

That turns a frustrating failed run into usable engineering state.

In this case, the resulting state is:

• keep the exact 7051/7059/7064 anchors
• do not promote 7051..7064 to a contiguous window
• treat later-scene timed-input extraction as compatibility-pinned work

That is a much better position than having a broken command and a vague memory that "I think this used to work."

What changed in the docs

The repo now records this blocker directly in the source of truth:

• rom_analysis/docs/next_steps_roadmap.md
• rom_analysis/docs/progress_checkpoints.md
• tools/README.md

That keeps the failure visible in the same places that drive the next action selection.

The new practical reading is simple:

• the local bridge environment is not healthy enough to finish the interior carry check
• the next defensible move is compatibility work, not a provenance promotion

Next step

The next move is no longer "extract 7055 and 7061."

It is:

• pin or recover a known-good Mesen/MesenCore.so pair for the timed-input bridge
• rerun the same 7055 and 7061 checks only after that bridge is stable again

That is the cost of working honestly.

Some iterations add a new frame.

Some iterations protect the repo from claiming a frame it cannot currently prove.