Sonic the Hedgehog 2 has been converted for Commodore Amiga AGA hardware in a test release that aims to carry the game from its opening logo through its ending credits. The project, credited to EAB moderator Cody Jarrett, is notable not only for its scope but for how it was made: AI assistance was used to translate the original game logic from 68000 assembly-language disassembly into C, then the resulting behavior was checked against the original code.
The stated feature set is comprehensive. It includes all 11 zones, the special stages, cooperative play with either a second player or computer-controlled Tails, and the 2-Player VS mode. That makes this more than a selective technical demo or a single-level proof of concept. At the same time, it remains explicitly a test release, and compatibility has not been established across every Amiga configuration.
A full-game conversion with a modern development wrinkle
Ports of old console games are often judged by a straightforward question: does the new version preserve the original game’s behavior? This project addresses that question in an unusually direct way. Its development began with s2disasm, a community disassembly of the original game’s 68000 logic. A disassembly is source-like material reconstructed from a compiled program; rather than being the original development source, it represents machine code in a human-readable assembly form.
The original logic was translated into C with help from Claude, Anthropic’s AI system. C is a programming language that can be compiled for different processors and platforms, making it a practical bridge when moving behavior from a console-oriented assembly codebase to an Amiga program. But translating code is not the same thing as proving it is equivalent. A condition checked in a slightly different order, an arithmetic edge case, or timing-sensitive behavior could alter a game even when the broader structure looks right.
To test that risk, the project ran the original and translated code side by side through the Unicorn engine and compared their results for identical behavior. Unicorn is an emulation engine: software capable of executing code for another processor architecture. In this case, its role is verification rather than simply playing the game. The comparison method matters because it focuses on the underlying logic instead of relying only on visual inspection or a handful of playthroughs.
That does not mean every possible issue is ruled out. The release is still being tested, and the supplied compatibility notes ask users to report problems along with their CPU, memory and Kickstart version. Still, the use of side-by-side checks points to a deliberate effort to keep the translated logic aligned with the original implementation.
Why the Amiga version needs far more memory
The hardware transition is not a simple matter of placing a 1 MB console ROM onto an Amiga disk. The port requires 2 MB of Chip RAM and 4 MB of Fast RAM, plus roughly 20 MB of hard-disk space for either its LHA or HDF form. That is substantially more working storage than the original 1 MB ROM, and the reason lies in how the systems handle graphics and sound.
The Mega Drive version uses compressed tiles and hardware-synthesised music. By contrast, this Amiga conversion relies on pre-drawn graphics and sampled audio. Pre-drawn graphics consume memory because visual data must be stored in a directly usable form rather than reconstructed from a more compact tile arrangement. Sampled audio similarly requires sound data to be held and played back, rather than relying on the original console’s music hardware approach.
For this release, 4 MB of Fast RAM is allocated to a 2 MB program and 3.9 MB required for each act. Put simply, an act’s resources must be available in memory while that act is being played. This helps explain why the requirement is expressed as a memory configuration rather than merely as disk capacity.
Chip RAM serves a different job in the Amiga architecture. The stated 2 MB requirement covers the AGA dual-playfield screens, hardware sprites and audio samples. The distinction is practical: Chip RAM is accessible to the Amiga’s custom hardware, while Fast RAM is used to hold the program and the larger act data described for the port. The project depends on both pools rather than treating total memory as one interchangeable number.
What dual playfields, Copper effects and the blitter contribute
The conversion uses AGA dual playfields for its screens. A playfield is a graphics layer; two playfields allow separate visual layers to be displayed. That is a useful fit for a side-scrolling game whose scenery needs foreground and background elements moving at different rates.
It also uses the Amiga’s Copper for per-line background scrolling and water effects. The Copper is a custom co-processor that can perform display-related changes in sync with the screen’s drawing process. “Per-line” here means settings can vary across horizontal display lines, enabling effects that would be difficult to achieve with one static background position. The project specifically identifies scrolling and water as uses for that capability.
Objects are handled with the blitter, another Amiga hardware component designed for graphics operations. The use of the blitter and hardware sprites is part of the port’s attempt to map Sonic 2’s moving visual elements onto Amiga-native display tools, rather than expecting the CPU alone to do every graphics task.
Audio is assigned to Paula, the Amiga sound hardware, with the soundtrack converted into four-channel ProTracker modules. A ProTracker module is a music format built around sequenced samples. Four channels means the music is arranged for four simultaneous audio tracks under this approach. It is a different technical route from the Mega Drive’s original hardware-synthesised score, and it is one of the reasons sampled audio must be part of the memory plan.
Minimum setup and known test boundaries
The stated target machines are AGA-equipped Amigas, specifically the A1200 or A4000, with a 68020 processor or better. Kickstart 3.0 or later is required, with Kickstart 3.1 listed as the tested version. Players also need the previously noted 2 MB Chip RAM, 4 MB Fast RAM and about 20 MB of hard-disk room for the LHA or HDF edition.
- AGA Amiga A1200 or A4000
- 68020 CPU or higher
- Kickstart 3.0 or later; tested with 3.1
- 2 MB Chip RAM
- 4 MB Fast RAM
- Approximately 20 MB of disk space for LHA or HDF files
The release has been played on a real A1200 using a Blizzard 030 accelerator. However, 040 and 060 accelerator cards are untested, as are configurations with less than 4 MB of Fast RAM. Those limitations are important for anyone approaching this as a preservation curiosity or a practical way to play: meeting an approximate model name is not identical to being within the tested configuration.
The request for reports including CPU, memory and Kickstart information is also useful diagnostic guidance. On older systems, differences in accelerator, available RAM and firmware can affect behavior. Reporting the configuration alongside a bug gives the developer a better chance of identifying whether an issue is general or tied to a particular setup.
AI assistance is the discussion, not just the implementation detail
This project arrives amid an active argument over what AI-assisted programming means for retro development. Here, AI was used as part of a workflow built around an existing disassembly, a C translation and logic comparisons. That is distinct from treating generated output as final without checking it. The result still depends on technical decisions about Amiga memory, display hardware, sound conversion, compression and testing.
There is also a clear contrast with reassembler’s forthcoming Amiga port of Sonic the Hedgehog, which is described as purely human-coded. The two projects therefore represent different approaches to adapting Sega’s early Sonic games for Amiga hardware: one foregrounds AI-assisted conversion and validation, while the other is positioned around human-only coding.
Neither approach eliminates the practical questions that matter to players. Does the game cover the intended content? This Sonic 2 release says it does, with zones, special stages, co-op and VS mode accounted for. Does it have a defined hardware target? Yes, though it remains in testing. And does it make visible how the new platform differs from the original? Very much so: its larger memory requirement and use of AGA, Copper, blitter and Paula hardware make the conversion’s design choices unusually clear.
For a broader look at how contemporary tools keep Sega’s 16-bit library in circulation, see Delta 2.0’s Sega Genesis support and RetroAchievements additions. This Amiga project takes a different path: it is not an emulator feature, but a platform-specific conversion built around the limits and strengths of classic Commodore hardware.
For now, the sensible expectation is a promising full-game test build rather than a universally verified release. Owners of the specified AGA hardware can assess it within the stated requirements, while those using untested accelerators or lower Fast RAM should treat compatibility as uncertain. Its lasting significance may be less about settling the AI debate than demonstrating a concrete workflow: translate, validate against the original logic, and then solve the target machine’s very different graphics, audio and memory constraints.
