From Seeded State To Scheduler Rails In The TD2 SDL Port

The latest checkpoint on the Test Drive II SNES port closes an important architectural gap.

Up to this point, the SDL runtime could load design packs, seed SNES-like state, render natively from VRAM/CGRAM/OAM/PPU, and compare itself against trusted extracted frames. That was a good bootstrap, but it still depended on a seeded callback shadow for the semantic side.

This checkpoint promotes a minimal callback scheduler into the runtime.

What changed:

• the runtime now resolves scheduler profiles instead of seeding callback state only once at init
• the first three promoted rails are now executable in the SDL port:
  • intro_noinput
  • menu_gameplay_entry
  • gameplay_live_race_mid
• the intro rail now carries the validated handoff from 01:9FE5 into 00:8029 through the 986 -> 1117 window
• the menu rail now covers the input-driven corridor from 1500 -> 2050
• the gameplay rail now covers the reproducible live-race seed over the promoted 3 -> 11 window

I also fixed a practical blocker in the content pipeline: tracked investigation bundles without layers/main_visible.ppm can now load directly in the runtime as long as compare is not requested. That matters because the most useful menu/gameplay design packs are often raw-state bundles first and compare goldens later.

Validation for this checkpoint is intentionally cheap and explicit:

• make -C port test
• regression smoke still passes
• compare lane still passes on the promoted intro fixtures
• intro callback model smoke passes
• new scheduler smoke passes across intro, menu, and gameplay rails

The important part is not that the scheduler is complete. It is that the port is no longer locked into intro-only seeded playback. The same runtime loop now has a viable proving path on menu and gameplay surfaces, which is where the next input and ownership work should happen.