
A Commodore 64 was left running for three and a half days and ended up cracking an Enigma message in German. That alone is a great story. What makes it better is that it did it without knowing any of the plaintext in advance. No handy opening phrase, no lucky hint, no shortcut. Just a long search through millions of possible settings until the right answer turned up. The scale of the job is what makes it so striking. Over the run, the machine executed 87 billion instructions, burned through 303 billion clock cycles, and tested 5.9 million candidate settings. Those are ridiculous figures for a C64, which is exactly why they land so well. This is a machine people usually associate with games, demos, and 8-bit nostalgia, not serious codebreaking work. Yet here it is, taking on one of the most famous cipher systems in history and getting the result.
Why the result matters
The important detail is not just that the message was cracked, but how it was cracked. Enigma stories usually bring up the idea of a crib — a likely word or phrase that gives you a way in. Here, there was no known plaintext at all. The program had to search, score, reject bad candidates, and keep going until something plausible emerged from the noise. That changes the feel of the whole thing. It is no longer just a fun re-run of a solved puzzle with extra hardware drama added on top. It becomes a real computational task, and one that suits an old machine surprisingly well. The C64 is not fast, but it is perfectly capable of doing repetitive, structured work if the code is efficient and the programmer is patient enough to let it run. This is also what makes the numbers meaningful. Three and a half days sounds extreme, but that runtime is the point. On a modern machine, the same task would lose most of its character because the result would come too quickly. On a Commodore 64, the search feels heavy. You can measure the effort in days rather than seconds, and that gives the achievement much more presence.
How much work did the C64 really do?
Quite a lot, obviously, but the raw figures are worth sitting with for a moment because they explain why this is more than just a novelty. An 84-hour run on a roughly 1 MHz machine means the computer spent days doing nothing but pushing through candidate settings, comparing outcomes, and keeping the search alive. That is exactly the kind of job older systems make visible in a way modern ones rarely do. The figure of 5.9 million candidate settings tested is especially useful because it gives the whole effort shape. This was not one clever guess that happened to work. It was a large, systematic search. Likewise, the 303 billion clock cycles tell you just how much time the machine spent grinding away at the problem. The C64 got there not by brute strength, but by sheer persistence combined with software that was lean enough to keep the process practical. That is really the appeal of the whole thing. It shows what happens when a limited machine is given a serious, well-defined task and enough time to finish it.
So what would an Amiga 500 do?
The obvious follow-up is to ask what would happen if the same challenge were handed to an Amiga 500 instead. At first glance, the answer looks simple enough. A PAL Commodore 64 runs at about 0.985 MHz, while a PAL Amiga 500 runs its Motorola 68000 at roughly 7.09 MHz. On paper, that gives the Amiga a little over seven times the clock speed. If you apply that ratio directly to the C64’s 84-hour runtime, you land at about 11.7 hours. Rounded off, that gives a clean estimate of around 12 hours for a stock Amiga 500. That is the easiest headline answer, and it matches the cycle-count method too. Take the reported 303 billion clock cycles from the C64 run, divide by the Amiga’s clock rate, and you end up very close to the same result. So the basic estimate is straightforward enough: if the Commodore 64 needed three and a half days, a stock Amiga 500 would probably need about half a day.
Why 12 hours is only a rough answer
The complication, of course, is that different computers do not scale neatly just because their clock speeds do. The C64’s 6510 and the Amiga’s 68000 are very different processors. The 68000 is far more capable, has a much richer instruction set, and can often do more useful work per instruction. That means a well-written Amiga version of the program could do better than the simple MHz comparison suggests. At the same time, the Amiga is not magically efficient in every situation. Memory access patterns matter, and poor use of the machine can waste a lot of the advantage. A lazy port would not necessarily deliver the best possible result just because it is running on better hardware. That is why the safest estimate is a range rather than a single hard number. Twelve hours is the sensible centre point, but something like 8 to 16 hours is probably more realistic depending on how well the code is adapted to the Amiga. A strong 68000 implementation might come in lower. A basic port might drift higher.
What the comparison says
The interesting thing about this comparison is that it makes both machines look good, but for different reasons. The Commodore 64 version is impressive because of the amount of work the machine had to endure. It sounds difficult because it was difficult. The runtime becomes part of the achievement. The Amiga 500 version is impressive for the opposite reason. It takes the same problem and makes it look manageable. That is a neat summary of the two systems in general. The C64 is the machine that earns respect by doing a lot with limited hardware. The Amiga is the machine that makes the same kind of task feel much less strained. Put them side by side here and the difference becomes very clear: one turns Enigma-breaking into a long-haul computation, the other turns it into something you could reasonably leave overnight. Neither outcome is boring. The C64 result is the better story because of the effort involved, but the Amiga estimate is a reminder of just how large the jump was between those two generations of Commodore hardware.
The bottom line
The Commodore 64 result is strong on its own: 84 hours of runtime, 87 billion instructions, 303 billion clock cycles, and 5.9 million tested settings to crack a German Enigma message with no known plaintext. That is already enough to make it one of those perfect retro-computing stories that spreads immediately. The Amiga 500 angle just gives it a useful second act. Based on raw clock speed, a stock machine would likely manage the same job in about 12 hours. In practice, the realistic answer is probably somewhere in the 8 to 16 hour range, depending on how well the code suits the 68000. So the simple version is this: the Commodore 64 proved it could do the job at all, and the Amiga 500 would probably have done it before the day was out.














