bc6354dce0
1/60 s, and the 60 Hz reading is excluded ui-keyframe-time-unit.md named its own re-test and nobody had run it: time 300 submitted frames on the IDLE title, where nothing is streaming from the ISO. Reaching the title is cheap now that one A skips the intro, so this cost one boot. Two clean trials: 300 frames in 10.40 s and 10.60 s, i.e. 28.8 and 28.3 fps. That is the same rate as the 27.6 fps measured during the loading splash, which is exactly the page's own criterion for "the game is 30 Hz and the unit is 1/60 s". The 60 Hz alternative is now excluded rather than disfavoured: it needs the emulator at 47% of real time while sitting idle on a screen the capture says costs 1526 draws over 300 frames, about five per frame. Nothing there halves an emulator. So the durations stand as written -- title 4.2 s, main menu 1.1 s, EXTRAS 0.87 s -- and Q1 leaves the handoff's open-residue table. It stays MEASURED, not decoded: no field on the disc says sixtieths of a second. One trap, and it nearly cost the conclusion. My first attempt reported 39.5 fps, which sits between the two hypotheses and would have left the question open. It was a harness bug: I polled the log for a "done" line rather than for the COUNT of them increasing, so it matched a capture that had already completed and timed 0.1 s of nothing. METHOD gets the general form -- a log-polling probe must compare a count, not test for presence.