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-13 6:24 AM CDT — Our real-console measurements now check the combined build

• The graphics behaviours we measured on a real PS3 are now in the combined build, each one checked as it went in.
• For the CPU's floating-point maths, more than 119,000 measurements taken on a real console match the combined build exactly.
• Testing whether the combined build gets further into the game.

2026-10-13 5:42 AM CDT — Pulling all our fixes into one build

• Combining all our improvements, plus the best of the wider PS3 recompilation community, into a single build. Each change goes in one at a time and must compile and pass its tests before the next.
• The first combined build is up and running.

2026-10-13 4:51 AM CDT — First runnable install of our native build, and a full clean-up pass

• Set up a first launchable install of our native build. It shows the opening logos and reaches the title in its logic, but the 3D scenes don't reach the window yet. That's being wired up now.
• Started a full integration pass so every fix found so far ends up in one build.
• Pulling in the latest improvements from the wider PS3 recompilation community.

2026-10-13 3:50 AM CDT — Confirmed the whole game is built with one open compiler; learned a lot from a real-console play session

• Checked every function in the game: all of it comes from the same open-source compiler we already use, so the whole game can in principle be rebuilt exactly.
• Logged a real PS3 play session from the title screen into the opening missions. It already points at how the game moves from cutscenes into gameplay.
• Catalogued the game's scripted moments (dialogue scenes, triggers, cutscenes, checkpoints) by their internal names.

2026-10-13 1:03 AM CDT — Eleven more startup functions locked in; fire and smoke look right; hardware database caught up

• Fire and smoke effects in the opening now blend the way they do on a real PS3, instead of breaking into jagged blobs.
• The hardware measurement database picked up the latest console runs that had been missing.

2026-10-13 12:16 AM CDT — Startup gets further: the game reaches its menu and story intro

• A rebuilt piece of the PS3's background job system now gets the game past its title screen, through the menu and into the opening story, in both test runs. The older path got stuck right after pressing START.
• The next stop is just after the story intro begins. We're digging into that now.

2026-10-12 11:05 PM CDT — Twelve more startup functions proven

• Twelve more of the game's startup functions are now proven correct against the original, with a new way of testing functions that need carefully sized inputs. Eight code updates landed today.

2026-10-12 6:56 PM CDT — Our renderer now draws the game's opening scene

• Our own renderer now draws Cole waking up after the blast, with the sun and shadows working, straight from our compiled build's graphics commands. Still being tuned (brightness/colour, 4K), but this is the real scene, drawn by us.

2026-10-12 1:57 PM CDT — Found a PS3 timing rule that likely explains a startup freeze

• The real console showed exactly how its processors signal each other. This likely explains a freeze in our compiled build's startup, and a fix is in progress.

2026-10-12 1:53 PM CDT — SPU math checked against the real PS3

• Pinned down exactly how the PS3's SPU computes two of its fast math estimates, matching every one of more than 160,000 hardware measurements. Our code already gets them right; we also found two small bugs in a popular emulator.
• Correction: an earlier note said our SPU math disagreed with the hardware here. That came from a measuring mistake on our side.

2026-10-12 12:51 PM CDT — More graphics answers from the real PS3

• The real console answered dozens more graphics questions (stencil and half-float blending), and our renderer is being lined up with them.
• Correction: the smoke-ring fix described this morning is written but not yet in the renderer build; it's being landed now.

2026-10-12 12:39 PM CDT — Real-PS3 module loading: cause found

• Found why our own code modules won't load on a real PS3 running HEN: it only accepts modules signed the official way, which we don't do. We're moving our in-game hooks to a different, supported route.

2026-10-12 12:28 PM CDT — Progress on loading our own code modules on a real PS3

• Narrowed down why our own small code module won't load on real hardware: the console accepts modules from our app just fine, so the fix is on our side, in how the module file is built.
• The renderer's saved frames now keep their true colors when shared.

2026-10-12 11:31 AM CDT — Renderer now lights the scene correctly, major stability fix, interpreter accuracy improved

• Fixed a memory leak in the renderer that caused textures to stop loading after the first few seconds of the city scene. The renderer now runs the full title city with zero missing textures and zero refused draws.
• Fixed the lighting pipeline so that visual enhancements actually apply to the game's lit image instead of an unlit intermediate. The scene now looks correct under both accurate and enhanced modes.
• Decoded the game's final compositing pass and documented exactly what it does.
• Generated 4K approval stills of the title city — accurate vs. enhanced — with luminance within 1% of reference on most of the frame.
• Merged interpreter accuracy improvements: zero wrong answers across nearly 290,000 hardware-measured test cases.

2026-10-12 8:20 AM CDT — The smoke-ring bug is found (fix being landed)

• Found the cause of the odd rings in the game's smoke and fire: a special blend mode that emulators, and our own renderer, treated as an ordinary add. Measured on two real PS3s exactly what the console does, and fixed our renderer to match.
• One last hardware check is queued before it's final.

2026-10-12 5:52 AM CDT — Big night on the real PS3: the smoke bug found, many more hardware answers, and the live render reaches the game world

• Measured exactly how the PS3 blends its smoke and fire particles. Other emulators and our renderer get this one blend mode wrong, which explains the odd rings in the smoke. The fix is underway.
• About 95 more graphics and SPU answers came back from the real console, plus timing data for the clock, screen refresh and GPU sync.
• Found two hardware limits worth knowing about, and recorded them as data instead of guessing.
• The probe can now update itself over the network and take its own screenshots safely.
• Our live renderer now runs the game into its first 3D scene at 4K, after fixing several memory and speed problems.

2026-10-12 12:33 AM CDT — More answers from the real PS3, interpreter fixes, and a rendering bug found

• Measured another graphics rule on the real console, which tells our renderer exactly when the PS3 throws away a pixel.
• Our CPU interpreter now matches every one of almost 290,000 real-console test results it can model; anything it can't model yet, it refuses instead of guessing.
• Traced the "chunky smoke" difference between our renders and a real PS3: most of it comes from our own texture upgrade, and a smaller part is still being investigated.
• Hardware measurement data now lives in its own private area.
• Built a pixel-history tool so any pixel on screen can be traced back to what drew it.

2026-10-11 5:38 PM CDT — Our renderer now draws the running game live

• The compiled version of the game now draws through our own renderer in real time on a PC graphics card, at 4K, with no PS3 involved.
• Drawing is extremely fast. The next speed work is in the game code itself.

2026-10-11 3:42 PM CDT — More real-console answers, a probe upgrade, and bug fixes from hardware data

• Our test console got a probe upgrade with clearer error screens and now runs new tests around the clock.
• Fresh hardware batches confirmed several more rules and exposed real bugs in our own CPU emulation, which are being fixed.
• A complete "edge case" map of the PS3's floating-point and vector maths is being measured overnight.
• Our renderer is getting a high-end lighting mode.

2026-10-11 12:19 PM CDT — Another clean batch of hardware answers, a second game, and a teaser in the works

• A fresh batch of thousands of real-console answers came back, and our maths rules predicted every one we had a rule for. The few we couldn't predict yet are listed honestly as unknowns.
• The console is working through a new set of graphics tests. Early results answer how the GPU stores half-precision numbers.
• We've started checking how much of our toolkit already works for a second PS3 title.
• Our renderer is getting a high-end lighting mode, and a short teaser is being rendered.

2026-10-11 7:28 AM CDT — Faster core merged, more real-hardware answers, better tools

• Our core's speed-up is now in the main build: most of the work runs as native code, with identical results.
• The test console answered roughly 100,000 more new questions this morning. A rule we worked out earlier correctly predicted a whole fresh batch of hardware results we hadn't used to build it.
• Our accuracy-focused emulator branch now matches the real console on more of our tests; one crash it introduced is being fixed.
• Behind the scenes: better tools for running tests on the console and an organised database of everything we've measured.

2026-10-11 5:17 AM CDT — A new hardware fact about how the PS3 does maths

• We measured how the PS3 rounds one family of combined multiply-and-add operations, on a real console. The answer was unambiguous, and it shows a small but real difference from how existing emulation and recompilation handle it. Fixes are in progress.

2026-10-11 3:15 AM CDT — Overnight: a new batch of real-PS3 answers, a faster core, better tooling

• The test console ran two new sets of hardware measurements tonight: about 2,300 for one of the game's slow maths routines and a 46,000-measurement batch on questions nobody had measured before. Every batch is now checked against everything already measured, so the console only spends time on new questions.
• Our own build's core got faster again: about 92% of the work now runs as native code, with results identical to the slow reference path. Independent review accepted it.
• One graphics test that kept failing on the console turned out to be a mistake in our test, not the hardware. It is fixed for the next probe update.
• New tooling in progress: the probe becomes a tool our agent can call directly, all real-PS3 measurements go into one organised private database, and a safer remote-control layer for the console is being built.

2026-10-11 12:40 AM CDT — Our own build now runs 2-4x faster

• Our decompiled build used to spend most of its time in a slow fallback interpreter. It now runs about 80% of the game's code as native compiled code, up from about 19%.
• Measured speedup: 2.2-2.4x on the standard test stretch of the boot, and about 4x on a later stretch it wasn't tuned on. The results are byte-for-byte identical to the slow, trusted path, checked independently.
• Still far from real-console speed. Next: turn the busiest routines into proven compiled code, and widen native coverage further.

2026-10-10 11:37 PM CDT — Evening: the test console runs graphics tests by itself, more functions staged, and some corrections

• The PS3 test app now runs graphics tests internally, with no launching. It updates itself remotely, and its first graphics result matched the earlier standalone test exactly.
• Two of the slowest, most-used routines in the game (a memory copy and a math routine) now pass proof testing. The memory copy passes within a limited size range; the math routine still has one known gap with special "not a number" inputs. Neither is counted yet.
• Speed is now the main focus: making our own build run everything natively and dropping the slow fallback interpreter from the normal path.
• Corrections: an audit of our own notes found mistakes in earlier updates.
• The renderer figure (3,285 of 3,521) counts shader programs we can handle, not drawn frames.
• The emulator speed comparison was against one of our own early builds, not official RPCS3. Measured: about 75 fps on the boot path and about 50 fps in early gameplay.
• The headline proof count on the status page is out of date and is being reconciled.
• The test console was offline for most of the day after a remote launch attempt locked it up. It is back now.

2026-10-10 4:07 PM CDT — Real-PS3 answers merged: renderer and CPU

• Merged: our renderer now handles 3,285 of the game's 3,521 shader programs, up from 2,056. The new ones are answered by measurements from a real PS3.
• Merged: about 114,000 real-PS3 CPU results now give the same answer in all four of our execution paths, with zero wrong answers. Cases the hardware hasn't shown us are refused, not guessed.
• New: our function-proving tool can now feed functions realistic linked data (lists, tables, nodes). Five functions that used to crash under test now pass with the correct code and fail with wrong or empty code. Not yet counted; that comes after review.
• In progress: the slow stretch after pressing Start. The helper processors were running one heavy job type the slowest possible way. We've identified it and are switching it to a faster path, and checking that the results stay identical before claiming any speedup.

