Porting Test Drive II from SNES to PC, Part 37: Narrowing the SNES clock-slot timing drift

The previous checkpoint closed the organic default-rival path:

L00C20B -> 01:C1D2 -> L00BE76 -> L008B87 -> 01:902D -> active_main = 02:9016

That left one narrow front-end problem:

can the fourth Select Opponent clock slot be chosen organically in the same
live corridor?

This checkpoint does not close that slot yet.

It does something almost as useful:

it proves why the obvious fixed-frame approach is still failing.

The remaining problem is not the button map

Static bank-1 reading at L00C32A..L00C371 already showed that the input loop
applies vertical and horizontal bits in sequence.

So right+down is not being discarded because of a bad button interpretation.

The problem is timing.

More precisely:

the live 01:C1D2 window itself keeps sliding when the earlier confirmation
windows move.

Two bounded follow-ups prove the drift

In v3, I moved right+down later and kept start relatively early.

That run reaches:

• L00C20B at frame 1600
• first 01:C1D2 only at 1615..1617

So right+down at 1600..1605 was still too early.

The run simply fell through the already-known default-rival path again.

In v4, I delayed the later confirmation window to create more room.

That changed the corridor itself:

• L00C20B moved to frame 1613
• first 01:C1D2 moved to 1628..1637

So the delayed right+down at 1620..1625 was still too early too.

This time the run only reached L00BE76 and then stayed on the later
01:BE43 callback in the sampled window, without falling through to
L008B87 or 01:902D.

Why this matters

This is a real narrowing, not a failed rerun with no information.

The remaining clock-slot problem is now better described as:

• callback-relative timing drift

not as:

• uncertain button semantics
• generic “needs later frames”

That changes the next probe design.

The next move is stricter now

The next defensible probe is no longer “slide the absolute frame numbers
forward again”.

It is:

• overlap right+down with the live 01:C1D2 window itself
• or trigger the direction change relative to first 01:C1D2

In other words, the problem is now local enough that the next step should be
callback-relative instead of frame-absolute guesswork.