Sonic 060 - credits and attributions

An honest account of who made Sonic 060, and of where every idea, every line of borrowed code and every byte of borrowed data in it came from. It is written to be shown to the people it credits, and to anyone else.

Sonic 060 is an unofficial, non-commercial fan port of Sonic The Hedgehog (Mega Drive, 1991) to AGA Amigas. It was vibe coded by Afrotechmods with Claude, Anthropic's AI model: Afrotechmods never wrote a single line of code. He started the project, directed it, set its rules, chose its art and tested the builds on his own Amiga; Claude wrote all of the code. It is not affiliated with, endorsed by, or connected to SEGA, nor to reassembler, RetroRic or Sonic Retro. Any mistakes below are ours. Corrections are welcome and will be applied.

Sonic 060 is not Aonic. Aonic is reassembler's port, with RetroRic's palette and art work, and it is aimed at a stock Amiga 1200. Sonic 060 is a separate port by different hands, aimed at an A1200 with a fast accelerator and fast RAM. The two share nothing beyond what this document credits. No Aonic code, art or data is in Sonic 060, and none of it has ever been seen.

This is version 3.0 of this document (29 September 2026), written for the first public release, Sonic 060 1.00a. Earlier versions were written for the project itself and for an email to reassembler and RetroRic. Section 13 explains how this one was put together.

The short version

If you remember one thing: reassembler's published architecture is load-bearing here. Strip it out and Sonic 060 does not exist in its current form. Nothing of RetroRic's artwork is in it, but his published reasoning changed two design decisions.

Both of them can be supported directly, and their work is ongoing. Their Patreon, YouTube, itch.io and site links are in sections 2 and 3, beside what each is credited for, and gathered again under Supporting the people Sonic 060 is built on (section 4). Sonic 060 takes no money, so nothing here competes with them.

1. SEGA

Sonic The Hedgehog, its characters, code, level design, artwork and music are SEGA's property. Everything Sonic 060 contains is a derivative work of theirs. We take no money for it, we distribute no ROM, and we will comply immediately if asked to stop.

The project's tools convert the game's data from a legally obtained ROM and the disassembly at build time, and the project's source repository holds none of SEGA's data. The game's level and music files, and the two Workbench icons (drawn from Sonic's own sprite art), are SEGA's artwork and music in a different form.

2. reassembler (@reassembler68k, GitHub djyt) - Aonic

The most important attribution in this document. reassembler has spent about ten months porting Sonic 1 to a stock A1200, and published the engineering as he went, across thirteen devlog videos and fifteen free Patreon posts. His architecture is the foundation Sonic 060 is built on.

His code is closed until his game ships. We have never seen it. Everything below came from his public videos, his public Patreon posts, his demo's readme, and the hunk and symbol layout of the shipped aonic executable. No byte of his binary was disassembled into Sonic 060.

Where his work lives, and how to support it

Everything this section credits him for, he published himself. If any of it is worth something to you, this is where to say so. His Patreon is how the work gets funded, and his Aonic devlog posts are free to read without a pledge, so it is support rather than a toll.

2.1 Ideas of his that Sonic 060 adopted - the architecture

1. The attached-AGA-sprite background layer. Eight hardware sprites, 64 pixels wide, attached in pairs for 15 colours, forming a 256-pixel strip repeated horizontally, repositioned per parallax band by the copper, sitting behind the playfield. This is his invention as applied to this problem, and it is the load-bearing decision of the renderer. A CPU-written background, costed against Green Hill's own data, came to 9 ms on a typical screen: A 25 fps design. His layer costs about 1 ms. Without it there is no 50 fps port.
2. 288 pixels wide, fetch mode 1. He discovered that AGA sprites and the bitplane fetch of a hardware-scrolled display cannot coexist at 320 pixels, and said there is no easy way around it. We measured it independently on Afrotechmods' machine and on an emulator and got exactly his answer, but we knew where to look because he said so first.
3. A resident, hardware-scrolled playfield with partial redraw. Draw only the column or row that scrolls into view; never redraw the frame.
4. A pristine second copy for restoration, with no save-before-blit. We kept the principle and changed the mechanism (ours is a fast-RAM shadow), but the insight that the save step can be deleted rather than optimised is his.
5. A dynamic copper list rebuilt every frame, skipping bands whose scroll value has not changed. He found this counterintuitively faster than a static list. We took the result and added delta-writing on top.
6. One restore rectangle per object, not per sprite piece.
7. Objects unchanged for several frames skip the restore entirely.
8. Pre-built 16x16 blocks with their flip variants, replacing runtime 8x8 tile composition.
9. The animated-tile solution, both halves. A script marks, offline, every block containing an animated tile; at runtime a handler keeps a live list of the on-screen ones and touches only those. We would not have found it unaided.
10. Foreground priority as a per-block priority mask rather than a re-derivation at runtime.
11. A bespoke HUD in its own copper band, outside the scrolling play area, as a rendering optimisation, with its one-row layout. (His sits above the play area; Sonic 060's sits below it, at Afrotechmods' request.)
12. Sprite draw order back-to-front, inverting the Mega Drive's front-to-back hardware order.
13. The AGA quirk that keeps sprites off the leftmost pixels, and his 2-pixel background scroll granularity.
14. REV01 as the target ROM revision.

