Porting Test Drive II from SNES to PC, Part 40: Narrowing the Post-02:9016 Divergence Window

#reverseengineering #snes #gamedev #retrogaming

This follow-up checkpoint is smaller than the last one, but more useful than it looks.

In Part 39, I closed the no-opponent clock path into the same later 02:9016 gameplay corridor as the default rival path. The next question was obvious: once both runs have converged to that shared corridor, what is still different?

The comparison window

I promoted a small reusable tool for this:

tools/compare_boot_probe_windows.py

Then I compared the recovered default-rival run against the recovered no-opponent clock run over the first shared post-handoff window:

frames 2044..2199

That is the first stable stretch where both runs are already inside the same later callback family.

What stayed the same

Across all 156 compared frames, both runs keep the same callback surface:

main = 02:9016
irq = 01:96A0
nmi = 02:8F3C

And out of the sampled probe fields, 54 remain identical across that whole window.

That matters because it means the remaining split is no longer a broad “different path” problem. The two lanes are already sharing the same corridor.

What is still different

Only 14 sampled fields differ at all.

The stable selector split is still there:

rival path: $1C70 = 0, $1C76 = 1
no-opponent path: $1C70 = 3, $1C76 = 0

But the more interesting part is the narrowed set of post-handoff fields that still diverge inside the shared corridor:

state_09a2
state_09a8
paired DP scratch fields such as $0020/$0022 and $0053/$0054

That is a much better search surface than “something after the clock path must be different somewhere”.

Why this matters

This checkpoint narrows the next archaeology target from a whole gameplay handoff down to a small state family.

The next useful step is no longer another blind front-end probe. It is a guided capture around the first shared 02:9016 window so those remaining fields can be tied to visible behavior: