Back to the 8-bit days, with a little help from AI

I grew up on these machines, so for my latest experiment I decided to combine two things I enjoy: retro computing and AI-assisted coding. The challenge: create fun, playable games that run on real classic 8-bit computers, and see how far an AI pair-programmer can take me.

The target machines fall into two families:

• 6502-based: the Commodore 64 (6510), Commodore Plus/4 and 128 (8501/8502), and the BBC Micro / Master series (6502 / 65C12).
• Z80-based: the Sinclair ZX Spectrum, the Amstrad CPC range, and the Z80 side of the Commodore 128.

Why 8-bit games are such a great exercise

Modern development hides almost everything from you. On an 8-bit machine you are staring at roughly 1-4 MHz, tens of kilobytes of RAM, and hardware that does very specific things. That forces good habits:

• Every byte and every cycle counts. There is no room for waste, so you think hard about data layout and loops.
• Gameplay comes first. You cannot hide a weak idea behind graphics. A tight, fun mechanic is what survives.
• The hardware is the personality. The C64’s sprites and SID chip, the Spectrum’s colour attributes, the BBC’s clean video modes and the CPC’s chunky palettes each push a game towards a different look and feel.

Choosing the kind of game

Some genres suit these machines far better than others. The ideas I’m looking at:

• Single-screen platformers in the spirit of Manic Miner and Chuckie Egg: tile-based, simple collision, and lots of personality.
• Maze and dot-collecting games: easy to make well on every machine in the list.
• Vertical or horizontal shoot-’em-ups: a good test of sprite handling and scrolling tricks.
• Dig-and-fall puzzlers along the lines of Boulder Dash: grid-based, so the logic is very manageable.

Where the AI helps (and where it needs watching)

Assembly language is a fascinating test for an AI assistant. It is well documented, but it is also unforgiving: one wrong addressing mode or a missed carry flag and the whole thing crashes. My plan is to use the AI for:

• Generating routines such as sprite movement, tile map rendering, joystick/keyboard input and simple sound effects.
• Working out tricky maths without a multiply or divide instruction: lookup tables, shifts and fixed-point arithmetic.
• Explaining hardware quirks, such as the Spectrum’s attribute clash or the C64’s raster interrupts.
• Debugging: pasting in a monitor dump or an emulator trace and asking what went wrong.

What I’ll be checking carefully is whether the generated code actually runs on the target hardware and whether it respects cycle budgets. That is where hands-on experience from the original era still matters.

The toolchain

You don’t need the real hardware to get started (although testing on it is wonderful). A modern cross-development workflow looks like this:

• Assemblers/compilers: ACME, ca65/cc65 or Kick Assembler for 6502; z88dk or sjasmplus for Z80.
• Emulators: VICE (Commodore), b-em (BBC Micro), Fuse (ZX Spectrum), and WinAPE or similar for the Amstrad CPC.
• Editor + AI: a normal code editor, with the AI as a pair-programmer for drafting, reviewing and explaining code.

NeonStrafe: a Commodore 64 shoot-’em-up, stage by stage

The first game is NeonStrafe, a side-scrolling shoot-’em-up for the Commodore 64, written entirely in 6502 assembly (assembled with ACME) and built up in four stages. Each clip below is 10 seconds of the finished stage running in the VICE emulator.

Stage 1: a ship you can fly and fire

A metallic-blue ship on a black screen, moved with the joystick, firing a stream of yellow bullets. The ship and bullets are all hardware sprites.

Stage 2: a scrolling cave

The world now scrolls past: a rocky ceiling and floor with stars drifting through the gap. It uses the hardware fine-scroll register together with two alternating screens, so the picture never tears.

Stage 3: enemies and collisions

Red saucers attack in waves on straight and wavy paths. Shoot one and it explodes; touch one, or the cave wall, and your ship explodes, the border flashes red, and the ship respawns blinking while it is protected.

Stage 4: status bar and power-ups

A fixed status bar (using a raster split so it stays still while the cave scrolls) shows the score, lives and five upgrade slots: SPEED, RAPID, DOUBLE, HOMING and SHIELD.

In the clip above the ship never collects a power-up capsule, so the upgrade system is not visible. This second clip is a test build that holds fire down and collects capsules automatically, so you can see the slots light up and the homing missile launch:

These clips were recorded with scripted joystick input rather than a human pilot, which is why the ship loses lives fairly often in the later stages.

What’s next

I’ll be sharing the results as I go: the games, the prompts that worked, the ones that went spectacularly wrong, and what I learned about getting an AI to write reliable assembly language. If you have a favourite 8-bit machine or game genre you’d like to see tackled first, let me know!