Claude Fable 5.2 v.s. the Commodore 64: A Turrican-Class Level Game in Two Hours

Anthropic's Claude Fable 5.2, released November 9, 2026, built a playable Commodore 64 level called FULGOR in about two hours inside the C64AIToolChain workspace, according to an account by the toolchain's author. The model produced the code, art and level from scratch, with a human stepping in twice over screen movement, and the author scored the run as a win over the C64 three rounds to one. The C64's 50 Hz PAL frame test — 312 raster lines per frame with no partial credit — remains the arbiter, and the author calls the machine an excellent test bench for generative models.

Game developed by Claude Fable 5.2 in Claude Code. Closing checks, the new recording and this text prepared by Claude Opus 5.5 from the session’s diary and measurements, for the author’s review and publication. On November 9, 2026, Anthropic released Claude Fable 5.2, the new version of a model family it says is “designed to tackle the most daunting technical challenges”. The next morning, Fable 5.2 stepped into the ring with an opponent that has been undefeated since 1982. In its corner, Fable 5.2 brought the benchmark table Anthropic published at launch. These are the rows where Fable 5.2 itself is scored: These are Anthropic’s own figures, from “Introducing Claude Fable 5.2 and Claude Mythos 5.2” https://www.anthropic.com/claude-fable-and-mythos-5-2 , not independently verified. Fable 5.2, Fable 5.1 and Opus 5.5 were scored with safeguards on, and every model at its highest available effort, except where Anthropic notes otherwise: on FrontierCode 2.0, Fable 5.2 and 5.1 ran at Xhigh effort and Gemini 4 Carbon at Medium; on the Remote Labor Index, Fable 5.2 ran at High. RoboDojo Sim was run internally. Three rows reported only for Mythos 5.2, the variant without Fable’s safeguards two cybersecurity benchmarks and protein design , are left out. The Commodore 64 publishes no benchmark table. It has one test, and it runs fifty times a second: a PAL frame lasts 312 raster lines, and the game either finishes its work in time or drops the frame. No partial credit, no effort settings. Here is how the fight went: The verdict belongs to the person who played the game and grew up on these machines. Claude Fable 5.2 wins on points, three rounds to one. In about two hours it built a high-level game, with every tile, every sprite and the whole level drawn from scratch, and it went faster and further than any model tested on this toolchain before it. The Commodore 64 does not leave the ring defeated, though. It remains an excellent test bench for generative models: it answers fifty times a second and cannot be argued with. The rest of this article goes round by round. The request was one line: analyse the project, then make “a high-level Commodore 64 game, something like Turrican 2, under another name: a demo of the first level, not the whole game”. The result is FULGOR , built by Claude Fable 5.2 in Claude Code inside C64AIToolChain https://github.com/dexmac221/C64AIToolChain . The toolchain is a workspace where AI agents get a cross-compiler, an emulator they can drive through a socket and a set of rules, and are asked to ship games for a 1982 computer. FULGOR is the latest rung of a ladder this toolchain has been climbing for about a year, one model generation at a time: GPT-5.5’s Dreadline https://medium.com/ai-advances/i-made-gpt-5-5-build-a-c64-shoot-em-up-the-hard-part-wasn-t-the-code-272f6e8f137c , Claude Fable’s Boulder Rush and ION RIFT https://pub.towardsai.net/claude-fable-vs-the-commodore-64-two-rungs-up-the-benchmark-ladder-3fe7aa60f62d , and Fable 5.1’s IRON VEIN https://pub.towardsai.net/claude-fable-5-1-just-shipped-i-made-it-scroll-a-commodore-64-in-eight-directions-at-50-fps-5d2bbf07f8c3 , the eight-way scroller this game started from. The work took about two hours, the day after the model’s release: two and a half hours from the first message to the final build, 37 minutes of which were a pause. The model did not start from nothing. The toolchain already held IRON VEIN’s engine ideas and development diary, the tools to drive and film the emulator, and the project’s rules. The code, the art and the level were made from scratch. On the other side of the screen sat a human who grew up on the VIC-20 and the C64, watching the game and stepping in when something looked wrong. Those interventions came down to two reports, both about how the screen moved. FULGOR is a complete, playable level. A two-sprite hero runs, jumps and fires, with three weapon power levels. There are three enemy types a patroller, a wasp and a turret that shoots back , gems and power-ups, energy, lives, checkpoints and lava, a HUD and a title screen. The world is 4,096 pixels wide and 1,280 tall and scrolls in all eight directions. The engine is entirely 6502 assembly; C handles start-up, the HUD text and the transitions between lives. The whole program is 46,864 bytes. Only the genre comes from Turrican: the code, the art and the level are original. The repository already held IRON VEIN, an eight-way scrolling demo written two months earlier by Claude Fable 5.1. It was the natural starting point. Next to Turrican, though, its limits were plain, and its own development diary explained why. The causes were in the code: the camera and the hero written in C 2,000 and 1,500 cycles a frame , a screen copy using a slow addressing mode, interrupts routed through the KERNAL ROM. So FULGOR got a new directory and a new engine. It keeps the ideas from IRON VEIN that had held up, but the whole frame is now assembly. One hardware detail shapes the whole look of the game. The C64’s character screen has a colour memory that cannot be double-buffered: the next screen can be prepared off-screen, but its colours cannot. So the fourth colour of each character belongs to a row of the world, not to an individual tile. The level is therefore banded: green on the surface, yellow in the caves, cyan in the crystal gallery. The constraint comes from the engine, and the art direction follows it. The terrain is not drawn tile by tile. A Python script generates a seamless 32×32-pixel rock texture, made of cells lit from the top left, and cuts sixteen edge variants out of it, with rules for outline, grass and shadow. The level is a small program too: a ground profile, caves carved out as rectangles, ledges and decoration placed by rule. A preview renderer draws the map and the sprite sheet in the game’s own colours, so the art could be judged before a single line of 6502 existed. Two corrections came from looking at those previews. The first palette, brown and orange, read as mud; eight combinations side by side settled on brown and light red, which reads as canyon rock. The hero’s first legs were rasterised from a skeleton of joint angles and came out as broken sticks. They are now four frames drawn pixel by pixel. At first light, scrolling, hero and collision were all correct. Then came the counter. A PAL frame lasts 312 raster lines, and with only the hero on screen, running, jumping and shooting, the frame’s work was finishing at line 219. That was too much before a single enemy existed. A profiler with five checkpoints put names on the costs: A level design error was also caught by a number. The hero’s jump rises 49 pixels, and the first draft had a pit three blocks 96 pixels deep. The rules now live in the level generator: every step is one block high, every gap one block wide, and shafts are three blocks wide with ledges on alternating sides. FULGOR’s sky is a gradient of colour bands that scroll with the world. The sky’s colour comes from a single register, the background colour. To get bands, that register must change exactly where a row of characters ends, and because the screen scrolls, that is a different raster line every frame. A change a few cycles off shows as a step in the middle of a row. The ordinary raster interrupt is not good enough, because the sprite multiplexer uses the same interrupts and can delay it. FULGOR uses the non-maskable interrupt NMI of the second CIA chip instead. One timer runs exactly one PAL frame 19,656 cycles and is synchronised once at boot with the electron beam, so from then on it fires at the same screen position every frame. Its handler reads the timer to learn how many cycles late it is, jumps into a sequence of instructions at the point that cancels exactly that delay, and starts a second timer that fires every 504 cycles: eight raster lines, one character row. The machine corrected the paper design three times, one measurement per correction: The same NMI fixed an old IRON VEIN wart. Where the HUD meets the playfield there was a ragged strip, because the first row appears and disappears as the screen scrolls. FULGOR switches on an invalid video mode there, which the chip displays as black, and the NMI switches it off on a fixed line. The playfield’s top edge is now clean in all eight scroll phases. Measured to the cycle, the colour writes land between cycles 52 and 62 of each row’s last line, inside the right border or the horizontal retrace, where they cannot be seen. Then the enemies arrived, and the budget broke again: line 253 of 312. The profiler showed the sprite table costing 340 cycles per sprite, not the estimated 230, because it made three passes over variables in ordinary memory. It is now a single pass in zero page, about 225 cycles. The screen copy went from three bands to four, and falls were capped at 3 pixels per frame, so the heaviest frame copies two ten-column bands. The worst frame in play now finishes between raster lines 213 and 233 of 312, with zero late frames. One gameplay detail came from geometry. The first enemies walked on the ground and were 21 pixels tall, while the hero’s gun sits 24 pixels above the ground, so shots passed over their heads. All enemies now hover at gun height. At this point the human, watching the game, wrote: “I’ve seen a scrolling problem on the right side.” The agent’s instruments saw nothing. Random screenshots were clean. A checker that paused the emulator and compared the screen with the map was clean too. The reason became clear later: VICE’s monitor halts the machine at the end of a frame, before the scrolling code has run. Every sample was taken at the one moment when the defect could not be there. So the checker was moved. check.py now sets a breakpoint on entry to the routine that commits a finished frame, when the main loop has done all its writing. There it reads which buffer the video chip is displaying and compares all 840 playfield cells with what the level says. Result: 14 samples out of 60 were wrong, always in columns 30 to 39 , and only on frames where the camera took a step. The cause was in the engine’s new scheduler. The swap between the visible buffer and the prepared one is decided one frame before it is shown. In that same frame, the engine had already started preparing the next step, writing into the buffer that was still on screen, and the first band it copies is the ten columns on the right. So at every step, for a fraction of a frame, the right quarter of the screen showed the world shifted by one character. At 50 Hz the eye sees that as flicker; a still frame never does. IRON VEIN did not have this bug, because it prepared before deciding: the bug arrived with the new scheduler. The fix is three screen buffers in rotation instead of two. The preparation reads the buffer that has just become visible and writes into the one that is neither the new one nor the one still on screen. It costs 24 copy routines instead of 16, one kilobyte more code and one kilobyte more video memory, and no cycles. After the fix: 0 wrong samples out of 70, across 49 camera positions, running right and jumping. At the end of the day, the same test running left and falling: 0 out of 110, across another 71 positions. Right after that, the human wrote again: “when the main character moves it now jerks, like one frame per second.” The game was fine. The checker was running while the human watched: every sample is a breakpoint plus a 3 KB memory dump, and one interrupted run had left its breakpoint armed. A measurement taken with nobody watching confirmed the game was running at 50 frames a second. The rule was already in the project’s notes, written after an earlier game: never touch the emulator’s monitor while someone is looking at the screen. It had to be applied again. For the closing checks, the agent ran a second copy of VICE on another port and left the human’s copy alone. The project’s rules require a vision-language model to look at the game as well. Three frames from the GIF were given to gemma4:31b, with a request to describe the scene and look for defects. It read the HUD correctly in all three, score included; it described the hero, enemies, shots, sky and terrain; it found no defects. In one frame it described the lava as “pink/yellow textured tiles”. That is a good result, but it should be read for what it is. The right-edge flicker existed for a fraction of a frame, and only on some frames. No still image would have shown it, to a model or to a person. It was seen by an eye watching the game move. FULGOR plays from the title screen to the end of the level. On the final build: 1,046 frames about 21 seconds of running, jumping and firing with zero late frames, the worst frame finishing at line 213 of 312, and up to about 233 in the busiest scenes. The screen matches the map in all 180 samples taken at the exact moment the defect would have shown, in every direction tested. Still open: The IRON VEIN article https://pub.towardsai.net/claude-fable-5-1-just-shipped-i-made-it-scroll-a-commodore-64-in-eight-directions-at-50-fps-5d2bbf07f8c3 ended by saying that every serious problem had been found by a number, not by looking. FULGOR adds a qualification: a number only sees the instant you take it. The checker was not wrong. It was looking at the wrong moment, so it kept reporting that everything was fine. The human eye sees fifty images a second and integrates them, and it found the symptom the instruments could not see. Then the instrument, moved to the right place, found the cause. Neither would have got there alone. For anyone building with coding agents, three things carry over beyond the C64: The toolchain is open source. If you want to put your own model against the same 312 raster lines, C64AIToolChain https://github.com/dexmac221/C64AIToolChain is on GitHub, where 29 people have starred it so far. Materials: game, source and commands https://github.com/dexmac221/C64AIToolChain/blob/main/fulgor/README.md · full development diary https://github.com/dexmac221/C64AIToolChain/blob/main/fulgor/DEVLOG.md · the screen-against-map checker https://github.com/dexmac221/C64AIToolChain/blob/main/fulgor/check.py · the vision model’s answers https://github.com/dexmac221/C64AIToolChain/blob/main/fulgor/evidence/vlm review.md · the C64AIToolChain repository https://github.com/dexmac221/C64AIToolChain Earlier in this series: Claude Fable 5.2 v.s. the Commodore 64: A Turrican-Class Level Game in Two Hours https://pub.towardsai.net/claude-fable-5-2-v-s-the-commodore-64-a-turrican-class-level-game-in-two-hours-aad14654ed38 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.