Doom: game logic / demos run 1.5-2x too fast (audio fine)

[JoeMatt]

Symptoms

User report from real hardware (iPhone 16 Pro Max, RetroArch release build):

• Doom (Atari Jaguar) game logic runs noticeably faster than expected
• Demos play "hyper fast"
• Regular gameplay: enemies shoot and run at ~1.5–2× their normal pace
• Audio is fine — no stutter or speedup, suggesting the audio pipeline (DSP / I2S / SCLK) is rated correctly
• This is rendering / game-engine speed, not the emulator's host frame-rate

Likely scope

If audio is rated correctly (60 Hz frame budget honored, DSP ticks at expected SCLK), then the wall-clock-per-emulated-frame is right. Doom's internal tick counter must be advancing too quickly. Doom Jaguar uses one of:

• VBlank IRQ from TOM
• JERRY PIT timer IRQ
• 68K poll loop on HC / VC / PIT registers

If any of these fire more often than they should per real-time second, Doom's gametic advances faster, enemies move faster, demos play faster. Audio stays correct because it's clocked off SCLK independently.

Suspect commits (recently merged to develop)

In rough order of suspicion:

1. 1ca2fdc Improve counter/timer accuracy (TOM HC, JERRY PIT reads) — replaced rand()&0x03FF HC stub with deterministic 0/HP/2 values per halfline. If Doom polls HC waiting for a transition, previously-random returns may have masked a bug; now it consistently exits the wait at one specific point.
2. 4fcf958 Fix emulation accuracy: resolution, 68K instructions, events, RAM init, logging (Fix emulation accuracy: resolution, 68K instructions, events, RAM init, logging #119) — large CD-derived merge. Notable: event system zeroed eventTime on init and checks all slots in GetTimeToNextEvent (was reading slot[0] unconditionally even if invalid); 68K MULL/DIVL via IllegalOpcode trap; 68K BSR.L $61FF fix; Doom resolution hack removal.
3. 1718703 HC bit 10 for OP half-line detection — sets bit 10 (0x0400) on HC during odd halflines for OP CONDITION_SECOND_HALF_LINE. If Doom (or the OP) responds to this differently than before, frame pacing could change.
4. 8f7efda Fix timing rollover and due event handling — directly changes when events fire.
5. 01c6c4b Fix JERRY interrupt control decode — directly affects JERRY IRQ generation.

What's needed to bisect

• A reproducible Doom test case (state file + repeatable input sequence)
• Per-commit headless measurement of "VBlank IRQs fired per emulated second" (should be 60 NTSC) — adding this to the BENCH_PROFILE counter set is a planned follow-up

Workaround (if any)

User can try the fast blitter as a temporary mitigation if they haven't already — this won't fix the timing bug but keeps the rest of the experience playable.

Related work

• PR perf(blitter): +15% AvP gameplay accurate via inlining ADDARRAY/DATA/COMP_CTRL #129 (just merged) ships make benchmark BENCH_STATE=... which can load a save state and measure per-frame timing variance. Useful infrastructure for bisecting once we have a Doom save state.
• Acid-test ROM toolkit (PR acid: scaffold synthetic-ROM test toolkit #130) — eventual home for a deterministic VBlank-rate test that would catch this in CI.

Will start a focused branch to bisect once we have a Doom state file or other reliable repro.