The Amiga CD32 gets the games it needed — starting in September 1993.
We are building games today for the unmodified 1993 console: a 14 MHz 68EC020, AGA, 2 MB of Chip RAM and no Fast RAM. Each game is benchmarked in a cycle-accurate emulator using the original ROM. Here we show the progress, review each game as rigorously as a magazine would have back then, and estimate how it might have changed the console’s fortunes.
Real history on the left, our imagined release schedule on the right. The dates on the right are fictional and part of this thought experiment.
All images are taken from development builds. All frame rates are measured results from the repositories, not performance targets.
How many additional consoles might each game have sold? The bars show ranges in thousands of units, estimated from genre, review score and release date. None of these figures can be verified.
additional units compared with approximately 100,000 actually sold. The ranges overlap: someone who buys the console for RumbleX does not buy it a second time for the racing game.
Even the upper estimate would not have saved Commodore. The company was crippled by debt and supply problems. A patent dispute prevented a US launch. Better games could have raised demand, but not the ability to supply consoles.
A mascot platformer and a fighting game at launch. Those genres sold consoles in 1993 and 1994, yet the CD32 lacked exclusive games in either category.
The single biggest omission was Fast RAM. On the CD32, program code, data and graphics all live in Chip RAM. The CPU shares the memory bus with bitplanes, Copper, Blitter and audio, leaving it waiting much of the time with eight bitplanes. The Mascot project measured an effective performance of only around 1 to 1.5 MIPS.
| Game | Measured today | Chip-bus share | With Fast RAM | Outcome |
|---|
How the model works: the part of each frame tied to the Chip RAM bus (chunky-to-planar conversion, Blitter, Copper lists and bitplane writes) keeps its original speed. Everything else speeds up by the selected factor. A factor of two is a rule of thumb from comparing an A1200 with and without a RAM expansion. Chip-bus shares come from project profiling and are estimates for Zombies, RumbleX and Mascot. Only the “measured today” column contains direct measurements.
Just 1–2 MB could have roughly doubled the processing capacity available for game logic and 3D, while freeing Chip RAM for graphics. In 1993, RAM cost roughly $25–40 per MB at wholesale prices. That would have mattered for a £299 console, but offered the best return on cost.
Project evidence: Duke Nukem only fits its textures because the original ROM leaves 1.62 MB of Chip RAM free. Every kilobyte of code and texture sits on the slow bus.
The chunky-to-planar hardware makes a measurable difference: Zombies in a Train reaches 12 fps instead of 7 with Akiko, and Ares Racing League needs 10.3 rather than 16.4 vertical blanks per frame. Conversion still takes 13–14% of each frame because the CPU must push every pixel through a register. A genuine chunky graphics mode would have eliminated the step altogether.
Measurements: the Zombies and Ares Racing League READMEs, plus Duke Nukem’s PERFORMANCE.md.
The 68EC020 has just 256 bytes of instruction cache and no data cache. A 25 MHz 68030 with Fast RAM could have delivered roughly three to four times the performance, but was too expensive for a £299 console in 1993. Fast RAM would have been the realistic first step; the CPU, second.
Estimate, not a measurement.
The NVRAM provides just 1 KB for all the console’s save files. That is why Zombies in a Train squeezes a save into 128 bytes. There is no room for an RPG or a racing league with detailed statistics. A memory-card slot could have fixed it.
Source: Zombies in a Train README.
A program booted from CD gets only 4 KB of stack. Duke Nukem’s portal renderer needs 7.5 KB and crashed in three of six levels until it was given a separate stack. There is also the CD32.TM trademark file, without which a CD will not boot. Both constraints cost developers time.
Evidence: Duke Nukem’s PERFORMANCE.md and boot tests across all projects.
The seven-button controller works for four-button fighters and for a first-person shooter with aim assist. CD audio barely reduces CPU load (1–2%), but sounds far better than four Paula channels. Copper and Blitter do the heavy lifting in RumbleX and the platformer: games designed for the hardware can reach 25–37 fps.
Measurements: the RumbleX and Ares Racing League READMEs.
Find out more about each project on Patreon: development reports, benchmarks, and access to alpha and beta builds for CD32, A1200 and emulators.
patreon.com/arescomputerInformation pursuant to Section 5 of the German Digital Services Act (DDG)
Ares ComputerEmail: [email protected]
This website does not set analytics, advertising or marketing cookies. We do not track visitors or store information in your browser when you visit the site. No cookie consent is therefore required for viewing this page.
The hosting provider may process technically necessary connection data (such as your IP address, access time and requested file) in server logs. The details depend on the hosting provider actually used and must be completed before publication.
Images and fonts are loaded without connecting to third-party services. If you follow an external link (such as Patreon), that provider’s privacy and cookie policies apply.
For privacy questions, contact the controller named in the legal notice at [email protected]. Hosting provider details still need to be added before publication.