DEV Community

Nivando Soares
Nivando Soares

Posted on

Porting Test Drive II from SNES to PC, Part 36: Closing the SNES organic default-rival handoff path

Porting Test Drive II from SNES to PC, Part 36: Closing the SNES organic default-rival handoff path

The last front-end checkpoint proved two things separately:

  • the downstream Select Opponent screen is a real 2x2 surface on $1C70
  • the bottom-right clock slot already changes handoff fields at L008B87

What was still missing was the live corridor.

Did the default rival path actually reach the gameplay callback family
organically, or were we only seeing that by forcing callbacks in headless
tests?

That gap is now closed.

The useful distinction was no longer menu meaning

By the previous checkpoint, the menu semantics were already narrow:

  • $1C70 = 0..2 means rival-enabled handoff
  • $1C70 = 3 means no-opponent handoff

The remaining uncertainty was runtime reachability.

So this checkpoint stopped treating the problem as a UI question and treated it
as a timing question instead.

The fourth slot is still important, but now as an input-timing target, not as
an unresolved visual.

SNES Select Opponent BG1 surface

SNES downstream selection-box row 0x1D

Two no-force probes now recover the same live corridor

I ran two timed-input boot probes without pinning active_main.

Both runs recover the same organic path:

L00C20B -> 01:C1D2 -> L00BE76 -> L008B87 -> 01:902D

and then, later:

active_main = 02:9016

The two runs land at slightly different frame numbers, but they agree on the
important part:

  • the Select Opponent loop really does fall through into the known gameplay callback family
  • the default top-left rival slot is enough to reach that corridor
  • this no longer depends on forced callback injection

What the probes actually proved

Run v1b reaches:

  • L00C20B at frame 1562
  • first 01:C1D2 at frame 1577
  • L00BE76 at frame 1616
  • L008B87 at frame 1706
  • 01:902D at frame 1857
  • first active_main = 02:9016 at frame 2014

Run v2 reaches:

  • L00C20B at frame 1584
  • first 01:C1D2 at frame 1599
  • L00BE76 at frame 1646
  • L008B87 at frame 1736
  • 01:902D at frame 1887
  • first active_main = 02:9016 at frame 2044

In both runs:

  • $1C70 stays 0
  • $1C76 flips from 0 to 1 only after L008B87

So these are not clock-slot runs.

They are the recovered default-rival baseline.

The remaining blocker is narrower now

This is the real value of the checkpoint:

the blocker is no longer “can this front-end path reach gameplay organically?”

That answer is now yes.

The blocker is now:

can I move the input to the bottom-right clock slot after 01:C1D2 is
already live, so $1C70 actually leaves 0 before the same corridor falls
through L008B87?

That is a much better next target.

The next probe is no longer generic.

It is specific:

  • inject right+down only inside the live 01:C1D2 window
  • keep the already recovered default-rival run as the control case
  • compare the later $1C76 = 0 path against the now-closed $1C76 = 1 baseline

Top comments (0)