← Back to all articles

When AI Meets the ZX Spectrum: And Suddenly 48K Looks Rather Large

20 August 2026

MemoirAIZ80

I recently decided to see whether modern artificial intelligence could do something that seemed, on the face of it, rather simple.

Armed with $100 of promotional usage credits, I set Claude Code to use the new Fable model, and put it to work. I instructed Claude to “Write a game for a ZX Spectrum.” After all, today’s AI can write Python, JavaScript, C++, PowerShell and probably a reasonable approximation of the Magna Carta if you ask nicely. So surely a little game for a 48K ZX Spectrum should be a doddle?

Apparently not.

I gave Claude Code the job and, to put it politely, it struggled. To put it less politely, it fell into the ZX Spectrum equivalent of a skip and came out wearing somebody else’s trousers.

And I think I now understand why.

The ZX Spectrum was not really a computer

Well, obviously it was.

But it was a computer designed at a time when engineers were apparently paid by the penny they could save on components. The 48K Spectrum has a Z80 processor running at roughly 3.5MHz, 16K of ROM and 48K of RAM. That sounds wonderfully straightforward. Until you discover that the screen lives inside that RAM.

The screen occupies $4000 onwards, with 6,144 bytes for the pixels and another 768 bytes for the colour attributes. And the pixels aren’t even stored in a sensible order. You might reasonably expect the first line of the screen to be followed by the second line, followed by the third.

No.

That would apparently have been far too easy. The Spectrum stores the screen in three sections, with the pixel rows interleaved in a way that makes perfect sense if you understand the hardware design, but looks like somebody dropped the memory map down the stairs if you’re trying to write a game.

So when your AI says:

“I’ll just draw the sprite at X=73, Y=42.”

the Spectrum replies:

“No you won’t.”

Then the ULA gets involved

The Spectrum’s ULA is responsible for producing the display. Unfortunately, it also wants access to the same RAM that your game is using. And the ULA gets priority.

When the display is being generated, accesses to the contended memory area can actually cause the Z80 to be stopped for several T-states. Think about that for a moment. Imagine writing a game on a modern PC and discovering that occasionally, when you try to access a particular block of RAM, the computer says: “Hang on, I’m watching telly.” That’s essentially what is happening.

And if you’re writing code where timing matters, this becomes extremely important. A 48K Spectrum frame is 69,888 T-states, producing an interrupt at about 50.08Hz. Individual screen lines are precisely timed, and even changing the border involves understanding exactly when an instruction completes relative to the ULA’s display activity.

Modern programmers generally don’t have to think like this. Neither, apparently, does Claude.

The problem with AI is that the code can look right

And this is where it gets really interesting.

An AI can quite happily produce perfectly respectable-looking Z80 assembly. It can use registers. It can write loops. It can calculate addresses. It can create routines called things like:

DRAW_PLAYER
MOVE_ENEMY
CHECK_COLLISION

This all looks very encouraging.

Unfortunately, on an old computer, looking like code isn’t the same thing as being code that works. The Spectrum has quirks everywhere. The keyboard is accessed through the ULA. The beeper is driven through an I/O port. I/O itself can be subject to contention. Memory access can affect timing. The screen layout is peculiar. And if you get sufficiently clever, you can start deliberately using these hardware quirks to produce effects that depend on individual CPU cycles.

At which point you aren’t really writing software anymore. You’re negotiating with a 40-year-old television.

The 48K paradox

And this is perhaps the funniest thing about the whole exercise.

The game I wanted to make isn’t particularly complicated. It’s a tiny 8-bit game.

There are no 3D models. No physics engine. No shaders. No AI opponents requiring a neural network. No multiplayer server. No texture streaming. No bloody microtransactions.

Just a bloke moving around a screen shooting things.

And yet getting that little bloke to move correctly can require understanding more about the machine than getting a modern character moving around Unity. Because modern computers hide the hardware. The Spectrum makes you deal with it.

Perhaps this is where AI has got the wrong idea

Modern AI has been trained on an enormous amount of modern programming. Modern programming tends to be about abstraction. We tell the computer what we want and increasingly let somebody else’s software work out how to make it happen.

The ZX Spectrum is the exact opposite.

You don’t tell the Spectrum: “Draw a sprite.” You tell it: “Put these particular bits into these particular bytes, which happen to be arranged in this rather peculiar order, while trying not to upset the ULA.”

You don’t tell it: “Play a sound.” You tell it which bits to send to an I/O port and when.

And you don’t tell it: “Run at 50 frames per second.” You count bloody T-states.

So perhaps Claude didn’t actually fail

I’ve been laughing at Claude for spectacularly failing to write a Spectrum game.

But perhaps I’ve been unfair.

Maybe the problem isn’t that AI is bad at old computers. Maybe it’s that we’ve spent the last 40 years teaching programmers to forget how computers actually work.

Give an AI a REST API, a database and a web framework and it is perfectly happy. Give it a Z80, a ULA and 48K of RAM and suddenly it looks like you’ve handed it a Sinclair service manual written in Klingon.

And I rather like that.

Because the ZX Spectrum was never supposed to be easy. It was supposed to be cheap. It was supposed to be clever. And it was supposed to make you understand that every byte mattered.

Perhaps that’s why writing a Spectrum game in 2026 is proving surprisingly difficult. We’ve spent decades making computers easier to program. The ZX Spectrum is sitting there, quietly reminding us that underneath all those lovely abstractions there is still a processor somewhere doing exactly what you told it to do.

Even if what you told it to do was completely bloody wrong.

The ones that did work

For all of the above, this hasn’t been a total washout — some earlier AI-assisted attempts did make it across the finish line, tested headlessly and played start to finish rather than just eyeballed in an emulator. If you want proof it’s possible, see Gig Rush, a complete original arcade game about dodging traffic on a bike, and Raiders of the Lost Aisle and its sequel, Raiders of the Lost Aisle II, both isometric games with full downloadable source. Whatever went wrong this time, it clearly isn’t a law of nature.

More like this

It’s a fair swap, not!

A borrowed copy of Dynamite Dan, a copy-protection scheme that beat "The Key", and a brother who traded it away for Engineer Humpty on the strength of the cover alone.

Raiders of the Lost Aisle II

A second, independently-built take on the same premise: a bargain hunter, a security guard called Big Dave, and a legendary discount tin sealed away in Aisle 13. Same isometric-engine idea as the original, a different story, and its own fresh set of bugs a screenshot caught that the test suite alone never would have.