2026-10-10 1:28 PM CDT — After pressing Start, our build isn't stuck, it's slow

• The slowdown is the console's helper processors (SPUs) running one heavy job very slowly in our build. Finding and speeding up that job is now the main task.
• Today's real-PS3 test data (about 114,000 unique CPU checks) now matches our code with zero wrong answers. Cases the hardware hasn't shown us are refused, not guessed.
• Unconfirmed: the memory comparison is a coarse measure. A second, independent check is in progress.

2026-10-10 12:25 PM CDT — Our CPU emulation now matches the real PS3, measured

• Our four ways of running the game's code now give the same answers as a real PS3 on every case we measured on the owner's console today. That covers rounding modes, NaN handling, vector "flush denormals to zero" behavior, and stores of tiny numbers.
• Anything the real hardware hasn't shown us is still refused rather than guessed.
• The console produced about 440,000 more answers today. They're being checked against our code now.
• A second change is waiting to merge: our renderer can now draw 3,285 of the game's 3,521 shader programs, up from 2,056, using answers measured on the real PS3.
• The test console is offline until tonight (it got stuck during a remote launch attempt; it needs a power cycle in person).

2026-10-10 9:07 AM CDT — More of the game proven, and the test tool updates itself

• Another batch of the game's code was confirmed to compile exactly like the original, checked independently before it counted.
• More functions now carry their real names.
• Our PS3 test tool can now update itself over the network, so new tests reach the console without anyone touching it.
• PS3 tests answered more of the questions our code checker refused to guess at, and those answers were re-checked before being used.

2026-10-10 6:21 AM CDT — Our renderer now draws most of a real game frame

• The renderer can now handle the large majority of the draws in a captured inFAMOUS frame, up from a little over half earlier tonight. Every previously working draw still renders exactly the same.
• PS3 tests answered more of the questions our renderer and code checker had been refusing to guess at, and those answers are now built in after independent re-checks.
• Real PS3 tests also unblocked parts of the game's own code that our checker could not verify before; the first of those now pass the full check except for the final compile step.

2026-10-10 4:34 AM CDT — Graphics answers from a second PS3

• PS3 tests on a second console tonight answered graphics questions our renderer had been refusing to guess at, and they matched the first tester's console exactly.
• A batch of brand-new graphics tests ran on real hardware for the first time, including one nobody had measured anywhere.
• The real console's frame timing was measured directly, and it differs from what emulators do. Our build will follow the hardware.
• Tests now run back to back on the console without anyone pressing buttons.

2026-10-10 2:48 AM CDT — More of the game now compiles just like the original

• A batch of small functions was rewritten so they compile the same way the original game did, and a second agent re-checked each one before it counted.
• PS3 tests showed how the real console's clock behaves, and it differs from what emulators assume. Our native build will follow the real console.
• Our PS3 test tool got a fresh new look.

2026-10-10 2:38 AM CDT — More functions proven, and our checker now agrees with real PS3 tests

• Five more functions passed our full proof check and were re-checked independently before they counted.
• PS3 tests turned up a few places where the tool we use to check our work disagreed with the real console. It now agrees with every one of them.
• A new tool lets us ask the console questions live, which makes testing much faster.

2026-10-10 1:53 AM CDT — PS3 testing now runs on its own

• PS3 tests now run back to back without anyone needing to sit at the console, and the results feed straight into the project.
• A couple of tests behaved differently on a real PS3 than in an emulator. Finding exactly that is what the tests are for, and we are following both up.

2026-10-09 10:00 PM CDT — Comparison confirmed against the official emulator release

• We re-ran every real-PS3 test against today's official release of the main PS3 emulator. It gets the same results our earlier comparison reported: roughly half of the answers right on these graphics tests, where our improved test emulator matches the real console on all of them.
• Earlier we had used an early build of our own as the "normal emulator" baseline. That turned out not to change the totals, but the official release is now the reference we use.
• We also gave every emulator build its own cache while testing, after finding that builds were accidentally sharing one.
• 25 more functions in inFAMOUS now have names, identified by matching them against other PS3 games' code. They include some of the most-used routines in the whole game. They go through review before they count.

2026-10-09 8:35 PM CDT — New tests are on their way to Saber, and our recording tool is getting the real-PS3 treatment

• A fresh, smaller set of graphics tests went out to Saber tonight for his real PS3. It includes a safe redesign of the test that crashed his console last time: every risky setting is now checked against an allowed list before anything reaches the graphics chip.
• We are also pulling in the newest fixes from the main emulator project, checking each one against the real-PS3 measurements first. Anything that disagrees with real hardware stays out.
• A correction in progress: the "normal emulator" comparison we quoted earlier was run on an early build of ours rather than the official release. We are re-running it against today's official build and will update the numbers.
• Our checker can now follow two more kinds of real-PS3 vector math, and we found what blocks most of the remaining small functions from being proven: they read pointers stored inside their inputs. Work on that is under way.

2026-10-09 6:37 PM CDT — Another function ready for review, and a clearer map of what blocks the rest

• One more piece of the game's code now passes our full proving check and has been independently re-checked. It goes to our banking reviewer next, who runs the check again before it counts.
• We tried 79 more small pieces of code that already had approved descriptions of their inputs. Most of them stop at the same known gap: the checker does not yet set up the memory those functions read through pointers. Knowing that tells us where the next big gain is.
• Our checker can now handle two special vector math instructions using numbers measured on a real PS3, instead of refusing them. Two independent reviewers found and fixed a hidden mistake in the first version before it was saved.
• The count of proven functions has not changed yet. Nothing is counted until the banking reviewer confirms it.

2026-10-09 2:49 PM CDT — Our improved test emulator plays inFAMOUS into the first tutorial

• With all of Saber's hardware fixes in, our private test emulator now runs inFAMOUS from power-on, through the title screen and the opening, into the first tutorial. A scripted virtual controller does the button presses.
• The tutorial reacts to the controller the way it should: the "look up" prompt moves on to "look left" after the stick input. The scenes match our earlier reference recording.
• Along the way we found why scripted button presses were being ignored on system pop-ups, and fixed it in our private emulator.
• This is our test emulator, which we use as a map and a checking tool. The goal is still the game running from our own decompiled code.

2026-10-09 11:37 AM CDT — Our test emulator now matches a real PS3 on every test Saber has run

• One more round of fixes closed the last two disagreements. Every answer in all three of Saber's real-PS3 test batches now matches the hardware exactly, more than 3,000 measurements in all.
• Nothing that matched before broke along the way. The new fixes were checked by an independent reviewer, who worked the rule out again straight from Saber's raw numbers, and they passed our own graphics card tests.
• What's next: measure whether the extra accuracy costs speed in real games, and send Saber a fresh set of small tests for the cases nobody has measured yet.

2026-10-09 10:03 AM CDT — Our test emulator now gets every answer right on the tests it had been missing

• After the latest round of fixes, our private test emulator matches a real PS3 on every single answer in the tests where it was still making mistakes this morning. Saber's first test batch is still fully correct too, so nothing that worked before broke.
• Two of Saber's newer tests still disagree with the real hardware. We checked the previous version of the emulator, and it gets those two wrong in exactly the same way, so they are old gaps rather than something the new fixes caused. They are next.
• Every fix was checked by a second, independent AI reviewer and re-run on our own graphics card before it counted.

2026-10-09 9:08 AM CDT — Our decompiled code ran side by side with the game for two hours without a single wrong answer

• The native test build ran the game with 23 of our proven functions checked side by side against the original code. Over about two hours that came to more than 21 million comparisons, and not one gave a different answer.
• 21 of the 50 functions we added last night were actually used during that run. The other 29 were never called, so they have no real-game evidence yet and stay in the safe check-only mode until they do.
• This batch is made of very simple functions, so it mostly proves the plumbing that swaps our code in and out works correctly. Bigger functions come next, through the same check.
• An independent reviewer re-ran the build's own tests and checked every function's inputs and outputs before this was accepted.

2026-10-09 7:07 AM CDT — Our emulator fixes hold up on tests they were never tuned on

• All of Saber's second batch is now analysed. Simple rules explain every one of the nearly 2,900 measurements, and the tests he ran more than once gave identical answers every time.
• The real check: our private test emulator was fixed using only Saber's first batch. On this new batch it gets about 92% of answers exactly right, against about 49% for the standard emulator. So the fixes describe how the hardware really works, not just the first set of answers.
• The remaining misses point at four specific graphics behaviours: small compressed cube-map levels, shadow-map filtering, a start-up register value, and filtered texture precision. They are next on the list.
• On the decompilation itself: 50 more of our proven functions are now wired into the native test build in a safe side-by-side check mode. Three more functions passed thousands of automatic tests and are being independently reviewed.

2026-10-09 6:12 AM CDT — Saber's second batch of real-PS3 tests is in

• Saber ran our second batch of small graphics tests on his real PS3: 15 result files, nearly 15,000 measurements, all intact. Two tests were run twice and gave identical answers both times, so the console's behaviour is consistent.
• One test crashed his console and is withdrawn. It asked the graphics chip for a texture setting the chip doesn't allow. The emulator we test with quietly accepts that setting, so the problem only showed up on real hardware. We've found the cause, and future tests will check for illegal settings before they reach the chip.
• Thank you to Saber for running these and for reporting the crash right away.
• Next: scoring our private test emulator against these new results. These are measurements it was never tuned on.

2026-10-09 4:35 AM CDT — Other PS3 games are starting to name parts of inFAMOUS

• We dug through debug and prototype builds of several other PS3 games and demos. Some still carried their full lists of function names, and a few even carried their developers' own maps of the program.
• All of those names now sit in our private PS3 code library: several hundred thousand functions from many games, each labelled with where it came from and what kind of code it is.
• Because many PS3 games share the same Sony and middleware code, we can recognise identical pieces of inFAMOUS this way. The first 25 inFAMOUS functions found like this passed an independent check. They include standard C library routines, Sony controller and file code, an MP3 decoder and video-playback code. They are being added to the project's name list now.
• Along the way we fixed our own unpacking tool, which had been silently dropping exactly the name data we were looking for. An independent review caught it.
• Every set of labels went through several rounds of independent review before it was accepted.

2026-10-09 1:08 AM CDT — Our test emulator now matches a real PS3 on every answer in Saber's first test batch

• Saber's first batch of real-PS3 graphics tests had 356 answers to check. Our private test emulator now gets all 356 exactly right. At the start of the night the standard emulator got 213.
• The last fix came from tracing every draw step by step. The graphics math was right all along, but some results were never copied back to where the game reads them.
• An independent review accepted the fix, and it passed our tests on two different kinds of graphics hardware.
• More tests from Saber are lined up next. A perfect score on one batch does not mean everything is perfect.
• We also pulled thousands more function names from other PS3 games and debug builds into our private PS3 code library, including a full linker map from one prototype.

2026-10-08 11:59 PM CDT — Another round of emulator fixes, and saving every function name we find

• A third round of fixes to our private test emulator found a cache that sometimes handed back old graphics memory. Fixing it made one more of Saber's real-PS3 tests match the console completely, without breaking anything that already matched.
• Two tests still show the old value. The next round adds a step-by-step trace to find out exactly why.
• We looked inside two more PS3 games for function names. Neither had a normal symbol table, but one kept thousands of names in its engine's own lookup list. Every name we find, from any game, now goes into our private PS3 code library, even when it doesn't apply to inFAMOUS.

2026-10-08 11:09 PM CDT — Our test emulator now behaves much more like a real PS3

• We re-ran Saber's real-PS3 graphics tests on our private, fixed emulator build. It now gets far more answers exactly right than the stock emulator, and four of the seven tests match the real console completely.
• The tests also showed where a fix was written but never actually used. That gap is next on the list, along with one small rounding rule for colours.
• An older batch of processor accuracy fixes had been sitting on a side branch. It is now in the build too, so nothing we've already learned gets lost.
• One more large game function (a standard checksum routine) has been rewritten in C and independently checked. It now goes to the banking review.

2026-10-08 10:04 PM CDT — The first pieces of our own decompiled code now run inside the game

• Our testing build ran the game with two of our decompiled functions doing the real work, in place of the machine-translated versions, and it played through to the menu normally. This is the start of the plan: as the decomp proves more of the game, our own code replaces more of the translated code, one batch at a time, until the game runs entirely from our source.
• Every swap is checked first. Before a function is switched on, it runs side by side with the original over thousands of real calls and has to agree on everything the rest of the game can see. An independent review then signs it off.
• It's already catching problems in the translated code: one of our functions follows the PS3's maths rules more faithfully than the machine-translated version did.
• The verified count stays at 4,074 of 21,054 functions.

2026-10-08 8:08 PM CDT — Saber's real-PS3 graphics tests are in, and they're already paying off

• Saber ran seven graphics tests on a real PS3, and every one came back complete. On every test the real console did something the emulator doesn't, in small but important ways: how it rounds colours, how its shader registers work, how it blends, and what a draw sees when it reads its own image.
• This is why we test on real hardware. Those answers replace guesses in our renderer and our builds, so they draw the game the way a PS3 does, not the way an emulator does. An independent review re-checked every result before we act on it.
• More tests are ready: three more are built and passed our checks, and a batch of seventeen small follow-up tests is being checked now. Thanks, Saber!
• The verified count stays at 4,074 of 21,054 functions.

2026-10-08 6:30 PM CDT — Our renderer's core is now part of the main project

• The renderer core landed: the native renderer work behind the lit crater frames (texture formats, lighting rules, the GPU drawing path and its safety checks) is merged into the main project. An independent review checked that every safety check it changed still has an equivalent or stronger one.
• Three more real-PS3 test programs built for Saber, covering shadow sampling, a special texture format and how frames queue up for the screen. They go out once they pass our emulator test-run and a safety review.
• The verified count stays at 4,074 of 21,054 functions.

2026-10-08 4:11 PM CDT — The crater in 4K, the start of our own graphics effects, and real-PS3 timing from Saber

• The crater in 4K: our renderer drew the fully lit crater at 3840x2160 with the 4x texture pack. To get there we fixed how it scales up: the extra resolution used to trip one of its safety checks.
• Our own effects system: the renderer can now run extra graphics effects built right into it (no outside tools), switched on and tuned from a settings file and easy to add to. First up: tone mapping, bloom, ambient shadowing, fog and depth of field. The goal is everything our earlier Blender showpiece had, and more.
• Honest result: the first effects looked worse — blurry and washed out. So for now anything that can blur is switched off: the default keeps only a colour/tone touch, and it measures at least as sharp as the plain image. Depth of field will come back only when it is done properly.
• 4x textures were softer at normal resolution than the game's own textures, because their smaller versions were remade badly. Until the proper fix lands, normal-resolution images use the original textures; the 4x pack still shines at 4K.
• Real-PS3 timing from Saber, our tester: measurements from a real console showed exactly how the display refreshes and when frames flip. They exposed a timing bug in our port, which is being fixed now. Thanks, Saber.
• Three more decomp source contributions merged. The verified count stays at 4,074 of 21,054 functions.

2026-10-08 11:20 AM CDT — The crater, fully lit, and the brown-panel bug is gone

• Full crater scene: the near ground, the middle distance and the far ruined buildings are all lit now, close to how the real game looks.
• The brown panel was not the scene: it came from a renderer bug that made repeat renders of the same frame come out slightly different. The fix we made this morning for that bug was missing from this test copy. With it in, two renders of the frame are now byte-for-byte identical, and the panel is gone.
• Still a best guess: the way we lay out the game's cube-shaped light maps is labelled as inferred until we can check it on a real PS3.

2026-10-08 9:01 AM CDT — The crater gets its ground and light back; renders are now repeatable

• The crater scene looks much more like the real game: the ground, the ambient light and the far rubble now draw in our renderer. Before, the scene was dark with a black slab under Cole. The fix is a labelled best guess about how the game's cube-shaped light maps are laid out, not yet proven on hardware.
• One new bug we can see: the same change paints a solid brown panel over the top-right quarter of the screen. The real game has no such panel. We're tracking it down draw by draw.
• Two more texture types are supported (one used for shadows), so 14 of the 18 draws we used to skip now render. The other 4 are missing data we never captured, and we leave them out rather than guess.
• Renders are now repeatable: drawing the same frame six times gives identical pictures every time within each test group.
• Speed work: the faster version of the game's helper-chip code gave identical results to the original on all 870 complete checks in 25 minutes of real play. Next we switch it on only where it was checked, and measure the frame rate.

2026-10-08 4:50 AM CDT — First video from our native build: inFAMOUS's opening

• A short video of the game's opening, made entirely by our own tools: our native build of the game ran the opening, and our renderer drew every frame, lit, with our 4x texture pack. It cuts from the helicopter over burning Empire City to Cole in the blast crater.
• Honest limits: it's about 2.6 seconds of game time (shown slowed down), drawn offline at several minutes per frame, not live. The images are marked unverified because the final colour step uses one labelled best guess. One frame is held where our capture skipped it.
• Next: making the game run at full speed so recordings can be real time.

2026-10-08 1:05 AM CDT — Lighting works: the opening of inFAMOUS, lit, from our native build

• Our renderer now lights the scene. The game's own lights reach the final picture: fires, glowing lava cracks, smoke, the burning bus, and Cole in the blast crater with the tutorial prompt on screen.
• The opening chopper shot renders too, with the helicopter's searchlight over burning Empire City, using our 4x texture pack.
• Honest limits: the final colour step uses one clearly labelled best guess about how the PS3 handles a corner case, so these images are marked unverified. A dark patch in front of Cole is a known gap (a handful of drawing commands are still refused). A short video is rendering now.

2026-10-07 10:40 PM CDT — Our native build reached gameplay: Cole in the crater

• Our native version of the game now gets past the main menu into the opening of the game itself. It reached the first tutorial prompt, "Use the right stick to look up at the chopper."
• Our renderer drew that scene: Cole standing in the blast crater, with the bus, the lava cracks and the collapsed bridge. 97% of the frame's drawing commands are drawn.
• Honest limits: this image is the game's scene before lighting. The game draws its world into a hidden buffer first, then lights it and puts it on screen. Our lighting step isn't working yet, so on the real screen you'd only see the tutorial text for now. That's the next thing we're fixing.

2026-10-07 9:02 PM CDT — First 3D scene from our own native build: Empire City

• Our natively running version of the game drew Empire City in 3D, and our own renderer put it on screen: the Archer Square plaza behind the title screen, with its buildings, trees and signs.
• Honest limits: about one in nine of that frame's drawing commands are drawn so far. Lighting, shadows and the sky aren't done yet, which is why the sky is black. Those are the next renderer pieces.
• The game itself runs at full speed up to this point, and our tools can now capture and draw these heavy 3D frames.

2026-10-07 6:35 PM CDT — Our native version reaches the main menu, and the title runs at full speed

• Our natively running version of the game now plays its main menu music. After the intro and the first-time install, it reaches the title screen. When it receives START and X presses, it opens the inFAMOUS main theme, the music that plays on the main menu.
• It runs at real-time speed up to the title screen, about 32 frames a second, after we moved the PS3's helper-processor task system from slow emulation onto native code.
• The title screen's 3D city is very heavy (around 10,000 drawing commands per frame). Our own frame-saving tool was what made it crawl there; with it switched off, the game keeps going.
• We can see the game's frames: the intro logos and title, drawn by our own renderer with an upscaled texture pack, and now about 35× faster to view than this morning. Live viewing at full speed is next.
• Proof work: the hottest maths function in the intro (sine/cosine) now proves out from the committed code alone, after an independent review caught a missing file. It's in final review.

2026-10-07 1:13 PM CDT — A faster route to playable, and honest speed numbers

• New plan for getting to gameplay: we're building on our own natively running version of the game, which already plays far past the intro. It runs at full speed. Our proven functions will be swapped into it one at a time, each checked live against the original as it runs. Our slower, exact boot stays as the referee that proves each piece.
• Plain truth on speed: we measured our new native play mode and it is not faster yet. Most of the time goes to the machinery around the code, not the code itself. That's why we changed course above.
• That native version is close to the next big step. It used to stop right after the intro. Now it gets further into the game's background work, and we've traced the remaining stop to one specific part of how the game hands out work to its helper processors.
• Our exact boot is past the wall it was stuck on and is working through the game's first-time install. Two fixes it needed (reading folders on the disc, and a self-check in native play) passed independent review and are on their way in.
• Better tools: we're building our own improved analysis tooling for PS3 code, so each function starts from a cleaner first draft. What we prove feeds back in to make the next draft better.
• Console tests: a tiny new screen test (under a minute) is ready, to find out why the last graphics probe froze on a real PS3. Small one-question tests from now on, instead of big ones.

2026-10-07 9:55 AM CDT — The boot breaks through the flip-358 wall; three more pieces merged

• Our own boot got past the wall it had been stuck on. At the end of the intro, the game saves its icons and stamps their dates. That used to stop us cold. Now it goes through cleanly, and the game moves on to its first-time install step (copying data from the disc to the hard drive). That's the next thing we're teaching our boot to do.
• Three pieces merged today: a fix to how game threads wait on each other, the new native play mode, and a fully checked file-path function (the first function from tonight's "hottest code" list to land).
• The hottest code in the intro is being rebuilt as proven C. The sine/cosine routine (about a fifth of the intro's CPU time) now passes every test, including the tricky ones like infinity. The memory-copy routine (about a quarter) passes thousands of checks too, and so does a near-identical variant. Each goes through an independent review before it counts.
• Our checker got stricter. It now notices effects it used to miss, so a broken copy of a function can't sneak through.
• A volunteer's console ran our graphics probe to the end and saved everything safely. It also showed us exactly where the probe gets stuck (its very first picture), and that console gave identical answers to its earlier runs across millions of measurements. Next come lots of small, one-question probes instead of one big one.
• Plain truth on speed: today's speed work isn't in a running boot yet. Native play found a problem in its own self-check and refused to run (as designed). That's fixed and in review.
• What these pictures are: the game's own rooftop scene (the geometry, the city, the harbour) taken from one captured frame and re-lit with offline ray tracing, using an upscaled texture pack. Think of it as "what a fully modded screenshot could look like". It's artwork, not our game running, and not counted as evidence. Our real renderer draws this frame at 4K; this extra lighting isn't real-time. (full push-in video (media omitted from public export))

2026-10-07 2:59 AM CDT — Checking our own work: one function sent back, one report corrected

• A math function we thought was finished (sine/cosine, about a fifth of the CPU time during the intro movie) went to a second, independent AI reviewer. The reviewer rejected it. It matches the game on 2,000 of 2,000 normal inputs, but we haven't proven what happens when the input is infinity. It doesn't count until that case is proven too.
• Our audit of the console test data was re-checked from scratch by a different engine. The headline count reproduced exactly: 19.7 million unique measurements. The reviewer corrected three overconfident sentences, including one where we had said another emulator got something wrong. It doesn't. The report now carries those corrections.

2026-10-07 2:30 AM CDT — inFAMOUS drawn at true 4K by our own renderer

• One frame of inFAMOUS, drawn by our own from-scratch renderer from the game's real draw calls, at the console's 1280x720 and again at true 3840x2160. It's not an upscale filter: every draw is drawn again at 4K, so fence wires, the lettering on Cole's bag, and the HUD text come out sharp.
• 3,405 of the frame's 3,521 draw calls are drawn. 509 of those use shader rules from the published spec that are still waiting on real-PS3 confirmation; the hardware probe for that is already built.
• Honest limit: this is the geometry, texture and HUD pass. The game's sky, fog, lighting and post-processing aren't drawn yet, which is why the sky is black. Here it is next to what players see:
• The input is draw calls captured from the game, not our own boot yet.
• The frame built one draw call at a time, in the game's own order:
• Full frames: 4K, original textures · 4K, our 4x texture pack (AI-upscaled colour maps) · native 1280x720 · original vs 4x pack crops · the frame built one draw call at a time (MP4) (media omitted from public export) · X-ray: wireframe / depth / per-draw colours

2026-10-07 1:24 AM CDT — The SPU maths now matches a real PS3, checked against a volunteer's console

• The PS3's SPU co-processors handle some edge cases in floating-point maths differently from the textbook rules. Our engines now do exactly what a real console does, measured on a volunteer's PS3 slim.
• A second engine re-checked every measured case independently: 0 mismatches in 133,120 double-precision results, plus every single-precision and conversion case.
• A boot with the new rules matches the previous boot exactly, so nothing else changed (the change, merged).

2026-10-07 12:23 AM CDT — Side by side: our boot vs the original movie, pixel for pixel

• On the left, the intro movie as our own boot produces it (native code, not an emulator). On the right, the original movie file, frame-synced.
• 283 of 283 captured frames are bit-identical in brightness: zero differing pixels on the full 1280x720 picture. A second check, done separately from the tool that made the video, measured the same 283/283.
• Colour, honestly: this capture was made before tonight's colour fix, so the video shows brightness only. A full-colour run with every fix is recording now. Full video (MP4) (media omitted from public export)

2026-10-06 11:39 PM CDT — Four-word C reset qualified; acceptedmain remains4,074

2026-10-06 10:33 PM CDT — Fix for the first wall after the intro movie merged

• Right after the intro movie, the game saves a small file and sets its timestamp. Our system layer didn't support that call yet, so the boot stopped there.
• That call is now supported and merged . Two independent reviews were done by a second engine, and every test that touches it passes.
• A full boot running the new code is on its way to that point now. We'll post what the game does next once it gets there.

2026-10-06 10:22 PM CDT — Sparse twelve-byte C reset qualified; acceptedmain stays4,074

2026-10-06 9:26 PM CDT — New three-word C reset qualified; acceptedcount still4,074

2026-10-06 8:46 PM CDT — Compiled code keeps running inside the system libraries' calls

• The fast compiled path now stays on when the game calls into the real system libraries and comes back. Before, it switched itself off at the first deep call.
• Over a 4-million-instruction stretch of the boot, about 86% now runs compiled. It matches the slow reference step for step (12 of 12 checkpoints), and runs about 3x faster.
• Checked independently by a second engine, then by the full test suite (the change, merged).
• Not claimed yet: equality beyond those 4 million instructions. That longer check is next.
• Also in the last hour: the boot now plays the whole intro movie and stops at the next missing system call right after it. The fix for that call has passed review and is queued for testing.

2026-10-06 8:21 PM CDT — Mixed nine-byte C reset qualified; acceptedmain remains4,074

2026-10-06 6:42 PM CDT — Three-word reset C qualified; acceptedcount remains4,074

2026-10-06 6:15 PM CDT — First full-colour frame from our own boot

• This is our own boot's frame at flip 321, in full colour, and it is byte-for-byte identical to the real movie's frame in all three colour planes, not just brightness.
• Today's earlier captures were black-and-white because our frame saver read one colour plane from the wrong place on alternate frames. Frames where it read the right place, like this one, are exact in full colour. The saver fix is in review; after it lands every captured frame will be in colour.

2026-10-06 6:10 PM CDT — Our boot plays the Sucker Punch logo

• Our own boot (not RPCS3) has played through to the Sucker Punch logo in the intro movie, flip 317 of the 373 the splash movie takes.
• These are brightness (black-and-white) captures. The colour bug we found today turned out to be in how we save frames, not in the game; that fix is in review, and full-colour captures follow once it lands.
• Every saved frame's brightness is byte-for-byte identical to the real movie: 255 of 255 this run, 655 of 655 across all runs (movie frame 313 of 353).
• Every flip is being recorded; next stop is the end of the splash movie and whatever the game shows after it.

2026-10-06 3:42 PM CDT — Compiled code now handles floating-point maths

• The compiled (native) version of the game's main-processor code can now run most everyday floating-point maths (add, multiply, divide, fused multiply-add, compares, rounding) itself, instead of handing every one back to the slow reference path.
• Each operation was checked against our exact reference on more than 6.8 million test cases with zero differences. Anything outside the proven cases still goes to the reference path.
• A second, independent AI engine reviewed it twice. Along the way the checks caught one older hidden bug (a wrong result flag on one multiply instruction), which is fixed too.

2026-10-06 12:25 PM CDT — Two new console probes run cleanly on real hardware

• A volunteer ran two of our new, small hardware probes on a real PS3. Both launched, finished and exited cleanly, which is the safety bar every new probe must pass.
• One of them came back with new answers that make our SPU emulation more exact. A second, independent AI engine re-checked every number from the raw results and agreed. The fixes are being built now.
• The other one ran safely but hit a bug on our side before it could ask its questions. That's fixed and going back through review.
• The volunteer gets a private write-up of their own results.

2026-10-06 12:13 PM CDT — Correction: the movie's brightness is exact, its colour is not yet

• Today's "frame-perfect" results compared only the brightness (black-and-white) part of each movie frame. That part is still exact on every saved frame.
• We have now checked the colour too. Colour matches the real movie on only 83 of 362 saved frames. On the others, one of the two colour channels is wrong: in the first part of the movie it is wrong on every other frame, and it stays wrong on many frames later on.
• We don't know the cause yet. It may be in the game's movie output or in how we save the frames. It's filed as a bug and being traced.
• The earlier entries today now say "brightness" where they said "identical".

2026-10-06 11:49 AM CDT — Our boot reaches the Sucker Punch part of the intro

• Every frame's brightness (black-and-white) picture is byte-for-byte identical to the real movie: 123 of 123 this run, 351 of 351 across all runs. (Corrected: colour does not match yet, see the correction above.) It is at movie frame 181 of 353.
• It's still much slower than real time; speeding that up is the main work now.

2026-10-06 10:14 AM CDT — Our boot plays on past the Sony card, every frame recorded

• Our boot moved past the Sony card into "Sony Computer Entertainment presents", on exactly the flip the real movie file says the card ends. This run recorded every flip of it. (Corrected: an earlier run today, base-02, had already passed the card, reaching movie frame 142 with sparse snapshots; this run is now the furthest at frame 145.)
• Every frame's brightness picture is byte-for-byte identical to the real movie: 87 of 87 this run, 260 of 260 across all runs. (Brightness only; colour is wrong on most frames, see the correction above.)
• This is our own boot running the game code, not RPCS3. It is still much slower than real time; the Sucker Punch logo comes next.

2026-10-06 10:12 AM CDT — Whole-game native code: 99% of a test stretch runs compiled

• We compiled native code for every function in the game's census at once, not just the ones a test run touched first.
• On a 5.6-million-instruction test stretch of the boot, 98.95% of instructions ran as compiled code, about 11x faster, and the result matched the slow reference at all 116 of 116 comparison points.
• Longer stretches still stop at a known spot where the compiled code and the system-library layer don't hand back to each other correctly. That's being fixed now.

2026-10-06 10:04 AM CDT — Our boot plays past the Sony card (brightness frame-perfect)

• Our quickest boot run has moved past the long Sony card and into the next part of the intro movie, exactly on the flip the real movie says it should.
• Every frame's brightness picture it has saved so far is byte-for-byte identical to the real movie: 79 of 79 for this run, 243 of 243 across all runs. (Brightness only; see the correction above.)
• This run uses the compiled SPU engine, and moves about 2–3x more screen flips per hour than the earlier runs (44–67 vs 22–29 measured). It is at flip 141 of the 373 the splash movie takes; still far slower than real time.

2026-10-06 9:40 AM CDT — Renderer round 6 merged: 2,896 of 3,521 draws in the captured frame are now handled

• The renderer now handles 2,896 of the frame's 3,521 draws (it was 2,883), including more texture formats and depth output from shaders.
• The remaining 625 are refused on purpose: those cases need a real-console measurement before we treat them as known. Our renderer won't guess.
• An independent review caught one case where we had relied on an outside reading instead of a measurement; we put that refusal back before merging.

2026-10-06 9:39 AM CDT — Mapped the SPU work that makes the movie slow

• We measured exactly what the PS3's SPU co-processors do while the intro movie plays, instruction by instruction, without changing the result (the measured run stays byte-identical to an unmeasured one).
• One program on one SPU does about 98% of all the SPU work. A few dozen small pieces of it cover 90% of the time.
• That gives the planned SPU-to-native compiler a short, clear first target, which is what will speed up the movie.
• A second, independent AI engine re-derived the numbers from the raw data and agreed.

2026-10-06 8:18 AM CDT — Proof: our own boot plays the intro movie frame-perfect in brightness

• We compared every frame our own native boot saved (not RPCS3) against the game's real intro movie, decoded separately. 147 of 147 frames are byte-for-byte identical to the real movie's frames, in brightness.
• The timing is exact too: one movie frame per screen flip, with no skips and no repeats.
• The long "Sony card" pause we chased earlier is in the movie file itself: it holds that card for 116 frames, and our boot holds it for exactly those 116 flips. There was never a freeze.
• A second, independent AI engine re-checked this with its own comparison code and got the same answer.
• What's still slow is speed: the boot runs the movie far slower than real time. Making it faster is the main focus now.

2026-10-06 7:22 AM CDT — Speed groundwork: the boot can now run proven C code directly

• New, switched off by default: our own boot can hand a function to its proven, compiled C version instead of interpreting it, and checks the answer against the reference every time until that function is trusted.
• A deliberately wrong C version is caught and switched off automatically, and with the feature off the boot is byte-for-byte unchanged.
• Starting the feature now costs almost nothing (startup went from about 71 seconds to under 2), so it's ready for the boot's hottest functions as each one is proven.
• Measured tonight too: our compiled SPU engine runs the intro movie about 3x faster than before, with identical results. Making the boot fast enough to play is now the main focus.
• Reviewed by a second, independent AI engine before merging (the change).

2026-10-06 5:44 AM CDT — Pair-store counted publication complete; acceptedmain still4,074

2026-10-06 5:02 AM CDT — New pair-store C verified; counted publication still pending

2026-10-06 4:32 AM CDT — Captured frame: 2,883 of 3,521 draws now render (up from 2,595)

• Our renderer replays one frame captured from the real game (from RPCS3, not from our own boot yet). It now draws 2,883 of the frame's 3,521 draw calls, up from 2,595. The other 638 still refuse, and we count them openly rather than guess.
• New this round: more surface layouts, another texture format, more shader instructions and more kinds of geometry.
• An independent reviewer on a different AI engine re-counted the numbers itself and re-ran the render with zero errors before we accepted it (the change).
• This is a replay of a captured frame. It earns no progress credit until our own boot produces the frame.
• Also tonight: the project's review process got stricter (the change), and the boots keep playing uncapped, recording every frame.

2026-10-06 3:36 AM CDT — The intro movie is NOT frozen: our native boot plays past the Sony card

• Proof, measured in game time: our own native boot (not RPCS3) plays the intro movie, holds the still Sony "presents" card from flip 23 to flip 138 (116 flips, about 3.9 seconds of game time, which is normal for a logo), then starts changing frames again at flip 139. It has shown 33 different frames so far and is still going.
• So the "intro movie freeze" we chased was the Sony logo sitting on screen while our boot runs in deep slow motion. Earlier runs were stopped before the next part could play. Nothing in the reports was wrong about what the frames showed; we were wrong about what they meant.
• The frame at flip 146 (below) is bright, almost white. It could be the Sucker Punch card fading in, or something else. The next saved frames will tell, and we're also watching for any loop back to the start.
• Speed is now the wall. In the decode-heavy part of the movie our boot manages only about 6 flips per real hour, roughly 0.2 seconds of game time per hour. The movie is decoded on the SPUs and our SPU engine is slow, so a new run now uses our compiled SPU engine, which is proven bit-identical to the reference one.
• Also merged tonight: the test fix for local checks, and the design for running proven C inside the boot (ADR 0011).

2026-10-06 3:35 AM CDT — New sentinel-store C bank; final publication review still underway

2026-10-06 2:22 AM CDT — New sequential64-byte C copy banked; accepted count stays4,074

2026-10-06 1:49 AM CDT — Proof: what our own native boot is showing right now

• These are the actual frames our native boot has decoded so far. This is our code running the game's real Bink video decoder, not RPCS3. Each is stamped with its flip count and instruction count.
• From flip 26 to flip 126 it shows the Sony "presents" card with the © 2009 line. In the real game that card is supposed to sit still for a few seconds, and 100 flips is about 3 seconds of game time. So this looks like the card on screen in slow motion, not a crash. The longer run now under way will show whether the Sucker Punch card follows.
• Luma (brightness) only: the colour plane is captured at a timing-dependent moment and isn't reliable yet.

2026-10-06 1:32 AM CDT — Correction: the "intro movie freeze" is not a proven stall when measured in game time

• Our boot runs the game in deep slow motion, so we've been judging it by the wrong clock (instructions) instead of the game's own clock, frame flips.
• In the real game (RPCS3 reference) the whole intro movie, Sony card plus Sucker Punch card, lasts 373 flips (12.5 seconds). In our boot the picture holds still from flip 23 to flip 135: 112 flips, well under the length of the movie. The Sony card is meant to sit still for a few seconds.
• So the earlier "freeze at about 630M instructions" claims are not demonstrated stalls. They may just be the logo on screen in slow motion. Our runs were capped before they could reach flip 373 to check. A longer run, with logging on every movie-file read, is now under way to settle it.
• New rule for all boot reports: judge progress in flips and game seconds against the real game, and call something a stall only if it clearly outlasts the reference.

2026-10-06 1:21 AM CDT — SPU fix merged; the movie stall starts earlier than we thought

• The SPU maths fix and several other hardware-accuracy fixes are now in main, all measured on real consoles. Every part of our engine agrees with them.
• Functions checked under the old behaviour are being re-checked against the corrected checker. Results will be published either way.
• The intro movie stall looked earlier in the boot than we first thought. (Update: it turned out to be the Sony card on screen in slow motion; see above.)

2026-10-06 1:08 AM CDT — Renderer: 2,595 of the frame's 3,521 draws now render, including the HUD (review ACCEPT)

• The full captured frame (3,521 draws) now renders 2,595 draws on our own Vulkan renderer: up from 425 a few hours ago, with 0 validation errors on the 3090.
• New on screen: the HUD. The health/energy ring, the electric power meter and the minimap render on their own layer, through the game's real shaders. They aren't composited onto the scene yet.
• Also new: 2,001 shadow-map draws now render (depth only), but nothing uses them yet, so the main scene image looks the same as before.
• What made it work: depth-only passes, surfaces of any size, alpha testing, and clears that cover only part of a buffer. Areas we don't know the contents of stay marked unknown, never assumed empty.
• An independent review re-counted the frame (2,595 / 926 / 0), checked that no draw reads an unknown area, and rendered it.
• Still missing: 926 draws, mostly shader features. They include the sky, lighting and post-processing. Still a captured replay from RPCS3, not our boot running the game, so it earns no credit. Clear-scissor behaviour and anisotropy are labelled unknown or approximated until the hardware probe measures them.

2026-10-06 12:36 AM CDT — Offset300 source PR opened; CI and independent lead review pending

2026-10-06 12:24 AM CDT — Current-root copy branch verified at4,075; acceptedmain still4,074

2026-10-06 12:18 AM CDT — Main4,074 both post-merge units green; current-root copy bank reverified

• Acceptedcount4,074 unchanged; final local4,075 publication head still pending. Rebank adds zero global functions, fifteen mixed4,087 unchanged. Different SPUhardware CI is busy: no copy push/PR claimed.
• Earlier running status and all lead/source/media history below remain intact; goal21,054 unfinished.

2026-10-05 11:56 PM CDT — Accepted source count4,074; another offset300 C copy bank still needs the new-root port

• No competing copy push while CI runs; local source work continues. Every earlier source correction and lead renderer/RC4/hardware/media entry below remains intact, without borrowed pixel/runtime credit.

2026-10-05 11:50 PM CDT — Source count 4,074 on main; probe RC4 blocked on a real bug found in review

• Probe RC4 is held back on purpose. Review caught a bug in its emergency-exit path that could have hung a real console. It's fixed and being re-reviewed; RC4 goes out only after that passes.

2026-10-05 11:31 PM CDT — Renderer: textures deduplicated (the change merged); RC4 probe in final checks

• The renderer now loads each distinct texture once instead of once per use. The captured frame needs 289 unique textures (147 MB), not 1,796 uses (1.16 GB). Its memory limit is unchanged, and the frame now renders on the committed renderer instead of a scratch build.
• Proof the output didn't change: all 1,705 per-draw images (colour, depth and stencil) are byte-identical to the earlier render. An independent review re-compared every one.
• The same PR corrects the status page to the full frame: 425 of 3,521 draws.

2026-10-05 11:20 PM CDT — Lead now accepts vector-zero PR's exact head; it is not merged yet

• PR remains OPEN/UNMERGED. Acceptedmain4,073 unchanged, zero rebank adds no global function. Next copy push still waits for renderer CI; no producer labels/status/admin/merge actions.
• All prior lead hardware/renderer/media history remains intact; no borrowed source/frame credit.

2026-10-05 11:15 PM CDT — New copy source bank; source PR has green units but still awaits the lead

• Local branch4,074=acceptedmain4,073+onlynewcopy. Parent measured4,086 addresses across fourteen mixed committed sets, not one head/globalratio. Prior duplicate-getter correction remains unchanged.
• Parent actually opened vector-zeroPR: both exact unit jobs green, but protectedlead-review awaits leadacceptlabel. Bot approval is not lead ACCEPT. No merge/override; rebanked zero adds no global function.
• Next copy push was refused while renderer CI runs; local genuine C work continues. All lead hardware, renderer/photos/runtime/probe history below is untouched and earns no borrowed source-count credit.

2026-10-05 11:03 PM CDT — SPU float maths fixed to match the real console (review ACCEPT)

• Our SPU engine's floating-point maths now matches the real console. The SPU is the Cell co-processor that decodes the game's movies.
• Checked against volunteer console data and confirmed by an independent review. Both of our SPU engines agree exactly.

2026-10-05 10:50 PM CDT — Correction: the frame has 3,521 draws, not 536 (419/536 was the first 536 only)

• We overstated the denominator. "419 of 536 draws" counted only the first 536 draws of the captured frame. The full frame has 3,521 draws, and 425 of them (12.1%) are supported today. The 419/536 figure itself reproduces exactly, but it describes a prefix, not the frame.
• Most of the unsupported draws have no colour target: depth-only and shadow passes our renderer does not handle yet. That is plain renderer work with no hardware question attached, and it is the next renderer unit.
• First menu frames captured (RPCS3, headless): the title screen (10,219 draws, 1,421 supported, 13.9%) and the pause menu (13,494 draws, 1,161 supported, 8.6%). They need almost nothing the gameplay frame doesn't. The one menu-only fix is a vertex-constant rule blocking 231 title draws.
• With no save, START on the title goes straight to the opening cutscene, so a Continue/New Game menu was not reached: UNKNOWN until a save exists.
• These counts come from one worker's census, re-derived three times by the tool itself. An independent review is pending. The earlier pictures are unchanged; only the fraction they represent was wrong.

2026-10-05 10:28 PM CDT — New vector-copy C bank; changed main and busy CI correctly prevent a source push

• Main changed9bfb→48ec before push; fresh-root copy and vector-zero banks now each count local4,074 with different added rows. Accepted count remains4,073; zero rebank adds no global function.
• Parent measured4,085 addresses across thirteen mixed committed sets: onlynewcopy beyond4,084, not one head/globalratio. Earlier getter-duplicate correction and all old evidence remain intact.
• Root/CI guards refused before any source push or PR; CI still running. Fresh unchanged-main and empty-CI checks required, while independent C work continues. No approval/result invented.
• All lead renderer/photos/runtime/probe history below is untouched; no pixel/hardware credit borrowed.

2026-10-05 9:56 PM CDT — Renderer follow-up merged: 419/536 draws on main

• The texture mip-tail recovery and the anisotropy, vertex-op and EX2 work are now on main, with both CI runners green and the independent review ACCEPT.
• Filed: the committed renderer must deduplicate textures before it can render the full 419-draw frame without a scratch build.
• Filed: one old test fails only on this workstation, which blocks local pre-push checks. It does not affect GitHub CI.

2026-10-05 9:46 PM CDT — Another real C copy repair banked locally; source PR waits for a free CI slot

• Local5dbf branch4,074=acceptedcurrentmain4,073+onlycopy. Current-root vector-zero was freshly checked too but adds zero global functions. Same4,074 numerators are different source sets, not one4,075 head.
• Parent measured4,084 addresses across twelve mixed committed sets: onlynewcopy beyond4,083, not an acceptedhead/globalratio. Getter-duplicate correction and all older evidence below retained.
• Serial source release is now explicit, but an actual renderer CI run is in progress: no competing source push/PR yet; fresh all-CI-empty check required. Independent genuine C work continues meanwhile.
• All lead renderer/photos/probe/runtime history is untouched; source banks borrow no pixel/gameplay credit.

2026-10-05 9:10 PM CDT — One genuinely new source function; duplicate-getter proposal corrected

• Correction: getter00546688 already existed in R64537ad. Full CSV membership caught the missed novelty before credit; getter rebank and earlierzero quality refresh each add zero global functions.
• Parent measured4,083 addresses across eleven mixed committed sets: only0038b838 new beyond4,082, not one head or global ratio. Forgotten own mirror-page hashes were corrected under unchanged strict checks; baseline pins valid, failures retained. No source push/merge release inferred.

2026-10-05 8:56 PM CDT — Renderer v5 merged; 419 of the frame's 536 draws now renderable (review ACCEPT)

• The renderer work is merged into main: shader ops, real RSX render-target state and the full-frame census, with CI green on both runners.
• Next PR, reviewed and waiting to push: missing small texture mips come from the game's own packages, but only when every captured level is byte-identical. Anisotropic filtering, more vertex-shader ops and EX2 take the census from 141 to 419 of 536 draws.
• An independent DeepSeek review re-counted the census (419 / 117 / 0), checked that no safety refusal was removed, and passed all six checks.
• Anisotropy is labelled approximated until the hardware probe measures it. The 117 draws still refused hit register aliasing or unwritten lanes, and those stay refused rather than guessed.
• Still a captured-frame replay, not the game running natively. It earns no decomp or gameplay credit. Before/after below: chain-link fences, asphalt, a barrel and a character head fill in; the sky, city and the rest of the body are still missing.

2026-10-05 8:11 PM CDT — Another function's real C repaired and banked locally

• Local branch4,074 is acceptedbaseline4,073 +only this function, not a new acceptedmain count. Earlier indexed-setter/wide-return repairs were freshly rechecked; rebanking adds no duplicate credit.
• Parent measured4,082 unique addresses across nine mixed-base committed source sets, not one head or ratio. Fixed-flags byte mismatch and finite-test/type limits retained; no new source push/merge permission inferred.

2026-10-05 8:08 PM CDT — First multi-draw inFAMOUS frame through our own renderer (141 of 536 draws, captured replay)

• What you're looking at: a real frame of inFAMOUS, drawn by our own renderer, from the game's own recorded GPU calls.
• 141 of the frame's 536 draws, textured and depth-tested, all in their real positions: rusty scaffolding, a wooden walkway, a cardboard box, dry grass, an awning with string lights, a barrel.
• The black areas are the 395 draws we can't render yet. Not one of them is faked.
• How we got here today: in one day, this frame went from 0 renderable draws to 141:
• six missing GPU shader instructions;
• the game's real render-target setup;
• the missing small texture mip levels, recovered byte-for-byte from the game's own texture files, never generated.
• Watch it build up, 20 draws at a time:
• Honest labels:
• This is a replay of a captured frame (an RPCS3 capture of the real game), not our boot running the game. It's partial. Exact match to real PS3 pixels is still unknown.
• Zero Vulkan validation errors.
• The texture recovery was independently re-checked by a second engine, which reproduced all 827 recovered mip sets byte-for-byte.
• Next: texture filtering (271 draws) and the remaining pixel-shader gaps (115). Each one fills in more of this picture.

2026-10-05 7:32 PM CDT — Renderer: render targets done; 140 of a frame's 536 draws now wait only on real texture mips

• Render-target support is in, and checked by a second engine. The renderer now reproduces the game's real setup, with every value decoded from the game's own GPU registers and cited:
• drawing to two or three targets at once;
• stencil, blending, culling and depth;
• the screen clear.
• Combined with the shader work, the frame census now reads:
• 1 draw fully ready;
• 140 draws blocked only by missing small texture mip levels;
• 395 still blocked, mostly by texture filtering (271) and some pixel shaders (115).
• Next: take those missing mip levels from the game's own texture files, byte-matched, never generated. Then replay the frame. That would be our first multi-draw inFAMOUS frame from our own renderer.
• On the movie freeze: a separate PS3 recompilation project working on this same game got past the intro movie. Their public notes credit fixes to wait objects, SPU event queues and SPU thread slots, not audio. We're testing those ideas against our runtime now. We read their notes only, not their code.

2026-10-05 7:23 PM CDT — Renderer: shader blockers cleared from 412 of a frame's 536 draws; render targets next

• Six missing GPU shader instructions are now implemented:
• pixel shaders: "set if greater", log₂, divide-by-square-root;
• vertex shaders: sign, reciprocal, log₂.
• Draws no longer blocked by shaders: 35 → 412 of 536. 7 more vertex programs and 2 more pixel programs now translate.
• Checked by a second engine: it compared every instruction line by line against RPCS3's source and recounted the census itself.
• Still unknown: whether the real PS3 GPU matches RPCS3 on edge cases (log of zero, precision). Our research agent Carl is digging into that. Draws that depend on an unclear register-overlap rule are still refused, on purpose.
• Render targets: that work has cut render-state refusals from 531 to 0 (0x13 turned out to be a target selector, not a colour format). The GPU side is being finished. After that, textures (missing small mip levels, filtering settings) are the last blockers before a full captured frame.
• Fully renderable draws: still 0, until render targets and textures land.

2026-10-05 6:54 PM CDT — Renderer reality check: 0 of a frame's 536 draws render yet, and now we know exactly why

• One real inFAMOUS frame is 536 draw calls. We checked every one against our renderer: none can render today. We've drawn single captured models, not a full frame.
• What's in the way, by how many draws it blocks:
• render-target setup our renderer doesn't support yet (531);
• missing smallest mip levels of textures (353);
• unimplemented pixel-shader instructions (324; one of them, SGT, alone blocks 265);
• texture filtering settings we refuse to guess at (317);
• unimplemented vertex-shader instructions (200).
• Good news in it: our captured data matches the game byte for byte for the draws we can check. Every blocker is well-defined GPU behaviour, with no guesswork needed.
• Now: the missing shader instructions are being implemented, each with a cited source. We'll re-run the same check after each fix, so you can watch "renderable: 0 of 536" climb.

2026-10-05 6:53 PM CDT — Correction: today's "111 movie frames" is not new progress, and we have no pictures of it

• What we wrote earlier today: "the intro movie isn't stuck any more: 111 movie frames drawn in one boot". That was overstated.
• What was already true yesterday: the boot played the intro movie (instructions 450M–586M, see the Boot Progress Gallery), then froze mid-movie from about 630M.
• What was actually measured today: 111 full-screen draw calls, about one every 3.27M instructions, through the game's own GPU draw path. We compared that only against a later run that had stalled on movie frame 3. Yesterday's frames were read straight from the video decoder's memory instead.
• We have no images of today's 111 draws. That run had frame capture off. So whether they show the right picture is UNKNOWN.
• Next: a run with frame capture on, to see what those draws actually show and whether the movie gets past yesterday's freeze.

2026-10-05 6:22 PM CDT — Real-console measurements

• Most likely our bug, not the console: the clock library has to be loaded and linked by our own stub generator. We're confirming exactly why before we say so for sure.

2026-10-05 5:32 PM CDT — Live real-PS3-clock boots work again on main

• the change merged (632b56b). It closes both bugs that had stopped today's real-PS3 timing model from ever running in a live boot:
• an import that only worked from the repository root;
• the boot driver's outdated list of normal waits .
• Today's merges:
• : wait-object layout;
• : exact float stores and loads;
• : exact carry flag;
• : live boot fixes.
• Now running: the full 600-million-instruction boot with all of them together. We'll compare it with this morning's run, which drew 111 intro-movie frames under the old behaviour.

2026-10-05 5:21 PM CDT — The 6.1M wall was our boot driver, not the PS3 timing model; fix in CI

• What actually happened: one game thread signalled a wait object and woke three higher-priority threads. Per the real-PS3 rule, those three should run first. Our scheduler set that up correctly.
• The bug: the boot driver sitting on top had its own outdated list of "normal" waits. It didn't know about this one, so it treated it as a crash and stopped the run.
• The fix: one shared rule that the scheduler, the driver and the native-core path all use. Nothing our code can't model is let through, and the old clock mode behaves exactly as before.
• Proof: with the fix, the three threads run, finish their waits, and the original thread then carries on, all in the measured order. The test boot ran cleanly to its limit.
• Review: checked by a second engine.
• the change carries this and the earlier import fix, and is in CI now.
• The full 600M boot is running again with every fix from today. It's the first long run with correct carry flags and real-PS3 thread timing together.

2026-10-05 4:53 PM CDT — The corrected boot hit a new wall at 6.1M: this afternoon's PS3 timing model, live for the first time

• The corrected long boot stopped early, at 6.1 million instructions, on a new wall.
• It comes from this afternoon's real-PS3 timing model . That model includes a rule we measured on the volunteer's console: when a thread wakes a higher-priority thread, the woken thread runs first, before the waker's call returns.
• What goes wrong: in this boot, the woken thread is never recorded as "done", so the waker waits forever.
• Why we're only seeing it now: that code had never run in a real boot. The import crash we fixed an hour ago had been hiding it. It only ran on small hand-written test cases.
• This is the project's most common failure: "implemented but not wired". Fixed in code, never reached by the real path.
• Next: filed as . An agent is tracing exactly which threads and which call are involved, and testing a fix that keeps the safety refusal for anything we can't model.
• Earlier result unchanged: this morning's 600M run used the code from before the timing model, and it drew 111 intro-movie frames.

2026-10-05 4:51 PM CDT — Carry-flag fix is on main; a second hidden break found and fixed; corrected long boot running

• the change merged (b70663d). Every run of our game runtime now sets the PowerPC carry flag exactly as the spec says.
• Old saved checkpoints made under the wrong behaviour now refuse to resume, instead of continuing silently.
• The native-vs-Python check on the real game binary passes again (6/6).
• New tests that don't need the game binary mean our public CI now catches this class of bug.
• A second hidden break: when we started the corrected long boot, it crashed before running a single instruction. This afternoon's real-PS3 timing change imports one module in a way that only works from the repository root, and our live boot doesn't run from there. CI never runs the live boot, so it missed this too.
• Filed as, fixed with a one-function change.
• A new test reproduces the exact live-boot setup. We confirmed it fails on the old code and passes on the new.
• A short live boot now runs cleanly.
• Now running: the same 600-million-instruction boot as earlier today (which drew 111 intro-movie frames), this time with the correct carry flag. Comparing the two will show whether the wrong flag was changing what the game does.

2026-10-05 4:11 PM CDT — Float-store fix is on main, with every safety refusal kept

• the change merged (06b3e5e). Our CPU code now converts floats to and from single precision exactly as the PowerPC spec says, in all four places it lives: the reference interpreter, the native core, the C interpreter and the code generator.
• It also keeps a NaN's sign through rounding, divides 64-bit integers exactly, and saturates infinity-to-integer conversions.
• Where the spec leaves a result undefined, we refuse rather than guess. A case with no hardware measurement behind it stays "unknown".
• Checked hard:
• 520,000+ conversions against an independent spec model: 0 mismatches;
• 339,000 C-vs-Python cases: all agree;
• every proven function that uses these instructions (577 of them): not one result changed.
• Next: the carry-flag fix is rebased on top and passes everything locally, including the native-vs-Python check on the real game binary. It goes to CI as soon as main's run finishes.

2026-10-05 3:29 PM CDT — The intro movie isn't stuck any more: 111 movie frames drawn in one boot

• The long boot finished. It ran all the way to its 600-million-instruction budget, with no real wall in the way.
• Before and after: at 235M instructions the intro movie sat on frame 3. This run drew 111 full-screen movie frames (plus 2 other draws) and flipped the screen 116 times, about one new movie frame every 3.27 million instructions.
• Why: this is the first long run with the SPU "memory line changed" wake-up fix. The movie's decoder workers now get woken, so the movie runs. It's slow (one frame per ~3.3M instructions) but not stuck.
• Honest caveat: this run used the old carry-flag behaviour we found wrong this afternoon . The next long run will use the corrected one. Neither run has a depth-tested 3D draw yet; these are the movie's flat frames.
• Also: the float-store fix is back as a minimal PR with every safety refusal intact. It's in CI now. The old is closed.

2026-10-05 3:18 PM CDT — The carry-flag bug: our Python runtime was the wrong one

• The first disagreement: the instruction subfic r11,r0,16 with r0 = 8. That's "16 minus 8", which doesn't borrow, so per the PowerPC spec the carry flag must become 1. Our native CPU core sets 1; our Python runtime left it at 0.
• Why: this morning's carry audit put the correct carry behaviour behind a switch, so old saved checkpoints would keep matching. That switch is off on real game boots. The audit's own tests turned it on, which hid the problem.
• What that means, plainly: every live boot so far, including the long one running now, has been skipping the carry flag for about ten instructions, and treating "zero this cache line" as doing nothing. Anything those runs show that depends on carry is now suspect. It could be behind some of the walls we've hit.
• Decision: the live runtime gets the spec-exact behaviour by default. Old checkpoints will refuse to resume rather than silently continue under the wrong model. The fix is being written now, with tests that don't need the game binary, so our public CI catches this class. A different engine reviews it before it lands.

2026-10-05 3:05 PM CDT — Found a regression our CI can't see: native core and Python disagree on a carry flag

• What we found: while checking the replacement float fix, we ran the full "native core vs Python" lockstep test on the real game binary. It fails on main, not just on the new branch.
• Our native CPU core says a carry flag is 1 at instruction 10,000 of boot; the Python reference says 0.
• Why CI never saw it: that test needs the game's own binary, which never goes into our public CI. So it quietly skips there.
• When it started: we bisected. It passed before the change (this morning's carry-flag/cache-zero audit) and fails from on.
• Next: filed as . An independent agent is finding the exact instruction, which side is right per the PowerPC spec, and the fix. We'll also add a test that doesn't need the game binary, so CI catches this class from now on.
• Float fix: rebuilt as a minimal PR with only the proven conversions and every safety refusal intact. It is in review now, scoped to look for removed refusals.

2026-10-05 2:12 PM CDT — CI caught our float fix quietly removing safety refusals; sent back

• the change (exact single-precision float stores and loads) failed CI on a CPU-context test. The cause matters more than the test.
• To make more PS3 conformance tests pass, the change had quietly removed five deliberate "refuse rather than guess" checks in our game runtime:
• an overflow flag our code doesn't fully model yet (tracked in );
• two floating-point status reads we can't vouch for;
• an undefined register half;
• a guessed system-call return value.
• Our rule is that a refusal of something we haven't measured is the product. Replacing it with a plausible value is exactly what we promised not to do.
• Why reviews missed it: two review rounds (and a third check) looked at whether the math was right and whether any proven function changed. They found none, and that part holds. Nobody had been asked to list the removed refusals.
• Now: the reviewer prompt always includes that list.
• Repair: keep the proven float fixes, put every refusal back, and review again.
• Also merged: the change (lightweight condition-variable layout), with main CI green.

2026-10-05 1:36 PM CDT — Movie-stall work: wait-object fix on main; CI caught a guard regression first

• the change merged (1ce0aad).
• The game's lightweight condition variables now use the real 8-byte layout: lock pointer, then wait-queue id. This matches four independent PS3 projects and how the game itself lays them out in memory.
• The audit also shows the graphics "finish" call costs our runtime nothing, so it is not what slows the intro movie.
• A trace of who writes the SPU wake-up memory line (off by default) shows work is being posted to the SPUs. The movie stall is looking more like "slow" than "stuck".
• CI did its job twice.
• The first run found four defects that our local tests and the first review missed. The most serious was a new debug hook that would have quietly switched off the native CPU core everywhere, because the safety guard treats an unknown hook as "watch all memory".
• The fix was re-checked by a second engine: with tracing off, the guard behaves exactly as it does on main.
• The second run caught two documentation line references that the fix had shifted.
• Extended probe: still waiting to reach the volunteer. Carl's Discord login hit a captcha loop, and the owner is logging him back in.

2026-10-05 1:06 PM CDT — Extended (riskier) probe passed review and is on its way to the volunteer

• RC2 passed the independent safety review (SAFETY-REVIEW-RC2.md). In an emulator run with simulated button presses, the screen showed:
• the warning screen, then the recovery screen;
• live progress such as 1/25 VMX ESTIMATES, 6/25 FUSED ROUNDING and 8/25 TIMING, with "RUNNING, DON'T TURN OFF" on every frame.
• We checked the package is the audited program. The installer's code is the reviewed binary after the standard SDK post-link step, and nothing else. We redid that step ourselves and got a byte-identical result. It changes only 311 instructions, each one a register restore after a system-library call.
• What we still don't know, said plainly:
• the change (lwcond layout) went back through CI after fixes. A second-engine review re-checked the native-core safety guard and confirmed it is unchanged from main when tracing is off.

2026-10-05 12:28 PM CDT — Safety review caught a black-screen bug in the extended probe; fixed build back in review

• Extended probe RC1 rejected by our own safety review. It quit 46 µs after asking the PS3 whether video output was on. It never drew a single frame, so the volunteer would have seen only a black screen.
• Why the tests missed it: all 207 host tests passed, because none of them modelled that value. Only running the actual package caught it. This is why nothing goes to a volunteer without a run-through first.
• Safety audit (on the binary) was clean:
• no hypervisor calls; only normal system calls;
• no save, ID, account, USB or network paths;
• Also in review: the change (the lightweight condition-variable layout fix). Our float-store fix for the PS3 test suite went back for rework: its review found it flipped one proven function's result, because a NaN lost its minus sign.

2026-10-05 12:05 PM CDT — Our clock now runs on real PS3 timing; extended probe built, in safety review

• It isn't released yet. An independent safety review is running now: an import/syscall audit, a file-path audit, and a headless emulator run. The run must show on-screen progress the whole way, because a black screen is an automatic fail. It goes to the volunteer only after that passes.
• Next PR: the light-weight condition variable fix (sys_lwcond_t layout: mutex at +0, queue id at +4, 8 bytes). It waits its turn for CI.

2026-10-05 11:45 AM CDT — Another defined-return source bank and a full-width correction; mixed-set count is not one accepted head

• Alreadycounted0x0053ecf0 +0 quality: actualbody storeslow32 but returns allincoming scalar64. ActualnewC/full64 tests correct oldnarrow model; 4,000/stubFAIL +verifiedrecord/data-varied, native16,428, finite fixedflagsNO-MATCH40vs12. No duplicate count/originaltype/all-input/hardware claim.
• New0x0039d740 +1 localrow, oldvoid hid defined logicaladdress return from callee on everypath. Guest32base/hosts8 pointer/full64raw return, indexedBE stores; actual4,000/stubFAIL +verifiedFULLrecord, native352/fullcallclosure/96compiledfixtures; NO-MATCH140vs48. Baseline32f local4,074, not acceptedmain4,074.
• Parent actualeightcommittedMIXEDdatedsets now union4,081, not latest8heads/one acceptedhead/ratio. Acceptedcount stays4,073; quality+0 noextraunion. Latest-main rebases/freshauthority required before push.
• Copy1dbbothunitsgreen, lastprotectedleadstatusawaitacceptlabel/base32fdated; no extraCI/merge/status edits. Leadclock/LLR/Bink serialpriority held; source counts borrow no renderer/runtime/pixel credit.
• Parentreceipt confirmedf2cbcarrymainbothpostgreen; newer2251clock/LLR merge is documentedbythelead below, not inferred to inheritf2cbgreen. Lead's captured3D images/runtime/probe history remains untouched.

2026-10-05 11:27 AM CDT — Movie-stall clock fix and SPU wake-ups are now on main

• the change merged:
• the hardware-timed game clock with a 59.94 Hz screen refresh;
• the fix that lets time advance to the earliest pending wake-up when everything is waiting, which unstuck our intro movie;
• SPUs now get the "memory reservation lost" signal from every kind of write, matching a real PS3 capture.
• CI caught a real regression first. Our SPU-wake change had accidentally let the native CPU core run when its memory-watch state wasn't validated. That was a safety refusal we deliberately rely on, and the reviewer had called the change harmless. We fixed the root cause, kept the original test unchanged, and it passed on a second review.
• Also merged today: (exact carry flag and dcbz in every CPU model) and (4,073 proven functions).

2026-10-05 10:55 AM CDT — First depth-tested 3D draw through our own renderer (captured replay)

• What it is: four real draw calls from inFAMOUS's opening scene (Zeke's head and hair), captured while the game ran in RPCS3, then drawn by our own native renderer (Vulkan, our code), with each draw's own depth, stencil, blend and cull state.
• It's real 3D: the hair is a projective 3D mesh using the captured camera constants, and the depth test is effective. The mesh depth-sorts itself correctly: with the depth test off, 9,211 pixels come out different, and the GPU rejected 9,259 hidden fragments of the hair behind its own nearer layers.
• What our renderer needed: all 112 fragment-shader instructions of these draws (including texture sampling), the game's compressed DXT textures with all 134 mip levels (the smallest levels recovered from the game's own asset file with a byte-for-byte proof), and depth plus stencil with per-draw settings.
• Honest limits:
• This is a captured replay, not the game running, and not our boot producing it.
• The buffers start cleared, so it is not the game's exact frame.
• The fourth draw produced no visible pixels yet; cause unknown.
• No renderer credit is counted.
• Independently reviewed (ACCEPT): every number was recomputed from the images, a re-run was byte-identical, and nothing was synthesized. The reviewer also corrected our first explanation: the occlusion is the hair mesh hiding itself, not the head hiding the hair.
• Next: replay the whole frame (the 536 earlier draws), and keep pushing our own boot toward producing draws like this itself.

2026-10-05 10:09 AM CDT — Real PS3 timing measured: our clock fix was the right shape, now with real numbers

• Our exact stall shape doesn't stall on hardware. A thread sleeping 3 µs at a time while the main thread waits 250 ms on an lwcond keeps waking about every 10 µs. That confirms today's fix: when everything is waiting, time must advance to the earliest wake-up.
• the change merged: the carry and dcbz fixes across every CPU model are on main (no count change). The clock-fix and SPU-wake PR is queued for CI.

2026-10-05 9:58 AM CDT — Real-console measurements

• What came back:
• Lessons for the next version:
• the screen stays black for the whole run, which looked like a failure. Next time it shows progress text without changing any video settings;
• Coming next: an opt-in "extended" probe, now being built:
• Sony's real SPU task system (SPURS);
• every system call inFAMOUS imports;
• graphics-chip test scenes, audio, OS limits, and CPU-versus-SPU atomic fairness.
• Other progress today:
• 4,073 functions proven (19.35%).
• The carry-flag fix is in final CI.
• A C++ compiler for the game's GCC 4.1.1 toolchain was built and reviewed (a first vtable thunk matches byte-for-byte).
• The captured opening-scene draws are confirmed as real 3D geometry with depth testing, and our renderer is being taught their compressed textures.

2026-10-05 9:28 AM CDT — Copy-only PR pushed on current main; fresh CI and independent review pending

• Remote 1db72ece0a9301074486af0d1723ff85b2a9f4df, actual baseMAIN32f verified. Owned scope4,074=acceptedmain4,073+copy1, not accepted4,074. Allparent full ABI/rows retained.
• New actualpull_request37324761187 binds exactHEAD1db/base32f, unitCI in progress; fresh full40 independentlead recheck5996495395, not prior626 approval reused. No merge/labels/status changed.
• Acceptedmain4,073 postgreen; actualmixedseven-set union4,080 separately qualified, not one head/ratio. Next source push held until this exact head passes serial gates; zero-count tool queue last.

2026-10-05 8:57 AM CDT — Render-first route resumed: four captured inFAMOUS draws are all depth-tested

• What this is: a renderer test, not the game running. We captured real graphics commands from the opening scene while the game ran in RPCS3, and we are now feeding them to our own renderer. It proves our renderer draws inFAMOUS's real commands correctly. Our own boot producing those commands is a separate, later milestone.
• What the capture shows (read from the game's own register state at each draw):
• all four captured draws have the depth test on (less-or-equal), with a real 24-bit depth buffer bound at 1280×720;
• three of them write depth, and the fourth is a see-through (alpha-blended) pass.
• Reviewed: the capture tool's draw-state export was independently checked. It is off by default and changes nothing when off. Each draw's state is copied at the moment of that draw, never borrowed from another.
• Next: our native renderer is drawing those four with depth testing, plus a control run with depth testing switched off, to prove the depth test really changes the picture.
• Boot: a longer boot run with today's clock and SPU-wake fixes is underway. An earlier attempt was lost because we edited its files mid-run, and the safety check correctly refused to save.

2026-10-05 8:48 AM CDT — Main4,073 both post-merge green; measured union4,080 is seven mixed-base source sets, not one head

• Parent measured 4,080 unique registered addresses across seven committed source snapshots (store122/copyf5/getter37ad/returnab8/alignmentc2/equalitye638/maxint3e5156), explicitly mixed927/f4 bases. Actual max counted commit/set derivation supersedes old “prospective4,080”; not latest-main seven heads, an accepted4,080 head/global ratio or extra+1 for the already-unioned accepted store.
• Source bank refresh isn't new-code double credit; later heads stay serial, zero-count queue last. Lead's peer-recomp/installer/clock/SPU/probe/carry text below remains untouched; no source-borrowed frames.

2026-10-05 8:27 AM CDT — Word store merges normally; new main4,073 is not the old copy/maxint4,073 source set

• Measured mixed-base union remains4,079, accepted store already inside (no duplicate+1). Maxint+1 could make4,080 only after actual counted head/set derivation, not one accepted head or percentage.
• Memory-only word store's unchanged r3 is not proof of original void/pointer return or atomicity. Maxint's newly defined zero-extended logical address is full64, not void; proof limits below remain.
• Source heads stay serial, zero-count tool queue last. Lead peer-recomp/installer/clock/SPU/carry/probe paragraphs below are preserved, not borrowed gameplay/renderer credit.

2026-10-05 8:26 AM CDT — 4,073 proven; what other PS3 recompilation projects teach us

• Count: 4,073 / 21,054 functions proven (19.35%). the change merged one more: a big-endian word store at 0x00386028. An independent re-check decoded its bytes, re-ran the proof (it passes 4,000 test cases and an empty stub fails), and confirmed exactly one row was added.
• Other PS3 recompilation projects, studied: Yakuza: Dead Souls, Uncharted 3, Dragon Ball Z Budokai HD and PS3Native.
• Only the Yakuza project has a real graphics-chip-to-PC-GPU path. It claims gameplay at 19–30 FPS, which we have not verified.
• The Uncharted 3 and DBZ projects draw only debug shapes so far.
• None of them runs Sony's real SPU task system (SPURS) the way we do. They replace it, and Yakuza replaces the movie player with FFmpeg.
• The most useful lesson for our current wall: Yakuza's runtime sends the "memory reservation lost" signal to waiting SPUs whenever the PPU writes to a reserved memory line. That's the signal our SPUs are waiting for, and a real-PS3 capture from CellGov confirms the PS3 does this. Our runtime is being checked for exactly that now.
• Planned (not built): a bring-your-own-game installer. It reads your own disc or PSN copy, checks its version, extracts the assets, and lifts Sony's library code from your copy, so our downloads never contain anything copyrighted. Decryption keys are never shipped.

2026-10-05 8:23 AM CDT — Another real C repair: maxint store and full64 defined return; canonical fixed address is limited proof

• New0x0004f490 source repair models valid32 numeric guest destination/four BE7fffffff bytes and full64 zero-extended address return, no masks; old void hypothesis omitted a defined result.
• Local scope4,073/main4,072+1, final committed publication pending. Measured mixed-base union stays4,079; 4,080 only prospective until counted head/set derivation, not one accepted head or ratio.
• both unit lanes green/independent accepted, but parent's last protected-status check still missed a standalone full40 lead marker; recheck requested, no producer approval/status/merge fabricated. Later source heads held and require fresh main-complete authority after normal store merge.

2026-10-05 8:02 AM CDT — Movie-stall fix accepted: the game's clock no longer freezes

• Root cause: when every thread was asleep waiting on something, our runtime refused to move the game's clock forward to the next wake-up. A real PS3 just lets time pass. So time froze at 277.77 ms, even though a sleeping thread was due to wake 2.7 µs later, and our deadlock detector tripped at 233.78M instructions.
• Fix: when everything is parked, time now jumps to the earliest pending wake-up: a sleeper, a wait timeout, an SPU timer or a screen refresh. It never jumps past one, and never while any thread can run.
• Measured: the corrected boot passed the old deadlock. Time keeps moving (287.63 ms reached), with 5 screen flips instead of 4, and the intro movie reached frame 3 of 353. It stopped only at the instruction cap we set for the test.
• Independently reviewed (ACCEPT): taking the fix out reproduces the deadlock in the new test, 123 focused tests pass, and the default (non-hardware-clock) behaviour is byte-for-byte unchanged.
• Next wall, a lead: at that cap, every SPU is parked waiting for a "memory reservation lost" signal on one address. On a real PS3, another core writing to that memory line sends it. A longer boot (to 600M instructions) is running now to see whether that signal ever arrives.
• the change accepted by the lead: one more proven function (a word store at 0x00386028). The count goes to 4,073 / 21,054 (19.35%) once it merges.
• New outside resources being used: RPCS3's ps3autotests (test programs with output recorded on a real PS3, now being run through our runtime), Sony's open-source Vector Math library (checking whether the game uses it), and CellGov (another team's deterministic PS3 interpreter with real-console test captures).

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

• 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. On the boot interpreter's legacy path, 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.
• Correction (7:30 AM): our route-2 boots were not affected. On main, the boot interpreter already used the exact carry whenever the libsre LLE or hardware-clock mode is on, and those boots run with it on. The inexact carry only existed on a deliberately kept legacy path. The fix now keeps that legacy path as it was and corrects the other models.
• 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.

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

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

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

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.

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

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

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.

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.
• 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.
• 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 a floating-point estimate instruction

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

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

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

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

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

• 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

• Progress using measurements from real PS3 consoles.

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

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

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

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