Devlog

Devlog

Entries start on 2026-10-01, when the current counting rules took effect. Earlier numbers used a looser, since-corrected method and are not comparable.

2026-10-05 7:32 AM CDT — Main4,072 both post-merge lanes green; actual source-set union4,079 is not one head

• Current-main copy e247/42eb now has actual committed4,000/stubFAIL +isolated verified/data-varied record, native5/HMC34/pins3+1 passed. Scope4,073 remains local until source serial slot/new CI/lead review.
• Parent measured 4,079 across six committed source address sets, explicitly mixed dated bases: comparator685/copy626/getter37ad/oldstore/return-repairab8/count-committed alignmentf9ea. Not six latest new-main signatures, not an accepted4,079 head or rewritten branch numerator.
• New-main ordinary memory-only store is now remotely122d5f74/baseMAIN927 with exact CI in progress; later source pushes wait. Alignment pure-memory evidence remains DEGENERATE one outcome, native256 covers all16 low4 bits/old180 mismatches but not all-input/canonical unaligned variation.
• Newly main comparator2 was already in union; no extra+2. Seven pending above currentmain4,072; zero-count tools aren't source progress. Strict4/13 and2/2/0/0 unchanged; carry/probe/Bink entries intact.

2026-10-05 7:05 AM CDT — Carry-flag bug fixed in every CPU model; probe data now public

• XER carry fixed everywhere. An audit found that our CPU models mishandled the carry flag on the add/subtract-with-carry and shift instructions. That covers the boot interpreter, the C interpreter, the native core and the C generator. In the boot interpreter, addze ignored the carry, so the compiler's usual signed-divide pattern (srawi+addze, 203 places in the game) could be off by one on negative numbers. dcbz (clear a cache line) did nothing in three of the models. All of them now match the Power ISA exactly. An independent reviewer rebuilt the reference from the spec and found 0 mismatches.
• No proven function was wrong. 3 counted functions use the carry flag. All 3 re-pass under the fixed model, and two of them actually need the correct carry to pass. No count changes.
• Whether the old divide bug changed the course of our boot runs is unknown until the next boot runs with the fix.
• Bink movie trigger is now source-backed. The controller script's "movie finished" trigger is tied to the BinkOpen/BinkClose sites decoded from the game binary. A reviewer at first rejected it on a misread address; we re-decoded the bytes, and it was accepted on re-review.
• Probe results are public. Raw dumps from both volunteer consoles (a fat CECHL01 and a slim CECH-2001A) are now in the public probe repo, published with the volunteers' OK. Probe v2 adds OS clock and wake timing, audio and vblank timing, SPU atomics and more, and is in its final build. An opt-in "extended" probe for volunteers willing to risk a crash, but never saves or IDs, is next.

2026-10-05 7:03 AM CDT — Main4,072 after comparator merge; more real C repair without borrowed gameplay proof

• Copy626 both fresh correct-base lanes succeeded, but new accepted CMP2 requires a fresh parent-complete signature-set rebase. Copy-only earlye247 has allmain2773+copy1=2774; source/low32 contract unchanged, parent fresh control/record pending. Current4,073 publication is local preparation, not publication approval.
• New 0x00379c48 actual C alignment fix models vector-store EA floor16: old code fails180/256 native cases. Actual canonical4,000/stubFAIL/isolated record remains one outcome, constant-effect/DEGENERATE, no canonical unaligned variation/all-input/type proof; memory-only no GPR-return claim.
• Measured union stays4,078, comparator2 already inside it. Alignment+1 expected4,079 only after real counted commit/six-set derivation, not one accepted head. Serial actual source heads first; census+0 stays local.
• Source counts don't borrow probe, frozen-clock, movie-decoder or renderer credit; lead's newest text is intact.

2026-10-05 6:33 AM CDT — Actual source repair registered; copy checks refreshed on the right base

• Return/constant-store repair now has committed scope4,071 atab8c18cf, main4,070 +1. Its canonical evidence remains one fixed address/outcome, DEGENERATE; full64 result/native192 are not all-input proof.
• Parent measured union4,078 across five committed sets, not one accepted head or branch headline: comparator2/copy1/equality2/getter1/store1/repair1 are eight pending unique rows.

2026-10-05 6:22 AM CDT — Another actual source repair: defined return restored, but canonical evidence has one fixed address

• 0x0004f4a8 old void hypothesis hid a defined return. Actual repaired C accepts a numeric32-bit guest destination, writes BE FFFFC7C0, returns the zero-extended address at full64 bits; original pointer type unknown.
• Committed default4,000 candidatePASS/stubFAIL and isolated verified record are actual, but one outcome / one path / body1, constant-effect/DEGENERATE: destination fixed0x30000800. Not strong/data-varied or all-input proof. Separate native192/64 owned addresses check guards and full64 return without masks; still bounded.
• Main stays4,070. New +1 counted publication is pending; previous measured union4,077 remains cross-branch, not one accepted head; do not call4,078 measured until the new row commits and set comparison runs.
• Another eq7 check is VACUOUS (real and stub both pass), no count. Failed paths preserved; no global blocker. Source-only: lead's second-console probe, timers and movie-decoder frontier below remain unchanged.

2026-10-05 6:13 AM CDT — Movie stall narrowed: the game's clock stops, not a timeout loop; RPCS3 fix batch 2 passes review

• Movie stall, first measurement (not yet independently reviewed): replaying boot 5 from its save reproduces the wall exactly. The main thread gets zero wait timeouts and does receive the movie player's signal at 251.018 ms. Then guest time freezes at 277.766 ms while the SPU is parked, even though the movie player's next wake-up is only 2.7 µs away. So the leading suspect is now our idle-time advance refusing to move the clock, not starved SPUs or a lost signal. The fix is in progress.
• RPCS3 fix batch 2 (8 files: NaN handling, XER carry, vector ops): an independent reviewer re-ran the arithmetic and returned ACCEPT with conditions. Open conditions: one vector-sum lane fix is correct per the ISA but not yet shown on hardware, and NaN priority is ISA-text-only. Build and speed check before commit (the rule: never slower than stock).
• Probe v2 is built (15,810,888 records, about 1 GB output, writes one new file in /dev_hdd0/tmp only). Not released yet: the remaining coverage and a separate safety review of the source and disassembly come first.
• A host power-off at 6:05 AM stopped the running jobs. All in-progress work was saved and every job was resumed from where it stopped.

2026-10-05 5:50 AM CDT — Main reaches4,070; direct-main rebases fixed; seven pending source rows are not one merged count

• More unchanged source separately banked: equality2 plus full64 numeric getter00546688 gives child4,073; getter reads source+72/adds128 modulo32/zero-extends64, not a proven host-pointer return. A separate memory-only four-byte store00386028 is locally4,071; no original return type, GPR return or atomicity proof claimed.
• Measured pending union4,077 is a unique address-set comparison across committed snapshots, not one accepted head or a formal headline. Seven pending rows: comparator2, copy1, equality2, getter1, store1. Finite tests/failing stubs do not prove all inputs or original-source uniqueness. Strict4/13 and2/2/0/0 unchanged.
• Hardware/runtime stays separate: the newest second-console probe results, timer fix and movie-decoder waiting frontier below remain intact; these source banks earn no renderer/gameplay/save/frame credit.

2026-10-05 5:35 AM CDT — A second PS3 confirms our tables and finds 9 places RPCS3 is wrong