2.2 Rules of method adopted from him

• "Whatever is expensive at runtime, precompute it into the data with a script." He arrives at this three separate times and generalises it. It is the governing rule of Sonic 060's whole asset pipeline.
• "Optimise for the maximum, not the average." His profiler reports the worst case because isolated spikes, not averages, drop frames. Sonic 060 logs every slow stretch by its worst frame and where it happened, so the slow places report themselves.
• Harness the game's own deterministic demo playback for profiling, so runs are comparable.
• Test on real hardware continuously and distrust the emulator on timing. He learned this when a build that ran clean under emulation flashed badly on a real A1200. Sonic 060 adopted it as policy, and it was right every time the two disagreed (section 11.5).
• "Architecture is everything": Micro-optimisation is marginal by comparison.

2.3 Numbers of his used as ground truth

• 70,824 colour clocks per frame on a stock A1200, used to check our bus arithmetic.
• His on-screen blitter calculator (14.2 objects a frame at five planes, 10.5 at six), used to check our own per-object costs.
• His published profiler captures and spec sheet, used as a sanity check on our budget.
• His observation that AGA widened the bus for display fetch only, and left the blitter and CPU where they were: The sharpest one-sentence statement of why this problem is hard.

2.4 Ideas of his deliberately not used, and why

These are not criticisms. Almost every one exists because he targets a stock A1200 with no fast RAM, a constraint he chose as a personal challenge. Sonic 060 targets an A1200 with a fast accelerator and fast RAM, so the constraint that produced these does not apply.

2.5 Where Sonic 060 diverged most sharply: Audio

reassembler's public djyt/sonic2mod converts Sonic's SMPS music to ProTracker MOD by synthesising instrument samples with a YM2612 core, and his engine plays them with Frank Wille's ptplayer. It is good work and it is public.

