# The mission clock is running — the runs were too short in *game* time Status: 🔴 "the phase clock is stopped" is refuted; ✅ something advances linearly at ~16.5–17 /s; 🟡 the leading explanation for six arrival-free runs is now that they covered far less game time than wall-clock time; ❔ the counters' exact identity is not established. ## 🔴 Refuted: the clock is not stopped [mission-arrival-watch.md](mission-arrival-watch.md) named this the prime suspect — every "no arrival" result was equally consistent with a scheduler that simply was not running, and nothing had checked. `tools/re-capture/timer_probe.py` takes three equally-spaced snapshots of the game heap (`0xBC000000–0xBE000000`, 32 MB) **with no pilot**, i.e. in exactly the condition where nothing was observed to change, and looks for words whose two successive deltas are both positive and agree within 12 % — linear, not merely noisy. ``` actual gaps: 20.1s, 20.5s region 32.0 MB linearly-increasing words: 286 rate histogram (/s): [(17, 111), (27, 27), (44, 19), (1, 10), (47, 10), ...] va 0xbc4428a8 14193 -> 14519 -> 14863 16.5/s va 0xbc65c948 14195 -> 14521 -> 14865 16.5/s va 0xbc668648 14193 -> 14519 -> 14863 16.5/s (and many more identical) ``` 286 counters advance steadily, a large cluster of them in lockstep at **16.5 /s**. The guest is running. The stopped-clock explanation is dead. ## 🟡 What this probably means: the runs were far too short **16.5 /s is the emulator's frame rate, not a coincidence.** The existing performance work records Canary playback on this box at roughly **14–19 fps**, and the dominant counter rate sits squarely inside that band. These read as per-frame counters. If the mission's scheduler is frame-driven and the title targets 30 fps, then game time advances at about **55 % of wall-clock** here. Every run so far: | run window (wall) | approximate game time | |---|---| | 168 s | ~92 s | | 190 s | ~105 s | | 240 s | ~132 s | `Route_S02.tbl` schedules phase-1 arrivals at t = 90, 120, 170, 210, 240. So the longest run reached roughly t = 132 of game time — **past the first two scheduled arrivals but nowhere near the last three**, and the shorter runs barely reached the first. That is a mundane and sufficient explanation for a string of empty results, and it does not require the event-gated model to be wrong or the timetable to be in frames. It is 🟡 rather than ✅ because two links in it are assumed, not measured: that these counters are frame counters, and that the game's own tick is 30 Hz. ## ❔ What the counters are is not established The value does not fit a naive frame count. The dominant cluster read 14193 at the first snapshot, roughly 255 s of wall-clock after emulator start — 14193 frames at 16.5 /s would be ~860 s, and at 30 /s ~473 s. Neither matches, so these are not simply "frames since boot". They advance in lockstep and at frame rate, but their origin is unknown and no claim is made about which one, if any, is *the* mission clock. ## Next: one long run The decisive test is now cheap in design and expensive only in wall-clock: run the arrival watch for the longest window the turn allows (~350 s of probe after a ~210 s boot) and check for `0 → n` around **t ≈ 163 s and 218 s wall**, which is where the t = 90 and t = 120 route entries land at 55 % speed. If arrivals appear there, the timetable is in game-seconds and the clock model is confirmed. If 350 s still yields nothing, the frame-rate explanation is itself refuted and the event-gated model returns as the front-runner. The boot's ~210 s title movie is the binding constraint on how much game time a single turn can observe, and is worth attacking separately if this becomes the limiting factor.