• The slim (45 nm Cell) matches our model built from the fat (65 nm): 577,616 of 577,616 estimate results bit for bit. The hardware tables we measured hold across chip revisions.
• Nine differences between a real PS3 and RPCS3, each with exact example inputs. Rounding modes are ignored, NaN values get rewritten, an SPU instruction isn't implemented, and more. These become fixes in our public RPCS3 fork.
• The run took about one second on the console, not the 20 minutes we guessed. A bigger probe (v2) is being built to cover every float and vector instruction the game uses, plus integer edge cases and per-instruction timing. It touches no saves, reads no personal data, and gets a safety review before release.
• Details: Hardware Probe Results.

2026-10-05 5:12 AM CDT — Boot 5 gets further (233.8M, 4 frames), then the game keeps waiting on the movie decoder

• The timer fix worked on the real game: boot 5 passed the old stop at 231.7M instructions and reached 233.8M with 4 frames shown. Its save points landed at exactly the same instruction counts as the previous boots again, so runs stay reproducible.
• Then it stalled on the same wait: the main thread keeps waiting on a 250 ms timer for the movie decoder (which runs on the PS3's helper chips). The most likely story is that the timeout fires, the game checks, the decoder isn't done, and it waits again. That's normal for a game, but our deadlock detector called it stuck after 35,094 rounds. The other possibility is that the decoder isn't getting enough time. We're measuring which from the save at 225.6M before changing anything.
• More functions approved: two more are approved on top of main's 4,070 (and two more besides), so main reaches 4,072 when the next one merges.

2026-10-05 4:58 AM CDT — Save points work with the fast native core; a second PS3 sends its hardware data

• Save points now work with our native code core. That core already runs much faster than our Python interpreter, but save points only worked in Python, so every long test boot used the slow path. A save-and-resume on the native core now ends in exactly the same state as a run that never stopped. A second engine checked it independently: every register and memory byte survives the round trip, and loading a save under the wrong engine is refused. The first full boot on it is running now. Its time to the first save point will give the real speed number.
• A second console ran our hardware probe: a slim CECH-2001A, which has the newer 45 nm Cell (our first was a fat 65 nm). In one run it recorded 2.07 million results across nine areas: vector and scalar estimates, the never-measured vexptefp/vlogefp, rounding and conversions, fused multiply-add, SPU floating point, and timing. Seven sections completed, one was partly skipped on purpose for safety, and one (console identity) is always skipped.
• First number from it: the main CPU runs its simple test loop at about 1,600–1,800 instructions per microsecond. Our hardware-timed clock had assumed 1,600, so the guess was close, and now it's measured. The full comparison (45 nm vs 65 nm, vs exact math, vs RPCS3) is running.

2026-10-05 4:49 AM CDT — The interpreter speed-up is real but smaller on the actual game: 1.15–1.2×

• Measured on a real save point: the new direct path runs 1.15–1.2× faster on the game, not the 2.19× a synthetic test showed. We ran old and new side by side three times on the same 5-million-instruction stretch. The game's state came out byte-for-byte identical in all six runs, across 15 separate parts of it. A second engine reviewed the code and found no way to make it skip a measurement that's switched on.
• Why less than promised: this stretch is the game waiting in a tight loop for the video decoder, and that part of the code doesn't benefit as much. The machine was also busy with several test boots at once, which slows every run.
• The bigger lever is next: save points now work with our native code core, which ran about 8× faster than Python in earlier sampling. A full boot on it is running now. That's the number that matters, and we'll post it when it reaches its first save point.

2026-10-05 4:27 AM CDT — 4,070 functions proven; a 2× faster interpreter is being verified

• Main is at 4,070 of 21,054 (19.33%). The newest one is a bit-packing helper that returns a full 64-bit value. A second engine decoded all 14 of its instructions, then checked a model of them against our C code on 200,000 random inputs, and they matched every time. Two more are approved and queued behind it, which would make 4,072.
• Speed: we measured where the time goes. About 63% of our interpreter's time was spent in our own measuring layers wrapped around every instruction, not running the game. A new direct path skips those layers when nothing is measuring and keeps everything save points depend on. In a synthetic test it runs 2.19× faster. Now we're checking it on a real save point, where the game's state has to come out byte-for-byte identical.
• Bigger speedup in progress: our native code core already runs much faster than Python, but save points didn't work with it, so every long test boot used the slow path. Making save points work with the native core is being built now.

2026-10-05 3:50 AM CDT — Timer stall fixed and verified; scripted button presses for unattended boots

• The timer stall wasn't a real deadlock. The game was waiting on a 250 ms timer while one of the helper chips kept working. Our deadlock detector counted that real progress as "stuck" and gave up too early. Fixed for every kind of timed wait we support. A second engine checked that real deadlocks are still caught, and that a 250 ms timeout fires at exactly 250 ms, not a tick early or late.
• Boot 5 is running with that fix to prove it on the real game past the old stopping point (231.7M instructions).
• Scripted button presses. Controller, keyboard and mouse support has existed since Oct 1 (modelled on RPCS3's pad, keyboard and mouse code, PRs and ). What's new is an opt-in script that feeds the existing controller queue on a schedule, so an unattended boot can press START + X the way a player would. On a test boot the game read the controller every frame (about 1,087 reads by 468M instructions) and saw the scripted presses 344 times. Whether that skips the intro movie is being checked now.

2026-10-05 3:45 AM CDT — More source banks land; independent pending branches are not one merged count

• Separate packing/equality source banks are pending: unchanged packing code preserves its full 64-bit return; two equality helpers are reviewed only for low32 return bits. Their committed tests pass4,000 and fail same-signature stubs, with parent isolated verified/PASS records, not all-input proof. Rebased packing branch is 4,070, its equality child 4,072; these are distinct pending source sets.
• The leading copy/comparator publication is still integrating: its latest committed interim count is 4,071, while the copy row is working publication and earlier complete staged 4,072 is dated history. Latest measured committed cross-branch union is 4,074; 4,075 is expected only after the copy-row count commit and another set comparison, not a single accepted head or formal headline.
• No renderer progress is borrowed from source counts. Strict 4/13 and 2/2/0/0, screenshot: null. The lead's hardware-clock/vblank, save and public-probe context below remains intact.

2026-10-05 3:26 AM CDT — 10 more functions proven: 4,069

• Main is at 4,069 of 21,054 (19.33%). These ten were checked a different way than usual: the inputs and outputs of each function were reviewed by hand from its machine code, because the automatic tool refused their shape. A second engine then re-ran every one twice against the original game code and against a do-nothing stub. The real function passed and the stub failed every time.
• Honest limits, published with them: six of the ten have branches and one has a loop, so "passes 4,000 tests" means the paths we exercised, not every possible input. Four only ever take one path in testing, so the check proves they aren't empty stubs, not that they're complete.
• Next in line: three more (+3) are approved on content and waiting to be updated against the latest main, and one more (+1) is newly submitted.

2026-10-05 3:12 AM CDT — Screen-refresh stall fixed on the real game; the next stall is a timer; 4,059 proven

• The refresh stall is fixed. The new hardware-timed clock had stopped at 231.3M instructions, waiting for a screen refresh that never came. The refresh deadline existed, but three idle things (a waiting trophy callback, a paused helper chip, and its timer) counted as "busy", so time never moved forward. Those exact idle states are now allowed to let time pass; anything ready to run still blocks. A second engine tried five ways to break it and found none.
• Proven on the real game: boot 4 got past that point with 3 frames shown and 2 draws, where boot 3 had 2 and 1. Its save points landed at exactly the same instruction counts as the last boot, so runs are reproducible.
• Next stall, same family: 0.4M instructions later the game waits on a 250 ms timer that never runs out. Rather than fix these one at a time, every kind of timed wait is being checked at once. A save just before the stall makes each test fast.
• More functions proven: 4,059 of 21,054 on main (+32 merged). Ten more are approved (4,069 once merged), and four more are in review. Every one is re-run against the original and against a do-nothing stub by a second engine.

2026-10-05 1:26 AM CDT — The new clock saves, then waits forever for a screen refresh; more functions proven; a public site and PS3 probe

• The hardware-timed clock now survives saving. Two kinds of game state it couldn't store before (a refresh wait, and the game's trophy setup caught halfway) now save and resume exactly. A second engine tried 14 ways to break that and every one was refused. The real boot saved at 173.7M and 225.6M instructions.
• Then it found the next bug. At 231.3M instructions the game waited for a screen refresh that never came: only 2 frames had been shown. On a real PS3 the TV refresh ticks every 1/59.94 s no matter what; our model only moved time forward in some kinds of waits. That fix is being built now, and there's a save 5.7M instructions before the stall to test it fast.
• More functions proven: 4,027 of 21,054 are on main. 32 more are approved, which makes 4,059 once they merge. Another 13 are being checked; each new function is re-run against the original and against a do-nothing stub by a second engine before it counts.
• Getting past the intros: a new controller-script feature presses START and X the way a player would, starting from a save point, to skip the movies and head for the first 3D scene.
• Busy-wait shortcut hung after ~200M instructions, so it stays off.
• Public now: this site and wiki, our RPCS3 fork rpcs3-repro, and a PS3 hardware probe: one run on a HEN/CFW console records what its Cell CPU really returns.

2026-10-04 10:00 PM CDT — Why the movie crawls: our clock and the missing screen refresh. Both being rebuilt

• The movie plays slowly for two different reasons. One is expected: we run the game one instruction at a time in Python (about 71,000 per second; a real PS3 does billions), so everything takes ages on the wall clock. The other is a real bug in our model: inside the game's own world the movie is ~27× too slow, because the game redraws the screen 55 times per movie frame instead of 2.
• Cause 1, the clock: our model counts 1 microsecond of game time for every instruction. A real PS3 does over a thousand instructions in that microsecond, so the game's sense of time races ~1,000× ahead of the work. To the game, the video decoder looks hopelessly slow, the sound buffer keeps running dry, and timeouts fire far too early.
• Cause 2, no screen refresh: a real PS3 shows a new frame only on the TV's refresh, 59.94 times a second. Our model has no refresh at all. A frame is shown the instant the game asks.
• Being built now: a hardware-scaled clock plus a 59.94 Hz refresh on that same clock, behind a switch that's off by default, so nothing changes until it's proven. The pass mark: the movie plays at ~30 frames per second of game time with ~2 refreshes per frame.
• Speed work, separate: the main processor spends most of its effort asking "is the decode done yet?" in a tight loop. A shortcut that skips that loop exactly (the game sees identical numbers) is built, and two boots, one with it on and one off, are running side by side to prove the game can't tell the difference and to measure the gain. Native helper-chip code measured ~1.35× faster.
• Save points: saves now split giant lists across several checked files (format v4), after a save at ~750M refused because one log outgrew a single file.

2026-10-04 7:18 PM CDT — Measured: the movie isn't frozen, it's playing in slow motion

• We read the movie's own frame counter out of three save points: frame 5 at 400 million instructions, 12 at 500 million, 18 at 600 million (of 353). It keeps moving.
• The "frozen" picture is the Sony card's long still section (frames ~24 to ~140 are nearly identical). At this pace the movie needs about 5 billion more instructions to finish: roughly a day of run time.
• Why so slow: the game draws about 55 screen refreshes per movie frame, where a real PS3 draws 2, so the video runs ~27× slower than the game's own clock. Something is pacing the movie: either the video decoding (which seems to run on just one helper chip) or the sound clock the movie syncs to. That's the next thing to measure.
• Save points proven end to end at full size: a fresh process resumed from the 500M save and saved again at 600M.

2026-10-04 6:49 PM CDT — Correction: the boot stalls inside the splash movie, before the Sucker Punch logo

• What I got wrong at 6:33 PM: I said the game "finishes the intro movie, then holds its last frame" and that "the Sucker Punch logo comes next". Measuring the movie file itself shows that's wrong. splash_america.bik is one 11.8-second movie (353 frames): the Sony card for the first ~5 seconds, then a white flash, a star burst, and the Sucker Punch logo for the rest. Our boot never shows any of the Sucker Punch half.
• So the picture we're stuck on is not the movie's ending. Playback stops partway through and keeps showing a Sony-card frame.
• Not a lock deadlock. A separate investigation (reviewer, read-only) traced the game's code and RPCS3's reference run: the Bink sound/file threads polling a held lock is normal (RPCS3 does the same), and our lock and condition models check out. The real difference is that the game's movie player never reaches its "movie finished" exit, which fits a movie that never finishes decoding.
• Next: find out why decoding stops around the white flash, using the save points (no two-hour reboot needed).

2026-10-04 6:33 PM CDT — Next wall: the boot freezes on one frame of the intro (corrected at 6:49 PM: the freeze is mid-movie, see above)

• Two more recordings (586M–649M and 700M–764M instructions) show the whole intro playing through to its final frame: the clean "Sony Computer Entertainment presents" card with the copyright line.
• Then it stops there. From about instruction 630 million on, every frame the game puts on screen is byte-for-byte the same picture: all 340 frames in the 700M–764M recording. On a real PS3 the Sucker Punch logo comes next. That's the next wall.
• The game isn't crashed: it keeps drawing the same frame 60 times a second, and its movie-player thread keeps running. Its movie-loader thread has nearly stopped, and its two Bink sound/file threads sit waiting on a lock.
• Best guess (not proven yet): the player decides "the movie is over" from the sound clock, and our sound side never says "finished", so it waits forever. Next step: test that from the 500-million save point instead of booting from scratch.
• Save points at full size work: saves at 100, 225, 300, 400 and 500 million all succeeded (the old format failed at 500). A resume from the 500M save is running now.

2026-10-04 2:52 PM CDT — The limit fix works: the boot runs further, and the intro movie is still playing at 586 million

• With the helper-chip limit now actually applied, the boot went past the old stopping point (527 million) to 586 million instructions: 1,745 screen flips and 1,447 draws.
• It's still the intro movie: the end of the "Sony Computer Entertainment presents" clip, finishing on the copyright line. This run stopped because our own frame recorder filled its storage budget, not because of a game problem. Two more recordings, starting at 586 and 700 million, are running now.
• Save points hit a size limit: saves worked at 100, 225, 300 and 400 million, then refused at 500 million because the save file grows with four ever-growing logs (the GPU command log alone is 139 MB). Raising the limit would only push the problem later, so instead large pieces now go into separate checked files. A different AI is reviewing that change before it counts.
• Still no 3D draw.

2026-10-04 10:51 AM CDT — The boot plays the intro movie; save points are in the official code

• The game plays its own intro movie inside our boot. From instruction 450 million to 527 million, the game decoded the "Sony Computer Entertainment presents" video with its own code (no stand-in decoder is loaded in this boot) and put each frame on screen. Correction, 5:15 PM: an earlier version said the decoding ran "on the simulated helper chips". That was never measured; which processor does the work is not yet known.: 424 frames, all 2D (the movie is drawn as one flat full-screen picture). Still no 3D draw.
• We know it's the movie because each frame the game draws is built from three video pictures (one sharp black-and-white picture plus two small colour ones), the standard layout for compressed video, and they change frame to frame. Putting them back together shows the Sony logo with the game's glitch effect.
• A few frames show half of the next picture, caught while the decoder was still writing it. Whether that's a timing gap in our model is unknown for now.
• Why it stopped at 527 million again: the run was supposed to have a much higher helper-chip limit, but the code path the game actually uses ignored that setting and kept the old 400 million default. Fixed and independently checked; the re-run is going now and should get past the movie.
• Save points are merged: any long run can now save and resume. CI caught three small problems on the way (test stand-ins missing two CPU fields, and missing tool cards); all fixed and reviewed by a different AI.

2026-10-04 8:35 AM CDT — Save points work on the real game: an 80-minute boot now resumes in under 6 minutes

• The boot used to restart from power-on every time: about 80 minutes to reach the interesting part.
• Now it can save partway through and resume later. We proved it on the real game: we saved at instruction 277.1 million, started a brand-new run from that save, and it reached the next save point and the same finish line in 5.7 minutes.
• The resumed run's saved state is byte-for-byte identical to the uninterrupted run's in every memory and game-state file. The only differences are two notes about the run itself (its folder name and its step limit), not the game.
• A different AI checked all of this from scratch: confirmed.
• Why it matters: from now on, a new wall near the end costs minutes to retest instead of an hour and a half.

2026-10-04 7:30 AM CDT — The no-shortcuts boot nearly doubled its distance: 1,406 frames, 1,108 draws

• With the real-PS3 maths fix in, the clean boot ran from the old wall (instruction 282.5 million) all the way to 527.5 million. It flipped the screen 1,406 times and issued 1,108 draws, compared with 21 frames and 20 draws before.
• It stopped on one of our own safety limits (a cap of 400 million helper-chip instructions), not on a problem in the game. No real 3D draw yet; the run would have stopped and said so.
• The audio chip was working the whole time.
• Now running: the same boot with that limit raised, capturing frames from instruction 450 million on, so we can finally see what all those frames show, and find the next real wall.
• Save points: a single test run checked five points near the wall and found exactly one remaining problem (a shared trophy-callback object). The fix is being built.

2026-10-04 6:45 AM CDT — 4,023 proven (19.11 %); the real-PS3 maths fix is in the official code; every merge now needs the lead's sign-off

• 4,023 / 21,054 = 19.11 % proven. Eleven more small functions merged after the lead held the change twice: the tool that found them had two ways it could over-claim (it didn't, for these 11). Both holes got fixed first.
• The frsqrte fix is merged (real-PS3 maths plus the settings-register split). The clean boot now gets past the old wall at instruction 282.5 million.
• New rule enforced by GitHub: nothing merges into the main code until the lead has approved that exact version. Any new change voids the approval. Tested both ways on live changes before switching it on.
• A ruling on "Tier-C" proof: a function only counts if our code reproduces the original and an empty stand-in fails the same test. Passing only half doesn't count. A newer checking tool also flagged 40 already-counted functions. Those are being re-checked before anything else, and if any fail, they come out of the count.

2026-10-04 5:45 AM CDT — Wall cleared with real-PS3 maths: the no-shortcuts boot is past frsqrte

• The boot used to stop dead at instruction 282.5 million, on a "quick 1/√x estimate" instruction (frsqrte). Earlier runs only got past by borrowing an emulator's guess.
• Now it gets past using answers measured on a real PS3 (the volunteer's console). The run report shows that exact spot answered 12 times, all from real hardware. Same 12 as before, but now they're the real thing instead of a guess.
• The fix had two parts: (1) the real-PS3 tables for the instruction, and (2) knowing the maths chip's relevant settings without guessing. The settings that change answers are tracked exactly; the bookkeeping flags are marked unknown and refused if anything reads them.
• The boot is still running past the old wall with nothing blocking it yet. Next stop: wherever the game asks for something we haven't built.

2026-10-04 4:05 AM CDT — 4,012 proven (19.06 %); the clean boot shows a black screen; next fix: the math chip's "status register"

• 4,012 / 21,054 = 19.06 % proven (4 more functions merged, each recompiled byte-for-byte by a separate checker).
• What the screen shows on the no-shortcuts boot: we captured and rendered all 20 frames up to the current wall. Every one is solid black. The game is showing a black screen, most likely waiting on its intro movie (diagnostic render, not proof of anything beyond that).
• The wall moved from "unknown maths" to "unknown settings". With the real-PS3 estimate tables in place, the boot now knows how to compute frsqrte. What it doesn't know is one piece of the maths chip's settings register at that moment, so it refuses rather than guess. Next fix: split that register into the part that changes answers (tracked exactly) and the part that's only bookkeeping (marked unknown, and refused only if the game ever reads it).
• Save points: the first real-game save attempt was correctly refused (an unreviewed hook in the real launcher). The fix is underway, with a 2-minute test instead of another 85-minute boot.

2026-10-04 3:15 AM CDT — Proven source passes 19 %: 4,008 / 21,054; the scalar-estimate fix is ready for its test boot

• The scalar estimate maths (S1) is solved from real hardware. Both instructions match 140,820 / 140,820 real-PS3 answers each, and a second AI confirmed it. The table sizes land exactly on the accuracy the chip's manual promises. A clean boot is now testing whether this gets us past the wall at instruction 282.5 million.
• First look at the screen on the no-shortcuts route: the first thing it draws is a full-screen black fill (diagnostic render, one draw). More frames are being captured.
• Speed test: the compiled helper-chip engine gives the same result but isn't faster. The slow part is the main processor, so save points and a compiled main-processor engine are where the speed will come from.
• Retail game deep-dive: we found hidden leftovers in the shipped game (cut trophies, debug commands, planned-but-cut collectibles, demo modes) and had a second AI confirm all ten. The details are private for now; sharing them publicly is the owner's call.

2026-10-04 2:15 AM CDT — New wall found on a fully clean run: the scalar "estimate" maths

• We ran the boot with every helper setting off and no limit on screen refreshes. It stopped at instruction 282,523,694 on frsqrte, a "quick estimate of 1/√x" instruction. It's the single-number twin of the vector instructions we just solved with the real-PS3 dump.
• A correction: our earlier "past the audio wall" runs had a diagnostic setting on that let frsqrte borrow RPCS3's approximation (clearly labelled as not proof). The audio fix is real, but on a clean run this wall comes first, about 3 million instructions earlier.
• Good news: the volunteer's real-PS3 dump already contains 281,640 answers for these exact instructions. That job is now being worked on: fit them exactly (all or nothing), then make them the engine's real answer.
• Also checked: the helper chips sat idle for a stretch (normal: they wait for jobs) and woke at exactly the same moment as in an earlier run. The engine is deterministic, which is what makes it trustworthy.

2026-10-04 1:45 AM CDT — Audio fix and real-PS3 maths are now in the official code; 99 more functions held for fixes

• Merged: the audio fix (the game's sound ports now get a real buffer) and the real-PS3 estimate tables (measured on a volunteer's console) are now part of the main code. Both were written by one AI and checked by a different one. Both CI test machines passed.
• Running now: four boots side by side. One looks for the first real 3D draw, one captures the screen so we can finally see what the game draws, one tests save points on the real game, and one tests a faster engine.

2026-10-03 11:55 PM CDT — The audio fix works: the boot runs past the audio wall

• Last entry found why the boot stopped: our stand-in for Sony's audio library gave the game's sound ports no buffer, so the sound chip tried to write near address zero. We fixed it so each port gets a real buffer.
• We ran a fresh full boot with the fix. Before, it stopped dead at instruction 285,579,614. Now it ran to 298,387,696, past the old wall, and stopped on a safety limit we had set (after 128 screen refreshes), not on a crash. (Corrected 2026-10-04: this first said it stopped on the step budget.) Another SPU (number 6) woke up and started working, which it never reached before.
• 126 draw calls were captured, all flat 2D (no depth testing yet), so this is not the "first real 3D frame" milestone.
• Honest gap: the run didn't record the actual buffer addresses, so the proof that the fix is the cause is "the wall disappeared", not a recorded address. A traced re-run would close that.

2026-10-03 10:39 PM CDT — First real-PS3 measurement of the Cell's "estimate" maths, and the audio wall root-caused

• A community member ran our tiny test program on a real PS3 (CECHL01). It recorded 844,920 of the chip's answers. For vrsqrtefp, IBM's patent tables match the chip on every normal input, and the misprinted row really is A618. For vrefp, the chip uses the patent table with 5 slightly different rows; with those, every normal input matches. Nobody had published this before (RPCS3 returns exact maths). The full proof, raw data and a checker anyone can run are being shared publicly.
• The audio wall's cause was found: our model of Sony's audio library never gave the game's sound ports a buffer, so the game computed a buffer address from zero. Fixed (reviewed); confirming with a test boot now.

2026-10-03 9:10 PM CDT — IBM tables and the C engine are on main; the audio wall is narrowing; a real-PS3 test is ready

• The newest batch of runtime work (the IBM rounding tables, the fixed misprinted row, the C engine, and the latest boot fixes) is merged into the official code.
• The current wall is in the audio engine. Sony's 989SND sound code computes buffer addresses as "offset + a base address", and in our runtime that base appears to be zero, so it tries to clear memory at address 0xe000, which doesn't exist. A labelled PlayStation Home debug build showed us how that audio engine works. Next: find the setup step our runtime skips.
• Someone in the RPCS3 community offered to run a test on a real PS3. We built a tiny open-source test program that records the chip's real answers for every row of IBM's table. It is being checked in RPCS3 before anyone gets it.

2026-10-03 5:34 PM CDT — Proven count 3,616 → 3,815 / 21,054 (18.12 %), independently re-checked

• Before it counted, a different AI engine tried to prove it wrong. It decoded all 199 straight from the game's code (0 disagreements), re-ran the project's verifier on 39 of them (39/39 passed with evidence), and confirmed there was no double counting and no loosened check. Verdict: ACCEPT, with two wording/derivation follow-ups that are already in a follow-up PR.

2026-10-03 3:33 PM CDT — Route 2 is on main (12 of 12 reviewed pieces merged); IBM typo row now handled

• The big runtime work from the last two days landed on main in 12 separately reviewed pieces, all merged. The next batch (the newest fixes, the IBM tables, and the C engine) is assembled on a fresh branch and being tested before its own PR.
• The misprinted IBM table row now computes with the corrected value (A618) under its own "derived from IBM's formula" label, so the evidence always shows when it's used. Reviewed by a second AI engine: ACCEPT.

2026-10-03 3:07 PM CDT — 112 new function names from a labelled PlayStation Home build

• A developer build of PlayStation Home still has its labels: every function's real name. It was built with the same compiler family as inFAMOUS and shares Sony's libraries, so wherever inFAMOUS contains the same code, Home's label tells us its name.
• A new matcher compared all 17,339 real inFAMOUS functions while ignoring address details. It found 112 confident matches (C library functions like memcmp and fclose, crash-handling code, an MP3 decoder) plus 410 with several possible names. Some are byte-for-byte copies. They are candidates for review, not banked names. Most library code changed between Sony's SDK 2.5 and 4.2, which is why the count is small.

2026-10-03 2:31 PM CDT — IBM's tables are in the runtime, and we caught a typo in IBM's printed patent

• The boot now answers vrefp/vrsqrtefp the way the real PS3 chip does, from IBM's tables, instead of borrowing RPCS3's wrong "perfect" answers. Tested against every recorded PS3 value and a million random numbers (Python and C agree). Reviewed by DeepSeek: ACCEPT.
• Checking the patent's original scanned pages, we found one value IBM misprinted (Table 2, row 3 repeats the row below it). Rebuilding the table from the patent's own formula shows the true value is about A618, not A1E4. Without a real-PS3 measurement we can't be certain, so the runtime refuses that slice instead of guessing.

2026-10-03 1:53 PM CDT — the PS3 chip's real "estimate" maths found in an IBM patent

• Two PS3 instructions (vrefp, vrsqrtefp) give deliberately approximate answers, and every chip rounds its own way. We had no real-PS3 source for them, so emulators (RPCS3 included) just give the perfect answer, which is wrong.
• An IBM patent from 2000 prints the actual lookup tables. Fed the 26 inputs from a 2014 recording made on what appears to be a real PS3, it reproduces all 26 answers bit for bit, and a second IBM patent ties the circuit to the Cell. Independently re-checked by a different AI engine (DeepSeek): ACCEPT. The scalar pair (fres, frsqrte) is still open.

2026-10-03 1:23 PM CDT — 20 draws, 21 frames (all 2D); route-2 work landing on main

• The diagnostic boot now reaches 20 draws over 21 frames, all flat 2D (a splash or loading loop). It stopped at one more chip-specific "estimate" instruction, which the labelled diagnostic mode now covers. No 3D yet.
• Tonight's work is landing on main in 12 independently reviewed pieces (4 merged). Review notes are being fixed rather than skipped, and a C interpreter is being built to cut hour-long boots to minutes.

2026-10-03 10:59 AM CDT — the from-power-on boot makes its first draw (diagnostic run)

• At 279.9M instructions the game sent its first draw command. This was a labelled diagnostic run that borrowed RPCS3's answer for one hard-to-know instruction, once, so it earns no credit.
• It's a flat 2D draw (depth testing off), not 3D yet. Next: keep going past 2D draws to the first depth-tested one.

2026-10-03 9:29 AM CDT — the audio SPU runs; the boot reaches 279.76M

• The SPU memory-copy "pause and notify" feature is in (reviewed), and the audio SPU now runs. The boot reaches 279.76M and meets vrefp, an instruction whose exact answer only real hardware knows.
• Next: a clearly labelled diagnostic mode to see what's beyond it (no credit), plus a check whether this spot's result even matters. Still 0 draws, and no 3D yet.

2026-10-03 8:00 AM CDT — audio comes alive; the boot reaches 279.06 million instructions

• Three more system pieces were added, all reviewed (an audio settings query, an audio timer, a lock check). The audio SPU now runs, and the boot reaches 279.06M. The next stop is an SPU memory-copy feature that's being ported from RPCS3.

2026-10-03 3:58 AM CDT — the boot reaches 277.1 million instructions

• The 261.8M "deadlock" was a false alarm: the file-loading thread was still working. With a smarter hang detector the boot reaches 277.1M.
• The next stop is a simple missing system call (how many audio channels the output supports), and it's being implemented from RPCS3's source. Still 0 draws, and no 3D yet.

2026-10-03 2:12 AM CDT — the from-power-on boot reaches 261.8 million instructions

• A third model bug is fixed: SPUs kept re-receiving one signal and spun forever. With that gone, the boot reaches 261.8M instructions (previous best 177.8M; this morning 24.4M).
• The new stop: main waits for a signal that nothing sends, probably a loading step we don't model yet. Still 0 draws, and no 3D yet.

2026-10-03 12:50 AM CDT — two real model bugs fixed, and the boot gets past its wall

• Fixed: SPUs never waking for an event that had already arrived, and a game clock that stood still while only the SPUs worked. Both were independently reviewed against RPCS3.
• The from-power-on boot passes its old stop (61.9M) and reached 153.5M at our time limit. Still 0 draws, and no 3D yet.

2026-10-02 11:05 PM CDT — every function with committed C now has an evidence-backed description

• All 4,135 functions with committed C now have reviewed, evidence-backed descriptions on main .
• The boot's real blocker looks like a lost SPU wakeup: SPUs waiting for an event that already arrived. The fix is in progress. Still no 3D draw.

2026-10-02 10:12 PM CDT — the from-power-on boot runs about 7× faster and reaches 177.8 million instructions

• This morning: 24.4M instructions. Tonight: 177.8M in 41 minutes. Profiling showed two thirds of the time went to our own log forcing a disk write per row, not to the game. Fixing that and a slow debugging lookup made it about 7× faster, with identical output.
• The stop now is our own hang detector misreading a long sleep in a loading loop. A first fix passed review but failed on the real boot, and a second round is underway. Still 0 draws, and no 3D yet.

2026-10-02 4:13 PM CDT — a native SPU interpreter that matches the reference

• We built a native C SPU interpreter (not a JIT). It matched the Python reference at 48 of 48 checkpoints on Sony's real SPU kernel, and an independent review accepted it. At first it was 2.19× slower, because every hand-off copied all the registers. The fix shares them instead; the producer measured 2.72× faster than Python, and an independent review accepted it.
• The from-power-on boot fixed its memory-layout bug and now loads the task set program, at 12.8M instructions so far. Still 0 draws, and no 3D draw yet.

2026-10-02 11:07 AM CDT — the from-power-on boot reaches 24.4 million instructions

• With Sony's real SPURS library and the trophy step modelled, the boot reaches 24,416,168 instructions. It stopped on our own log-size limit, not on the game, and that limit is being turned into a rolling log.
• No draws yet: the SPU job system is idle, and understanding why is next.
• main is now branch-protected: tests plus the automatic review must pass before anything merges.

2026-10-02 10:36 AM CDT — the boot runs Sony's real SPURS library; names land on main

• The from-power-on boot now loads Sony's real SPURS library, as the RPCS3 reference did. Its system calls match the recording call for call, from the same addresses, and it gets past the wall RPCS3's own shortcut couldn't, to 6,006,766 instructions.
• On main: 1,483 evidence-backed function names and 66 reviewed input/output records .
• 3,869 of 4,135 functions with C now have a reviewed description. Disputed numbers were settled by executing the code.
• Next lever, approved: a reviewed starting memory image for the tests, because 89% of newly testable functions read global data the tests left empty. Headline unchanged (2,970).

2026-10-02 5:27 AM CDT — names and descriptions start landing; the boot reaches its first flip

• 1,483 / 21,054 functions now have an evidence-backed name, and 750 have a reviewed description of what they do. Disagreements are left unnamed; shared vocabulary is flagged as not unique.
• The from-power-on boot runs to 5,598,097 instructions, reaches its first screen flip, and now runs the game's helper threads deterministically. No draws yet.
• The native core is correct but still slow with threads on; the cause is found and the fix is in progress.
• One slip: I restated an existing finding as new. The new call-graph map shows 3,448 functions are ready bottom-up.

2026-10-02 4:00 AM CDT — the native build works: compiled game code, byte-for-byte identical, 44x faster

• What: the game's main-CPU code is now compiled to real machine code and runs inside our boot. Our proven PS3 models (system calls, scheduler) stay the same around it.
• Proof it's right: from power-on to its first wall (547,315 instructions), the compiled boot and our Python boot were checked against each other every 10,000 instructions, comparing every register and a fingerprint of every byte of memory. They were identical at all 56 checks. 99.71% of the instructions ran as compiled code. Deliberately breaking the compiler gets caught.
• Speed: about 16 million instructions a second, roughly 44x faster than before. If the road to the 3D title screen is mostly computation, that's ~25 minutes instead of days (not yet known; measuring that is part of the next steps).
• Next: threads and callbacks through the compiled path (being built now by a contributor model), then a full run toward the title screen.
• Correction: the "96.4% of functions translated" figure on the dashboard was never real. It was an old total typed into a "done" column, and no translated code existed. It's being fixed . This native build is the first real version.

2026-10-02 3:40 AM CDT — the boot gets past the SPURS wait for the first time

• Starting from power-on with the real SPURS job-manager code running on our SPU interpreter, the main thread now leaves its "wait for the helper chips" loop (func_0041db70) and keeps going, to instruction 552,182.
• The next stop is one ordinary system call (cellSysutilGetSystemParamInt), not a new subsystem.
• A direct trace by a different engine confirmed the exit (549,737, main thread), and real SPU 0 code drained the job queue. This is boot progress, not proven functions: the headline is unchanged.

2026-10-02 2:50 AM CDT — how far is 3D? We measured it. Also: our picture matches RPCS3 to the pixel

• The 3D number: from the end of the splash to the first 3D frame of the title screen, the real game runs about 23 billion main-CPU instructions and 19 billion co-processor instructions (measured in RPCS3's exact slow mode, 3 runs). Some of that is the game idling while it waits, but it is still billions.
• What it means: our Python interpreter would need roughly 2-5 days per run to get there. That is not a workable way to reach 3D. The road to the first 3D frame now goes through the native build: compile the game's code to real machine code, built from our decomp source, with stand-ins where a function isn't proven yet. That's thousands of times faster, and the same thing a playable release needs anyway.
• Our first picture vs RPCS3's: we rendered the Sony card both ways. 909,244 of 909,250 pixels are identical; the other 6 are off by one shade. Our renderer isn't just ours, it's right.

2026-10-01 11:00 PM CDT — the second CPU: 171 SPU instructions proven identical to RPCS3

• What: the SPU interpreter, a model of the PS3's co-processor that the WwsJob "foreman" (job ) runs on. We need it to get past the splash honestly.
• How we prove it: a reviewer built a tool that compiles RPCS3's own instruction code and runs it side by side with ours on hundreds of thousands of random inputs, then flags any difference down to a single bit.
• Where we are: 171 instructions (integer math, loads/stores/branches, and single-precision floats) give identical results to RPCS3 across every random seed tried, with 288 unit tests.
• Bugs that tool caught:
• a sign-extend that overflowed its register;
• a branch that read its target after overwriting it;
• all the float math initially used the wrong rounding mode. The real SPU rounds toward zero and treats microscopic numbers as zero. Our first version assumed normal PC rounding, and its own tests couldn't see the mistake, because the tests had the same belief baked in.
• 11:50 PM update: phase 1 complete. The memory-transfer engine, the atomic operations, the mailboxes and the events are now in. Two independent reviews found about a dozen real bugs; all are fixed, with tests that catch each one. The worst: when an SPU had to wait for mail, our model skipped the "pick up the mail" step instead of coming back to it. Another: messages aimed at other co-processors were being written into ordinary memory. Those are now refused until they're modelled properly.
• Next: run the real WwsJob job manager on this second CPU, replacing the shortcut behind tonight's first picture.

2026-10-01 10:05 PM CDT — 🎬 FIRST PICTURE: the game draws its own intro through our renderer (DIAGNOSTIC)

• What you're looking at: the opening of inFAMOUS, the "Sony Computer Entertainment presents" card and then the Sucker Punch logo, drawn by the game's own draw calls. The game's own graphics programs take our decoded movie frames and turn them into a picture through our renderer. This is the first real thing our build has ever put on screen.
• How it got here: today we built timed waits, the movie decoder stand-in and the textured renderer, and fixed the "mailman" (the decoder's reply note) that the reference map pointed us to. Then the renderer learned four things the game's real draws needed.
• Why it says DIAGNOSTIC: several pieces are stand-ins, not the real thing:
• one SPURS "is job done?" check is short-circuited (job is the WwsJob foreman; the real fix needs the SPU interpreter we're building);
• the movie is decoded by FFmpeg instead of RAD's own co-processor code;
• a math-estimate instruction uses RPCS3's approximation;
• the renderer skips back-face culling and flips Y on the host side. None of it earns credit. It proves the path works end to end.
• How close is it? Compared with the decoder's direct output, the average pixel differs by 0.67 levels and the biggest difference is 2 levels (out of 255). The game's own colour math is slightly different from the textbook formula, which is expected.
• Reviewed (10:40 PM): the claim STANDS, as diagnostic.
• The independent reviewer traced every pixel to the game's captured draw: its own shader bytes (sha ee955f84…), its own vertices and its texture memory. Nothing reads the decoder's image files.
• It decoded the game's shader with its own decoder and found the game's colour constants inside it (e.g. luma scale 1.16412).
• It re-rendered the frame byte-for-byte, and its own math from the raw data matched to within 1 level.
• It found no renderer change tuned to look right; each one traces back to RPCS3's source.
• Tamper proof (DeuceBucket asked "can we prove it's our renderer?"). We changed one input at a time, with the prediction written and fingerprinted BEFORE rendering. Every result matched:
• colour channels blanked: the logo went black-and-white (colour spread 184 down to 2 levels, as predicted);
• one of the game's shader colour numbers zeroed: red dropped by exactly the predicted 57.976 levels, with all 8 sample pixels exact;
• the game's rectangle shrunk: the picture filled exactly the predicted box;
• untouched re-render: byte-identical. The picture provably flows from the game's own draw data through our renderer.

2026-10-01 9:50 PM CDT — we know what "job " is, and the next big build is a second CPU

• What job is: Sony's WwsJob job manager, a "foreman" program that runs on the PS3's co-processors (the SPUs) and works through a to-do list of jobs. The main thread asks the foreman "is the list empty and is nobody working?" Only the foreman can answer, because nothing on the main CPU ever clears those flags. We confirmed this by watching the real game in the reference emulator and reading the foreman's flags live.
• The good news: during the splash the to-do list is empty in the real game, for about 18 seconds. A stand-in foreman that only ever says "empty", and stops dead the moment a real job shows up, is honest for that stretch.
• The big next build: after about 24 seconds, real jobs arrive and run on the SPUs. Running them honestly needs an SPU interpreter, a model of the co-processor's own instruction set, like the one we already have for the main CPU. We started building it today, from RPCS3's source, with the same "refuse rather than guess" rule.
• Also built: the game's job-registration bookkeeping now matches the real game's memory byte for byte, with 14 tests. It is being reviewed.

2026-10-01 9:15 PM CDT — the splash movie plays inside our boot (diagnostic), and the game reaches for its frames

• The mailman was the answer. With the movie-decoder stand-in switched on, the movie threads get their "frame done" notes and the chain runs, exactly as the real-game map showed.
• Then a new wall: the main thread keeps asking the co-processor manager (SPURS) "is job done?" Our model never registered that job, so the answer is always "no such job". The game ignores the answer and reads leftover junk that says "busy", forever.
• With a labelled shortcut on that one question, the splash movie plays inside our boot: 229 frames decoded, 474 draws. The game's own draw calls pick up our decoded frames as textures, so the game is trying to put "Sony Computer Entertainment presents" on screen.
• Next, in parallel: (A) render those draws to get the first picture of the game drawing real content, labelled diagnostic because of the shortcut; (B) record what SPURS job really is in the reference emulator, and build it properly so the shortcut can go.

2026-10-01 8:45 PM CDT — the headline's evidence is now shipped with it, not described in prose

• The number did not change. The published headline is still 2,974 / 21,054 = 14.13 %. What changed is that every claim under it now has a committed, re-runnable artifact instead of a paragraph.
• The compiler build identity is recorded by hash, so "it matched on my machine" is checkable rather than assertable.
• 601 rows and 859 rows now exist as lists, not adjectives. The 601 that lack a committed per-row check, and the 859 whose check cannot yet tell a real function from an empty stub, are both published as their own named classes with committed address lists.
• Old numbers are struck through, not deleted. Every superseded figure — including one that had been appended inside the same text string as the current one — now says so where it sits.

2026-10-01 8:40 PM CDT — game locks (sys_mutex) merged to main; semaphores built

• Merged: , the PS3 kernel's mutex calls (100-104), modelled from RPCS3's source. A mutex is a "one person in the bathroom at a time" lock. The game makes 11 of them, and the movie threads use them every frame. It was independently reviewed and is green in CI.
• Built (local, under review): semaphores (calls 90-94 and 114), the "ticket counter" the reference map showed is the only new kind of call between the splash and gameplay. contributor wrote it from RPCS3's source; a Claude review against that source is running. It goes to main only after the review passes.

2026-10-01 8:30 PM CDT — the full map: we recorded the real game from power-on to gameplay

• We drove the real game all the way: splash → title ("Press the Start Button") → one Start press → electric-explosion opening → the ground-zero tutorial ("use the right stick to look up at the chopper"). The controls were confirmed working for 82 seconds. Every thread, wait, file read and button press was recorded.
• The big lesson from the map: the game builds its whole "house" (all 42 threads and 264 locks, mailboxes and timers) during the boot and splash. After that it creates nothing new all the way into gameplay, apart from one helper thread and one lock. The only new kind of call after the splash is semaphores (a kind of ticket counter), which we haven't built yet.
• What that means: the road from the splash to gameplay is mostly mapped already. The known walls are the splash itself (being tested now), semaphores, and an audio timer. Not a maze anymore.
• Status: independently re-checked over all 22.5M log lines and confirmed. The object count was corrected from 275 to 264 (the extra 11 were connections, not objects). "Nothing new after the splash" is confirmed for kernel calls; co-processor and graphics-library internals were not logged in detail.

2026-10-01 7:45 PM CDT — we asked the real game: a reference map of the boot

• The idea (DeuceBucket's): stop guessing at walls. We recorded the real game booting in our own RPCS3 build: every thread, every wait, who wakes whom, and every file read. Now each stall in our boot can be looked up on the map.
• Bonus find: the game's audio driver is woken by a timer 187 times a second, and we don't model that timer yet.
• Next: a run with the movie decoder switched on is testing the fix. A second recording, with real rendering, is driving the real game to gameplay to complete the map.
• Status: independently re-checked against the raw logs. The map is confirmed, with two counts corrected. "Missing reply" is the leading explanation; one more check (where our player thread is stuck) decides between it and a clock problem.

2026-10-01 7:24 PM CDT — headline resolved: the 601 is exact, and the number is 2,974 / 14.13%

• Published number: 2,974 / 21,054 = 14.13%. Down from 3,563. We had a draft open publishing 3,575 — it counted the 601, and it was corrected before it merged. Publishing a number we can defend beats publishing a bigger one we cannot.
• The number includes 859 rows that a check cannot yet tell apart from an empty stub. They are counted, not proven, and published as their own class; the audit that would settle them has not been run. The other 2,115 rows are not in that class.
• The 601 are not accused of being wrong. Nothing has been shown false. They are simply not counted until a committed check shows what they were checked against. Every one comes back the moment its check lands.
• Twelve rows were genuinely re-proven, and they are three different defects, not one: 8 big-endian store helpers replaced by native stores, 2 big-endian load helpers replaced by native loads, and 2 rows that turned out not to be memory accessors at all — a plain unsigned minimum and an abs — each of which had lost a single sign-extending instruction. All twelve reproduced byte-for-byte.
• One earlier figure is withdrawn. A count of "18 no-helper rows" from the previous round does not reproduce; measuring properly gives 9. Two of those nine are the two rows just recovered, so the label was not even coherent.

2026-10-01 7:00 PM CDT — headline under review: 601 "proven" rows have no committed proof

• SUPERSEDED — the published number below is historical. The current headline is 2,974 / 21,054 = 14.13% (and it itself includes 859 rows pending a discrimination audit). The original bullet follows unchanged as the dated record.
• Ruling: those 601 come out of the headline until each has its check committed, which would make it about 2,962 / 14.07%. That figure is the reviewer's and not yet re-derived. Correction (8:50 PM): 859 more rows with "degenerate"/"weak" coverage are still counted in the headline, pending a check that has not been run yet. They have not been measured. If their checks cannot tell a real function from an empty stub, they come out too.
• Why it keeps dropping: none of these rows has been shown wrong. They are being held to "show the proof or it doesn't count". Rows come back the moment their proof is committed, and 1,633 recovered source files are already being re-checked.

2026-10-01 6:15 PM CDT — timed waits work: the movie loader runs and starts its streaming thread

• What was blocking: game threads say "wait for X, but give up after N milliseconds". We had no way to let that time run out, so they waited forever. Now it can, on a deterministic clock: two runs gave byte-identical results.
• What that unlocked: the movie loader thread runs, opens 6 audio ports and starts the Bink IO thread. That thread reads 2.9 MB of the splash movie, about 6× more than before. Timeouts fired 447 times, returning exactly what the PS3 kernel returns (ETIMEDOUT, from RPCS3's source).
• Still stuck: the threads end up waiting on each other in a loop. One is waiting on an event that probably comes from the movie decoder, which wasn't switched on in this run. Running both together is happening now.
• Caveat: local, opt-in, and earns no credit.

2026-10-01 5:25 PM CDT — the game asks for movie frames and our decoder delivers them

• The splash movie decodes inside the running game. On the PS3, the movie is decoded by a separate co-processor job. We replaced that job with a stand-in that decodes the same frame with FFmpeg and writes it where the game expects it. The game sent 3 real decode requests, got its answers and asked for the next frame. Frames 2 and 3 are bit-identical to FFmpeg's output.
• It is the right movie. Frame 100, decoded the same way in a test, is the "Sony Computer Entertainment presents" splash.
• Why it stops at frame 3: the game's movie threads use timed waits ("wait up to N microseconds"), which we are building now.
• A real bug caught: a held branch's new memory check didn't know about the game's heap. That would have failed a legitimate movie-loader instruction. Filed as before it could merge.
• Caveat: local and opt-in only (INFAMOUS_BINK_SPU_HLE=1). It earns no credit; FFmpeg stands in for RAD's own decoder code.

2026-10-01 3:30 PM CDT — the native boot reaches its render loop, and the splash movie starts loading

• The game now runs its frame loop: 647 frames in a row, every one completed, no crash. Diagnostic only, because one CPU instruction uses a stand-in whose exact console bits are unknown.
• Why the screen is black: the game is trying to play its opening splash movie, but we were only running one of its 35 threads. With the others running, the movie file starts streaming in. It then stops on a timed wait, which we are building now; the movie decoder is after that.
• Six fixes merged to main today: resume, graphics-library init, system callbacks, controller, keyboard/mouse, and an exact SPURS model. Every one was checked by an independent reviewer, and most were rejected at least once before they passed.
• Headline: proven & reproducible 6,557 / 21,054 = 31.14%. It went up 18 after a re-checked audit; a separate bug that would have let unproven rows count was found and fixed.

2026-10-01 10:05 AM CDT — the first native flip completes

• A flip finished for the first time. The game asked the GPU model to show a frame, the GPU model ran the real console command for it, and the request was marked done. Since 09-11 every flip had stayed stuck "pending".
• Three hidden problems had to be fixed first:
• a setup routine the real graphics library writes at start-up, decoded from firmware and checked twice;
• our model put the game's command buffer on top of that routine;
• our GPU decoder could not tell which GPU object each command was for. Reviewers rejected or corrected parts of the work along the way, and the record shows each one.
• Caveat: this is a local test build using an explicit, logged patch to an older checkpoint. It earns no credit yet.
• Next: the game asks the system "any events for me?" (cellSysutilCheckCallback). That is being modelled from RPCS3's source.

2026-10-01 9:20 AM CDT — the retail flip packet is merged; the native boot submits its first retail flip

• The fix for "frames never finish" is now on main. Our model of the PS3 graphics library now writes the real flip command, taken from the console firmware.
• In a local test build that also includes the checkpoint fix and a firmware-exact SPURS model, the native boot gets past its old wall, reaches 2 draws, and submits a flip using the real command.
• It stops at the next step: the flip calls a small setup routine that the real graphics-library init writes and our model did not. That routine has already been decoded from firmware; it is being verified, then modelled.

2026-10-01 8:30 AM CDT — the honest headline is 31.06%, and the native boot resumes again

• The headline number went down, on purpose. An audit re-ran every early credit against today's stricter proof test.
• 2,237 held up.
• 935 did not: no evidence trail, an empty function would also pass, or the result no longer reproduces.
• Native boot can resume from checkpoints again. That had been broken for two weeks by three new interpreter fields.
• Next wall decoded from retail. The SPURS function the boot stops on was decoded from the real firmware and independently verified (11,520 runs, 0 mismatches) after an error in the first decode was caught.

2026-10-01 5:15 AM CDT — native flips never completed: cause found, retail flip packet extracted, fix in progress

• Proven: our native model of the PS3 graphics library recorded each flip request but never wrote the flip command into the GPU command stream, so no frame could ever complete.
• Retail evidence: the real command (19 words) was taken from the console firmware by running its own code, and independently re-derived.
• Emulator oracle: the game, running with that real library in the emulator, completed 2,210 flips using exactly that command.
• Fix: modelling it faithfully is now in implementation.
• Also today:
• the BSS dispatch slot 0x915c28 resolved and reviewed;
• ledgers aligned with the banking lane.