Sonic 060 did not use it, or any part of it. Every track and all 49 sound effects are rendered to PCM offline, by running our own reimplementation of the Sonic 1 sound driver against a YM2612 emulator and our own SN76489 model, and the result is streamed through Paula. (Pre-rendered PCM in deduplicated chunks was Afrotechmods' idea, section 11.3.) Since build 75 the music files are also losslessly packed. This costs a great deal of fast RAM, which Sonic 060's target machine has and his does not. No code, configuration or output of sonic2mod is in Sonic 060.

2.6 What is unambiguously his

• The attached-AGA-sprite background layer as the solution to Mega Drive parallax on AGA.
• The animated-tile offline-mark / runtime-handler design.
• The "precompute it into the data" discipline.
• The 288-pixel fetch-mode-1 finding.
• "Optimise for the maximum, not the average," and demo-driven profiling.
• Aonic itself, its name, its demo, and every measurement he published.

2.7 One thing he should know

reassembler is on record that he uses no AI on his game's own code: He writes it by hand, for enjoyment and control, and uses AI only on tooling. He has also said he finds AI agents "incredibly unreliable with assembly language and surprisingly good with modern languages."

Sonic 060 is the opposite experiment, and he is entitled to know that. All of its code, including the 68000 assembly, was written by Claude. His assessment was quoted in the project's own planning documents as a guard against over-confidence, and section 12 lists some of the ways it proved right.

3. RetroRic (@RetroRic79) - tech art and the independent second opinion

The honest headline: There is no RetroRic material in Sonic 060. Not one colour value, not one tile, not one line of code. It is important to say so plainly, because he is credited for tech art on Aonic and someone reading Sonic 060's screenshots might reasonably assume otherwise.

Sonic 060's palettes are generated from the Mega Drive's own palette files in the disassembly (each 3-bit channel scaled to 4 bits). Nothing is hand-crunched, because at 64 colours nothing needs to be.

Where his work lives, and how to support it

Palette sequences were transcribed from his videos while studying the problem. Those values were never used: The project's own notes forbid it, because video gives roughly +/-10 per channel and because the 64-colour design does not need them.

3.1 What was genuinely taken from him: Reasoning, not pixels

1. The tile-animation verdict, which changed the design. His waterfall experiment showed that a block repeated across a wide area cannot be animated by rewriting its pixels, because every instance must be rewritten each step; palette cycling is far cheaper because it remaps a colour instead of moving data. This is directly implemented in Sonic 060: Green Hill's water shimmer is a palette cycle.
2. His documentation of the palette crunch is why Sonic 060 decided not to do one. He showed step by step what crunching 20 background colours to 16 and 40 foreground colours to 32 costs: Locked colours, merged ramps, every hole repainted by hand, iteration. Seeing that price per zone and per layer made the 64-colour design obviously right for this hardware. His "16 colour prison" framing is also the argument against dual playfield.
3. The convergence on baking static sprites into the tile layer. He and reassembler reached the same place independently; two experienced developers converging was strong evidence.
4. Level data volume in RAM as a principal risk: His call, made early. It was.
5. The finer AGA colour space partly offsets the smaller colour count. A genuinely useful insight.
6. Rings in spare hardware sprites: A real technique, and his. Not available to Sonic 060, whose sprites are all spent on the background.

3.2 A disagreement we recorded, which was our mistake

Earlier versions of this document said we disagreed with him about dual playfield giving eight colours per layer. That note was our error, and he corrected it on 20 September 2026: "My tech demo was aimed at ECS Amiga's with a fetchmode enhanced AGA build. So dual playfield on ECS is 8 colours per layer." On ECS that is exactly right; sixteen per playfield is the AGA number. The two figures never disagreed. Every figure he quotes about that demo is an ECS figure unless he says otherwise.

3.3 What should be credited to him

• The tile-animation-versus-palette-cycling finding, as a general Amiga result.
• The published method and true cost of a Mega Drive-to-Amiga palette crunch.
• His role as the independent second opinion that corroborated several of reassembler's conclusions before we relied on them.
• The tech art of Aonic, which is his, is not in Sonic 060, and should not be confused with it.

4. Supporting the people Sonic 060 is built on

Sonic 060 takes no money, in any form. Nothing is sold, no donations are accepted, and there is no Patreon or tip jar of its own. That is why this page can point at other people's funding links without a conflict of interest.

If what is credited above is worth something to you, these are the two links that matter:

• reassembler: https://www.patreon.com/REASSEMBLER68K, whose published architecture Sonic 060's renderer is built on. His Aonic demo is free at https://reassembler68k.itch.io/aonic, and Aonic is the port that will bring Sonic to stock, lower-end Amigas.
• RetroRic: https://www.patreon.com/RetroRic79, whose palette work and tile-animation finding changed two of Sonic 060's design decisions. His work is at https://retroric.itch.io.

Both also sell finished work: OutRun: Amiga Edition and the OutRun vinyl (https://reassembler68k.itch.io/outrun-amiga-edition and https://reassembler.bandcamp.com), and the Wardner AGA demos (https://retroric.itch.io). The free things count too: Both devlogs are on YouTube (https://www.youtube.com/@reassembler68k and https://www.youtube.com/@RetroRic79).

Sonic Retro, the largest single borrowing here, takes no money either; the way to support it is to contribute: https://github.com/sonicretro/s1disasm and https://info.sonicretro.org.

5. How reassembler's and RetroRic's material was studied

Stated in full, because the depth of it should not be hidden: Sonic 060 was built by Afrotechmods teaching Claude from reassembler's and RetroRic's published work. He gathered their material, handed it over, and insisted it be examined far more closely than a first pass had done. What Claude took from it is in sections 2 and 3; this section is how it was taken.

Their videos. Thirteen videos were studied: Ten of reassembler's Aonic devlogs, and three of RetroRic's (his December 2025 dev log and his two Palette Panic videos). YouTube could not be reached from Claude's working environment, so Afrotechmods supplied subtitle files for all thirteen, the audio of three, low-resolution copies of nine, and about fifty full-resolution screenshots he captured himself from four of them.

• First pass: 2,109 frames, one at every scene change, each opened and read.
• Second pass, at his insistence. On 11 September he objected that most of the visual material had gone unexamined. He was right: Scene-change sampling misses slides that build up, code being scrolled and palettes changing one colour at a time, and 30 to 59 % of each reassembler video and 84 to 93 % of RetroRic's palette videos had no frame in stretches of over 30 seconds. A second pass took a frame every five seconds (his suggestion), another 1,834 frames, reviewed by fourteen parallel reviewers, one per video and one for the Patreon images.
• In all, about 4,000 frames of their videos were examined. On-screen code, profiler tables, tool screenshots, slide captions and palette swatches were transcribed into about 7,000 lines of frame-by-frame reports. The second pass overturned several conclusions of the first.

reassembler's Patreon. All nineteen of his Aonic posts, every one of them free rather than paywalled; fifteen had readable text and all fifteen were read in full. Their 85 attachments were each opened and reviewed (83 images, and two that turned out to be video playlists). These posts are the most technically detailed source in the whole project, and they corrected several conclusions drawn from the videos alone.

The Aonic demo. Its readme was read, and the shipped executable's hunk sizes, memory layout and symbol names were examined to infer its architecture. It was not disassembled, and no part of it was reused.

RetroRic's demos and pages. Afrotechmods supplied eight of his tech-demo archives, and his itch.io pages were read. Palette values were transcribed from his videos while the problem was being studied, and deliberately never used (section 3).

Also read: reassembler's public GitHub repositories (sonic2mod and his collision explainers), and press coverage of Aonic, used only to cross-check dates and claims.

Everything above was published by its authors publicly and without a paywall. The first version of this document (16 September) was written for Afrotechmods' email to both of them about Sonic 060, and RetroRic's reply corrected it (section 3.2).

6. Sonic Retro, Hivebrain, and the Sonic 1 disassembly

sonicretro/s1disasm: By far the largest borrowing in Sonic 060.

159 source files from the disassembly are compiled directly into the game: 120 object files, 11 from _inc/, 7 animation scripts, 7 from _main/, 12 demo and ending input recordings, and the constants and variables files. This is Sonic's physics, collision, animation, camera, object behaviour and level logic, running essentially as the Sonic Retro team reconstructed it. The project's converter mechanically widens Mega Drive short addresses and flags the 24-bit address-masking tricks for repair by hand; the game logic itself is unchanged.

Also used from the same tree, as data: Level layouts, chunk and block tables, collision arrays and the angle map, sprite mappings, DPLC scripts, palettes and palette cycles, pattern load cues, and the SMPS music and sound-effect sources.

Licence reality: the disassembly carries no licence, and its readme says the content is for informational and educational purposes only, with commercial use expressly prohibited. Sonic 060 is non-commercial and will stay that way. Sonic Retro cannot grant rights to SEGA's code and does not claim to.

Credit also to Hivebrain for the 2022 rewrite (cvghivebrain/s1disasm), studied when choosing an assembler flavour, and to the SonLVL team, whose data-format work underpins the community's understanding of Sonic 1 even where the tool was not used.

7. Third-party code and data in Sonic 060

Nuked-OPN2 (ym3438.c, ym3438.h) - the only third-party source code

• Author: Alexey Khokholov (Nuke.YKT), (c) 2017-2022
• Licence: LGPL 2.1 (full text kept with the files)
• Status: a verbatim, unmodified copy
• Role: a cycle-accurate YM2612/YM3438 emulator, used at build time on a PC only to render Sonic's FM music and sound effects to PCM. It is never linked into the Amiga program.
• With thanks, as its header records, to digshadow for the YM3438 decap and die shot, and to Matthew Gambrell and Olli Niemitalo for the OPL2 ROM work.

The rewind's cassette sound

The whirr heard while F5 rewinds is a 0.3-second royalty-free sound effect, free for commercial use. Afrotechmods brought it in from the rewind kit of his earlier Amiga project (FAmiga).

8. Tools used but not copied

9. Technical references and documentation

• Amiga Hardware Reference Manual (Commodore-Amiga): The blitter and DMA cycle tables behind every bus cost in the project.
• Dutch Retro Guy, powerprograms.nl/amiga/dual-layer.html: The dual-layer analysis and the DMA cycle budget behind the frame-rate arithmetic.
• Codetapper, codetapper.com/amiga/sprite-tricks: Sprite multiplexing for background layers, the published prior art behind the technique reassembler settled on.
• Jarno Valtanen, jvaltane.kapsi.fi/amiga/howtocode/aga.html: AGA fetch modes.
• AGA.guide, and the WinUAE source: The AGA register details.
• Toni Wilen's "Undocumented Amiga hardware" thread on the English Amiga Board, read in full at Afrotechmods' request.
• Sonic Retro wiki: The Sonic Physics Guide and the compression format documentation.
• Robert F. Rice's coding (Golomb-Rice codes): The textbook method the music packer uses to store sample differences losslessly. IMA ADPCM was also measured, and rejected as audibly lossy.
• The NewIcons format, as implemented in newicon.library, ModifyIcon and AROS: The encoding of the Workbench icons.
• comp.sys.amiga.programmer archives and the AmigaLove forums: Chip RAM speed discussion, used only until Afrotechmods' own card was measured.

10. Open-source projects surveyed and not used

Listed for honesty, because the project's early plan was built on some of these. No code from any of them is in Sonic 060.

• Clownacy: clownnemesis, clownlzss, accurate-kosinski and others. The Nemesis, Kosinski and Enigma decoders were written from scratch in Python instead, and checked by rendering Green Hill against the real level. His work is still the reference the community measures correctness against, and (separately) it is in Aonic's lineage.
• flamewing: mdcomp, mdtools, asl-releases. asl-releases is used as a build tool; no mdcomp or mdtools code was taken.
• AmigaPorts/ACE, tditlu/amigeconv, GitExl/Turrican2Editor: Surveyed for chunky-to-planar conversion; ours was written from scratch.
• 1hedu/emuTOS-MCD: Sonic 1 retargeted to a Mega CD under EmuTOS, the closest precedent anywhere. Read for its porting discipline, deliberately not copied.
• kirjavascript/Flex2, sonicretro/SonLVL, sonicretro/KENSSharp, tristanpenman/spindash, ValleyBell/SMPSPlay, djyt/sonic2mod: Surveyed, not used.

11. Afrotechmods

Afrotechmods started Sonic 060, ran it from the first day to this release, and tested it on his own Amiga. He vibe coded it, and never wrote a single line of code: In his own words the game was "100% vibe coded by Afrotechmods with Claude". What he did instead is set out below in the same detail as everyone else's part, and only where the credit is due. Ideas that were Claude's and that he approved are listed separately from ideas that were his.

How this section was compiled: From the project's own records (the development log, the handover notes, the change log, the test notes of every build, the commit history, his uploaded logs, photos and videos, and the text of his messages from 22 September on). Every count below is a count of what those records hold, so it is a lower bound. The hours in 11.7 are estimates, and are marked as such.

11.1 The project itself

• The question that started it (10 September 2026): Could reassembler's published work be carried on to a complete Sonic 1 on the Amiga? The feasibility study, the plan and everything after answer that question.
• The re-examination (11 September): He judged that the first study had left most of the video material unexamined, and had it redone. Every frame of all thirteen devlog videos was then reviewed twice. His own suggestion of sampling a frame every five seconds turned out to be the right safety net, and the video tool uses it to this day.
• The go-ahead: Development started when he said so, on 11 September, and the first playable build reached his Amiga the same afternoon.
• The target machine, and every real-hardware result: An A1200 with a Blizzard 1260 (68060 at 50 MHz, 16 MB of fast RAM), 2 MB of chip RAM, Kickstart and Workbench 3.2.3, a flicker fixer and a ViewSonic monitor.
• The name. "Sonic060" as a working title (20 September), then Sonic 060 as the official name (26 September), with the rule that it must never be confused with Aonic.
• Nineteen days, first question to public release (10 to 29 September 2026).

11.2 What he supplied

• His Amiga, and every hardware measurement. The whole design rests on a number from his machine: His benchmark from an earlier project showed chip RAM writes at about 3.1 MB/s, not the 7 MB/s the first study had assumed. That single measurement turned a full-redraw design into a 25 fps design and forced the switch to hardware scrolling with partial redraw. He then ran six diagnostic programs on his machine (SonicDiag 1.2, 1.3 and 1.4, first light, a music audition program and a sprite ruler) and photographed their screens.
• The source material: his legally obtained ROMs, the Aonic demo and eight RetroRic demo archives, subtitle files for all thirteen devlog videos (the development container could not reach YouTube, so these were the main way in), and about fifty full-resolution screenshots taken from those videos.
• His earlier Amiga project's knowledge (FAmiga, an NES emulator for the same machine): The benchmark above, the emulator set-up, the Amiberry recipe that became the project's second emulator, the rewind kit (a guide, a royalty-free cassette sample and a player), and later the lessons its testers taught him about other people's Amigas (graphics cards, PAL and NTSC, grey screens), which became the check Sonic 060 now makes before it starts.
• Reference footage: REV01 gameplay, a longplay of Green Hill 3, and pictures of the original Special Stage, each used to settle what the real game does.
• Uploads, counted from the records (lower bounds): about 490 frame logs, at least 75 run files, 3 Sandbox results files, several crash reports, about 60 to 75 photographs of his screen and about 24 videos.

11.3 His own ideas, requirements and rules

Each of these came from him, not from Claude. Where the idea did not turn out as he framed it, that is said too.

The game

• The music's whole design, and both of the ideas that shrink it (13 and 26 September).
• Pre-rendered PCM in deduplicated chunks was his idea: Rather than emulating the Mega Drive's FM chip live, or converting the songs to tracker modules, render every track to samples ahead of time and store each repeated stretch of a song only once, as a playlist of unique pieces. That is how all of the music you hear is stored and played. The deduplication alone made the music 22 % smaller (25.4 MB of 22 kHz renders down to 19.8 MB), with no loss of quality at all, since every repeat plays the same samples.
• The rule that its quality is never traded away, and his push to pack it further anyway. He asked whether the music could be compressed without lowering its sample rate and without slowing even a 68020, and kept at it until it was done. Claude measured the options; the lossy ones were audibly worse and were rejected under his rule, and the lossless one (build 75) made the music files 42 % smaller again (9.9 MB to 5.8 MB), for about 0.2 ms of decoding a frame on a 68060.
• Between them his two ideas make the music about 2.2 times smaller than it would otherwise be, which is a large part of why Sonic 060 can run with 8 MB of fast RAM at all. (The third big saving, storing the music in mono since the game always played it that way, was Claude's.) The splitting into bars, the matching of repeats and the packing method are Claude's work; the ideas, the push and the rule are his.
• The F5 rewind (18 September), which he asked for and supplied the kit for; then his rules for it: A silent start-up check so it never breaks a machine short of RAM, a faster rewind, the deck sound stopping when the history runs out, and the music rewinding with the game.
• A graceful way back to Workbench when the game crashes (11 September): The crash guard, the first debugging instrument of the project, and the ancestor of the readable sonic.crash file.
• The disclaimer's words: "Sonic 060 is an unofficial fan made port. It may contain bugs not present in the original game." He then designed its screen himself in a separate Claude session: Its own screen at first start-up only, the level-select font, no mixed fonts, his line breaks, and SONIC TEAM PRESENTS back at its original length.
• The 288-pixel window stays 288 (15 September), and an ending scene takes whatever background its zone has (21 September).
• Never fewer scattered rings, on any machine (22 September): "The number of scattered rings must always remain true to Sonic's design regardless of what machine we are running on." It held through every build.
• Remove Star Light's foreground pylons (27 September), and every byte of their graphics, when they proved to cost frame rate. Star Light has run at full speed since.
• Refuse politely on the wrong machine, and say what it needs (27 September). The refusal was Claude's proposal; adding the chip and fast RAM requirements to the message was his.

Size and memory

• Question every stored byte (22 September): Whether background graphics that never show should be stored at all, and whether every graphic really needs a pre-flipped copy. The work that followed took the level files from 11.8 MB to 5.1 MB.
• The 4 MB machine as a goal (22 September), and one to-do list for everything that would get there. It drove four builds of savings, but the goal was not reached: The music alone needs about 1.9 MB, and Sonic 060 needs about 5.5 MB of free fast RAM.
• The loader audit (23 September): "Go through every loader and check what else it throws away." It found 768 KB of picture data that was stored but never read. (The music's own saving just before it was Claude's find, not his.)
• Remove the memory check (23 September), which gave back about 5 % of every frame.

Testing and method (every one of these found real faults)

• The Tab test tour (16 September): Number the places a build needs testing, and let Tab teleport him from one to the next. It became the backbone of every test after it, and every test sheet since lists its tests by spot number.
• Every build logs itself (16 September), and later numbered log files matched to their run files automatically (22 September), so no result is ever lost or mislabelled.
• Think in bug categories (14 September), and every fix names its category and is scanned for across every zone (17 September). The project's list now holds 117 categories, each with the rule that prevents it and the scan that looked for it elsewhere.
• A test program instead of more guessing (15 September): After eight builds of wrong fixes to a background seam, he proposed a ruler program to read the screen's edge directly. Its three photos settled the question in one round.
• Re-evaluate how builds are checked (15 September), after emulator screenshots had missed two large graphical errors. The project's checking method (two emulators, and automatic colour checks) dates from that challenge.
• The ring-loss Sandbox (22 September): A fully scripted program, needing no keypresses, that plays the heaviest scenes and writes a results file. He then asked that it measure his machine so a model of his hardware could be built from it. Both were built; the Sandbox's first result halved the cost of three of the slowest scenes.
• Run the tests on the 68030 and 68040 too, and describe work for the whole CPU range as "030-060", never as "060" (22 September).
• Capture every frame after a death and a restart (27 September): The capture found three faults that had been in every build since the start.
• Scan every zone after each fix (27 September): The scan after the Scrap Brain 2 floor fix found a hang nobody had reported.
• Compare builds pixel for pixel (22 September) as the regression check.
• A second opinion on the speed work (23 September): When a week of speed work had stalled, he set up a second Claude session to re-examine all of it. It found that one "shipped" optimisation had never been switched on, and delivered the builds that made the big ring losses, in his words, "BEAUTIFULLY smooth".

The background chooser

• Choose the background per band, not per zone (15 September), recorded at the time as "HIS idea and it is the best result of the session". Also his: Striking candidates off a band's list, a numbered guide for every background, a chooser documented and made extendable for later ports, and palette cycling shown in the chooser (he guessed correctly why Green Hill's water looked still).

11.4 Decisions he made on Claude's proposals

These ideas were Claude's; the choice was his. That is a real contribution, but a different one.

• The music, chosen by ear (13 September): Mono, deduplicated, 22 kHz, after a listening test of every variant; and the speed shoes playing the same music pitched up, instead of the Mega Drive's tempo change, chosen from previews.
• PAL on every machine (16 September); the rewind's design (18 September); the music tracks loaded only where they can play (23 September); the underwater background colours (27 September).
• Everything he turned down, which shaped the game as much: A debug mode, a second fire button for pause, Mega Drive-style fades ("way too much work"), ECS and OCS support, further speed work once it was good enough, a Labyrinth water ripple the American cartridge never had, and the asset audit once the savings proved small.

11.5 His testing, and his bug reports

• About 84 test builds reached his Amiga, from the first playable Green Hill on 11 September to build 85 on 29 September; about 64 have recorded results from him, and most of the rest were replaced within hours. He also ran the six diagnostic programs, the Sandbox and the chooser. He usually tested a build within 10 to 30 minutes of receiving it.
• About 150 bug reports, each from his own play on his own machine. About 115 were real faults, and were fixed. About 10 were not reproduced; about 8 turned out to be the original game's own behaviour or level art; about 9 were faults in tools rather than in the game.
• His Amiga disagreed with the emulator at least 30 times, and he was right every time. The project adopted it as a rule: "When he reports a hardware symptom the emulator does not show, he has been right every time." Examples: The Special Stage running at a third of its speed while the log said it was fine; a physics fault that made Sonic speed up and slow down, which two AI models had explained away as an emulator quirk; the Marble 1 pillar room, slow on his board although the emulator's model said it was not; a HUD that blinked on his machine and never in emulation.
• Faults that had been in every build, found only because he looked closely: There was no fade after a death; Sonic's body showed below the title banner for a frame or two; half the waterfall's ring sounds had been silent since build 37; the Scrap Brain chimney burned permanently.
• He corrected Claude's reading of his own evidence more than once: The background showing through Sonic in a photo Claude called normal; water that Claude said was not animated on the Mega Drive (it is, by palette cycling); a swing lurch Claude said was not in the game (his log proved it was); a test sheet that asked him again for results he had already given.

11.6 Other Claude sessions he ran

Besides the main development thread he started and steered several other Claude sessions, and carried their results between them by hand: The second-opinion speed review (builds 65 to 68), the session in which he designed the disclaimer screen, the credits sessions, a review of the project's estimates, and the background chooser thread, in which, over two weeks, he chose every one of the game's ten backgrounds, band by band, finishing on the day of this release.

11.7 His time (estimates)

The records hold no timesheet, so these are estimates from the times of his messages, his uploads and his test runs:

• 10 to 21 September: About 55 hours of hands-on time (plausibly 45 to 70), including two days of 11 to 13 hours.
• 22 to 29 September: About 30 to 38 hours, over six active days.
• In all, roughly 85 to 110 hours in nineteen days: Testing, filming and photographing, writing reports, choosing backgrounds, deciding, and directing up to three Claude sessions at once.

His Amiga test sessions alone (copying each build to a CF card, playing the listed spots, filming, collecting logs and writing the report) account for about half of that.

12. Claude's part, stated plainly

Every line of code in Sonic 060 was written by Claude, Anthropic's AI model (several versions of it over the project; on some days two or three Claude sessions worked side by side). That covers the 68000 game code, the renderer and sound code, the Python asset converters, the music renderer and packer, the diagnostic programs, the test tools, and every analysis document. Every one of the project's 334 commits was made by Claude.

What Claude copied from other people: the Nuked-OPN2 files (section 7), verbatim, and the 159 disassembly files (section 6). That is the complete list of copied source code.

What Claude derived from other people's published ideas: everything in 2.1 to 2.3 and 3.1. These are re-implementations from public descriptions, not copies, but they are not independent inventions either, and claiming otherwise would be dishonest. The architecture came from watching reassembler explain it.

How their material was obtained: section 5 sets it out in full: About 4,000 frames of their videos, all of reassembler's Patreon posts and their images, and the Aonic demo's layout, never its code.

Where Claude was wrong, because reassembler's warning about AI and assembly deserves an honest answer: Claude shipped regressions that its own emulator checks should have caught; it more than once dismissed a symptom Afrotechmods reported that later proved real (11.5); it once claimed an optimisation had shipped when it had never been switched on; and it sometimes asked him for results he had already given. Nearly all of these were caught by his testing.

13. About this document, and corrections

Earlier versions (1.0 on 16 September, 2.0 to 2.2 on 20 and 26 September) were written for the project and for an email to reassembler and RetroRic. Version 3.0 is the public edition. It adds section 11, updates the counts (the disassembly files, the commits, the backgrounds), adds section 5 (how their material was studied), drops the project's internal file paths, and leaves out the conversation transcript that earlier versions carried, because that was written for two named readers.

Section 11 was compiled by Claude from the project's records at Afrotechmods' request, with the instruction to credit him "only when due" and to be transparent. The records were read in full for the purpose; where they disagreed with each other (some dates in the development log were an hour or a day out), the commit history was trusted.

If anything here is wrong, under-credited, or credited to the wrong person, say so and it will be fixed. If reassembler or RetroRic would prefer any idea not be used, or credited differently, that will be done too, without argument.

Contact: Afrotechmods, afro afrotechmods.com (put the @ back in yourself).

Sonic The Hedgehog is a trademark of SEGA. Sonic 060 is an unofficial fan project, not affiliated with or endorsed by SEGA, reassembler, RetroRic or Sonic Retro. No money is taken for it and no ROM is distributed with it.

Credits version 3.2, 2026-09-30. Written for Sonic 060 1.00a.