Key points
A fight from Street Fighter II' Champion Edition runs on a stock Amiga 1200 (68020 at 14 MHz, 2 MB of memory, no expansion), identical to the arcade machine down to the pixel: 384 × 224 pixels, 182 colours. In 1992, this was the game the Amiga could not do. Today it runs at 16.7 frames per second, and practically at arcade speed (99.6%) when one arcade frame in four is shown. Add 1 MB of Fast RAM and the same 14 MHz 68020 reaches 19.9 frames per second, the speed of the arcade fight. This is not nostalgia, it is a case study: AI does not replace the machine, it finally makes it possible to use every cycle of it.
Why AI changes the game
Optimising an Amiga used to be months of work for a handful of demoscene experts. What has changed is the cost of an idea: trying it, measuring it and checking it now takes a few minutes.
- Reading the arcade machine. The game data is extracted from the arcade ROM with the MAME emulator, frame by frame, instead of being redrawn by hand.
- Writing the assembly. The engine is written in 68020 assembly, about 1,200 lines, with no compiler. Every idea is written, measured, then kept or thrown away.
- Checking everything. Every version is replayed in a 68020 processor emulator and all 639 frames are compared with the arcade. One wrong pixel and the version is rejected.
- Cross-checking. Several AIs review the same code. One suggested driving the conversion from the list of areas to redraw; another searched GitHub and found the thirty-year-old techniques of Mikael Kalms and of the game Gloom.
The human stays in charge: setting the rule (not one pixel of difference), judging by eye and choosing between smoothness and fidelity.
The challenge: an arcade board against a home computer
Capcom's CPS-1 board is not much faster than an Amiga 1200. Its strength lies elsewhere: dedicated chips draw the background and the characters on every frame, without the processor's help.
| CPS-1 arcade board (1992) | Stock Amiga 1200 (1992) | |
|---|---|---|
| Processor | 68000 at 10 MHz | 68EC020 at 14 MHz |
| Screen | 384 × 224, 59.6 frames/s | 384 × 224 in PAL, 50 frames/s |
| Colours in this fight | 182 | 256 at most, in 8 bitplanes |
| Background | 3 layers drawn by the hardware, scrolled line by line | recomputed by the processor, pixel by pixel |
| Characters | many hardware sprites | 8 narrow hardware sprites, unusable here |
| Memory | dedicated graphics memory | 2 MB shared by everything |
What was tried before
The Amiga versions and demos we found all redrew or simplified the game.
- U.S. Gold, 1995, Super Street Fighter II. Two versions, one for the A1200, with better colours and music and sound effects together. Graphics and backgrounds were redrawn (RQ87).
- Dennis Ramberg and Titan, 2021. A graphics engine showing what an arcade conversion "could have been" on the A1200, presented on video (Indie Retro News).
- NeesoGames, 2022. A playable demo for OCS/ECS Amigas using the Super Nintendo graphics, 256 pixels wide, in EHB mode. We ran it: smoother, but clearly less faithful (itch.io).
Our approach is different: redraw nothing, and prove that every frame shown is the arcade's.
The method: extract, don't redraw
We start from the Street Fighter II' Champion Edition ROM (World revision 920513) and the fight from the attract mode: Ken against Guile, 1,917 arcade frames.
- MAME records the arcade machine. On every frame, the graphics memory and video registers are read back, without changing anything.
- An independent renderer recomputes every frame and matches MAME's.
- The Amiga program is checked in a 68020 emulator, with an emulated Blitter that only finishes its copies at the last possible moment, so the slightest timing error would show. Every frame is compared with the arcade, pixel by pixel.
- WinUAE in cycle-exact mode runs the program on a stock A1200 and measures the speed.
This is a replay: positions and animations come from the arcade machine. There are no controls and no fighting AI yet. This demand for fidelity rules out the usual shortcuts, and makes every frame per second much harder to win.
First wall: one memory for everything
On an A1200 with no expansion, a memory access costs about 10 processor cycles. And everything goes through this Chip memory: the program, the data, the frame being computed, the screens, the Blitter and the display itself. The 68020's cache holds only 256 bytes, and only for instructions. Speed therefore depends not on the number of calculations but on the number of memory accesses: optimising means avoiding them.
Second wall: from pixels to bitplanes
The arcade machine stores one pixel per byte. The Amiga splits the picture into 8 bitplanes: every pixel is scattered across 8 places in memory. You have to draw in pixels, then convert everything, what demo coders call C2P ("chunky to planar"). Our conversion works on blocks of 16 pixels in a single pass that fits in the cache: 4 reads, 10 merge operations and 8 writes per block, with the writes interleaved between the calculations as Mikael Kalms did.
Third wall: the floor in perspective
The floor of Guile's stage scrolls at a different speed on every line. The arcade machine does it for free. On the Amiga, line-by-line hardware scrolling leaves only 8 pixels of margin at 384 pixels wide: we tested it, then gave it up. So the Blitter copies the previous frame line by line, with the right offset, and the processor only redraws the blocks that still differ.
What paid off
Every gain comes from the same idea: fewer Chip memory accesses. The areas to redraw are computed in advance by comparing the arcade frames. The biggest gain came from a hidden cost: the Blitter copied the whole screen on every frame and held the bus while the processor worked. With three screens, the one being redrawn already holds the frame from three steps earlier: for each line, the choice between keeping it and copying it is computed in advance.
Several attractive ideas were measured and then dropped: keeping a background without characters (slower), skipping the background hidden behind the characters (too much memory), starting a frame's copies during its own conversion (slower: the conversion had to wait for the copies).
Fourth wall: the Blitter and the processor fight over the bus
One measurement made everything clear. Without the Blitter copies (wrong picture, timing only), the processor finishes its work in 786 screen lines per frame. With them, it needs 990. The Blitter copies 146 screen lines per frame and holds the bus for about 310 lines: whenever it takes the memory, the 68020 waits. Giving it absolute priority is worse (1,081 lines), because the processor then stalls.
The fix: make the Blitter work while the processor is computing rather than reading and writing. The bitplane conversion is the most computational phase. So the next frame's copies are started during it, in 32-line slices, each one only once the conversion has finished its source lines. The gain is real but limited: the bus is saturated, and every cycle given back to the composition is partly taken from the conversion. Preparing the copy queue offline and speeding up the copying of the animated background tiles won 24 more lines. Result: 947 lines per frame, 16.5 frames per second, and one arcade frame in four at 99.6% of the arcade speed.
The checker was hardened so that this speed-up costs no pixel. In the 68020 emulator, a Blitter copy only finishes when the program asks for its status, and any write to its source or destination before it ends stops the test. Deliberately removing the line barrier triggers the stop immediately.
What did not work, measurements in hand: splitting the copies to skip the redrawn areas (953 lines: more copies to prepare than memory saved); switching to 7 bitplanes (the fight exceeds 128 colours, with up to 97 on a single line); recalibrating the choice between keeping and copying a line (no effect).
Another idea tested: no longer drawing the background hidden under the fighters. 45% of the background pixels recomposed on every frame end up under a sprite, and a quarter fall in 16-pixel blocks that are completely covered. A version that skips those blocks was written and checked: exact on all 639 frames. Yet it is slower, 985 lines per frame against 947. Copying a background pixel costs only a few cycles; what weighs is the fixed work of each of the roughly 265 line pieces composed per frame. Skipping 2,400 pixels saves about 7 lines, while the checks added to skip them cost about 45. Dropped, but it points at the real target: that fixed cost per piece.
An instruction-by-instruction profile found it. For each line piece, drawing the foreground scanned the line's segment list from the start again: over the first 64 frames, 1,627 segments examined per frame on average, 1,123 of which lay entirely before the piece. Now the next piece resumes where the previous one stopped. This pass drops from 98 to 78 lines, and the engine to 933 lines per frame: 16.7 frames per second, still exact on all 639 frames. The same resumption applied to the main background was slower: its loop no longer fitted in the 68020's 256-byte instruction cache. Looking up the pieces of identical lines only once was slower too: without Fast RAM, reading memory again costs more than recomputing in registers.
Is a faster processor the answer? The same program ran in WinUAE, in cycle-exact mode, with a 68020 pushed from 14 to 57 MHz, still with 2 MB of Chip memory and no Fast RAM. The gain fades quickly: quadrupling the clock only brings 16%. The processor spends most of its time waiting for Chip memory, which does not get any faster. No clock speed reaches arcade speed without Fast RAM.
Fast RAM, on the other hand, is enough: with 1 MB of Fast RAM added to a stock A1200, the same 14 MHz 68020 shows Ken against Guile at 19.9 frames per second, the speed of the arcade. The program is split in two: the code, the backgrounds, the sprite pieces and the frame being composed go into Fast RAM, where the processor shares the bus with nobody; the screens and the precomputed lists stay in Chip memory. Blanka's stage, which is heavier, rises to 16.5 frames per second (83%) with 1 MB and 17.3 (87%) with 2 MB. Back then, a Fast RAM expansion for the A1200's trapdoor was the most common upgrade, and they are still made today.
| 68020 without Fast RAM | Ken vs Guile | Ken vs Blanka |
|---|---|---|
| 14.2 MHz (stock A1200) | 16.7 frames/s (84%) | 12.8 frames/s (64%) |
| 21.3 MHz | 17.8 (89%) | 13.7 (69%) |
| 28.4 MHz | 18.4 (93%) | 14.3 (72%) |
| 35.5 MHz | 18.9 (95%) | 14.7 (74%) |
| 42.6 MHz | 19.1 (96%) | 15.0 (75%) |
| 56.8 MHz | 19.4 (98%) | 15.2 (76%) |
One arcade frame in three shown; percentage = fight speed compared with the arcade. WinUAE cycle-exact measurements, 25 October 2026, complete fight loop.
Second stage: Ken vs Blanka
Blanka's stage does not appear in any of the nine fights of the arcade attract mode. The arcade program, disassembled with Ghidra, revealed the variables for the stage and the characters. In MAME, in RAM only, the attract-mode fight Ken vs Guile is moved to Blanka's stage, with Blanka instead of Guile. The arcade program then builds the background itself, and Blanka replays Guile's recorded inputs. The ROM is not modified.
The same engine shows this fight at 12.75 frames per second on a stock A1200, 64% of the real speed. All 457 frames shown are identical to the arcade in the 68020 emulator, and the WinUAE screen captures match the arcade machine. The background is harder than Guile's. At the top of the screen, the tree and the hut scroll in front of the river at a different speed, and the plank floor shifts strongly from one line to the next. A single shifted copy is no longer enough: the processor redraws 1,346 blocks per frame, against 888 for Guile.
Idea tested: copying each layer with its own offset, through a mask, with the Blitter. The blocks to redraw fall by 21% and the picture stays exact, but the fight slows down: 1,601 screen lines per frame against 1,225. This three-source copy makes four memory accesses per word instead of two. It takes more bus time from the processor than it saves. Dropped.
Where we are
On a stock A1200, the fight runs at 16.7 frames per second showing one arcade frame in three, 84% of the real speed. Showing fewer arcade frames, each one still exact, catches up with real time: one in four is almost enough (99.6%).
| Machine and setting | Frames/s | Fight speed |
|---|---|---|
| Stock A1200, 1 frame in 3 | 16.7 | 84% |
| Stock A1200, 1 frame in 4 | 14.8 | 99.6% |
| Stock A1200, 1 frame in 5 | 12 | 100% |
| Stock A1200 + 1 MB Fast RAM, 1 frame in 3 | 19.9 | 100% |
| A1200 + 50 MHz 68030 card and Fast RAM, 1 frame in 3 | 19.9 | 100% |
The "1 in 5" and "68030" rows were measured on an earlier version of the engine (15.5 frames/s at 1 in 3); the video was filmed with the 15.8 frames/s version. Every frame shown is checked identical to the arcade in the 68020 emulator.
The last rows answer an old question: with a memory expansion of the time, the A1200 could have shown arcade Street Fighter II at full speed. It did not lack power, it lacked the method. This article is updated with every new measurement.
Your turn: an idea to win frames?
Have you programmed the Amiga, written demos, C2P routines, AGA engines? The challenge is open: win frames per second on a stock A1200 without changing a single pixel. The constraints: 68020 at 14 MHz, 2 MB of Chip memory with no Fast RAM, 384 × 224 in 8 bitplanes, 182 colours. Every idea published will be measured, and we will reply here with the result.
Ideas received
No idea published yet. Be the first.
Frequently asked questions
Is the game playable on the Amiga 1200?
Not yet. It is a replay: positions and animations come from the arcade machine, recorded in the MAME emulator. The display is finished and checked frame by frame; controls, collisions and the AI are still to be done.
Can this Amiga version be downloaded?
No. The game's graphics and data belong to Capcom: we show the technique and the measurements, we distribute neither the ROM nor the executable that contains its data.
Why doesn't the stock Amiga 1200 reach 20 frames per second?
Because, without Fast RAM, the processor, the Blitter and the display share the same Chip memory, and every access costs about ten cycles. Pushing the 68020 to 57 MHz without Fast RAM only gives 19.4 frames per second, while 1 MB of Fast RAM is enough for 19.9. With a 50 MHz 68030 card and Fast RAM, the same program reaches 20 frames per second and the real speed of the arcade.
What did AI bring to this project?
The cost of an idea: every optimisation is written in 68020 assembly, replayed over the 639 frames and timed in a cycle-exact emulator in a few minutes. Several AIs reviewed the code and found thirty-year-old demo techniques; the rule (not one pixel of difference) and the judgement stay human.
Sources: MAME's CPS-1 driver and its video renderer · WinUAE · chunky to planar conversion, Mikael Kalms · RQ87, Amiga versions of Super Street Fighter II · NeesoGames. Measurements: OutilsIA, 24 and 25 October 2026, WinUAE 6.0.3 cycle-exact, free AROS ROM. Street Fighter II is a trademark of Capcom; Amiga is a trademark of its current owners. OutilsIA is not affiliated with any of these companies.