01 The origin
My first memory of making a computer do something is a game of hangman — a little stick figure, a row of dashes — typed in line by line from a book. I was three, maybe four, sitting alongside my dad: coding, or more honestly watching him code. In my memory the screen glows green and the text is white, which has me half-convinced it wasn't a Commodore 64 at all but a 128 — though a three-year-old makes a poor witness, and it was more than forty years ago, so I wouldn't swear to any of it.
What I'm sure of is the Spectrum. That's where it took. I'd load the Horizons tape just to watch it run, and work through the examples in the back of the BASIC manual one at a time — changing a number here, a word there, to see what would happen. Somewhere in that I stopped being someone who used the machine and turned into someone who wanted to make it do things.
That itch never really left. All these years on, I write software for a living — still chasing the same feeling.
02 Why I'm building it
Most of my career has been technical rescue — taking on systems everyone else had written off, whose original authors were long gone and whose design had stopped making sense to whoever was left holding them. The hard part was rarely the code. It was that the code survives and the reasoning doesn't: you can read what a system does, but reconstructing why it was built that way, once the people who knew have gone, can be close to impossible.
The place I work now is the encouraging version of that. They'd half-talked themselves into believing their Rails monolith was the thing holding them back and had to be replaced — which would have cost years and thrown away a decade of hard-won behaviour. It didn't need scrapping; it needed bringing up to date. We took it from Rails 5.2 to 8.0, picked up about 30% in performance along the way, and the "legacy" monolith came out the other end genuinely valuable again. What made the difference wasn't cleverness — it was that someone still understood the thing well enough to argue for saving it.
That same loss of understanding is happening to early computing, except there's no upgrade path out of it. The people who built these machines and wrote their best software are retiring, and some are dying. The code is being kept — emulated, decompiled, archived — but the thinking behind it mostly isn't, and once that's gone no disassembler brings it back. I'd like to get some of it down while the people who know are still here to tell me where I'm wrong.
03 What it is
Code Like It's 198x teaches you to write games for old machines. It starts on four — the Commodore 64, the ZX Spectrum, the Amiga and the NES — and the intention is to work outward across the 8-bit, 16-bit and 32-bit eras over time.
The games are the hook. What you're really learning is how the machine works once you stop pretending it's something else — where the memory is, what a raster line costs you, how the sound chip actually makes a noise. Not an API's idea of those things, but the machine's.
They're not taught in isolation, either. Build on a few of them and you start to see why they were designed the way they were — why the 6502 and the Z80 reach for different tricks, how graphics went from character grids to sprites to blitters. And where modern boards exist for these machines — the MEGA65, the ZX Spectrum Next, the Amiga Vampire — the course covers those too: the original constraints first, then what the extra room buys you.
04 How you learn
You build from the first lesson — a small thing you can actually run, then a slightly bigger one, rather than theory now and a payoff later.
On the machines that shipped with BASIC, that's where you start. You write games in BASIC and get good at it, and then somewhere in the later lessons you try to do what real games did — smooth scrolling, a screen full of sprites, raster effects — and watch BASIC run out of road. By the time the course hands you assembly you're not being told you need it; you've felt why. The consoles never had BASIC, so there you start on assembly straight away — still game-first, always something on the screen.
Ideas come back around, too. Something introduced simply early on gets opened up later, once you've the footing for the fuller version: a few useful half-truths now, the rest when you're ready for them.
05 Why these machines
Part of why it's worth doing on a C64 or a Spectrum rather than something modern: you can hold the whole machine in your head. There's a finite amount of memory and you can know what's in all of it. Write to $D020 on a C64 and the border changes colour — you can point at the cause. Time isn't tucked away somewhere either; it's the beam moving down the screen while your code races it.
That's a rare thing to be able to feel now, and it quietly changes how you read every machine you touch afterwards.
06 The Vault and the Pattern Library
Two things sit alongside the lessons. The Pattern Library is the reusable stuff the course builds up — a first sprite becoming a multiplexer, a beep becoming a music player — there for you to lift into your own projects.
The Vault is the bigger one. It's an encyclopaedia of the era, but the point of it isn't specs and release dates — it's the connections. A game ties to the people who made it, the company that shipped it, the machine it ran on, the tools they had, and the films and money and politics of the moment that produced it. Follow the links and the period starts to read as something that happened rather than something behind glass.
That means writing people as they actually were, including the ones whose views or behaviour don't sit well today. Sanitising it wouldn't make better history. You can admire what someone built without signing off on everything they were.
07 A note on AI
I should be straight about how this gets made. The scope is enormous and I'm one person with a day job, so I use AI to help draft lessons and rough out code — including, with some irony, prose like this, which is exactly why I keep going back over it to make it sound like a person wrote it.
What AI can't do is know these machines. It hasn't spent a weekend losing to the same bug, or found the trick at 2am that nobody ever wrote down. It pattern-matches, fluently, and every so often it's fluently wrong. So everything that can be checked is: the code is assembled and run, screenshots come from real runs, and historical claims need sources. The public bar is written down in Sources & Standards. The aim is to lean on AI less as time goes on, not more — as people who actually lived this turn up and put me right.
08 Free and open
It's free, and it stays free. The writing is under Creative Commons, the code is MIT on GitHub, and the toolchains are there for anyone to use. If the project ever falls over, everything it has made survives.
One honest snag: a couple of platforms — the Amiga, and C64 BASIC — need their original system ROMs to run, and those aren't mine to hand out. You bring your own: free where you can find them, or a few pounds via Amiga Forever or C64 Forever. The course costs nothing; the machine's ROMs are yours to sort. More on ROMs →
There's a Patreon and GitHub Sponsors if you'd like to chip in — but you'll never pay to learn.
09 Me, and a request
I'm Steve Hill. I've been writing software for nearly forty years, mostly the unglamorous rescue kind — taking on the systems nobody else wants and keeping them running. The day job is a resource-management platform; this is what I build the rest of the time, and the project I'd most like to be remembered for.
It's too big for one person, though, and not only in the money sense. If you know one of these machines deeply, remember techniques that never made it into a book, or worked on them back when it was a job, I'd genuinely like to hear from you — and just as much if you'll work through a lesson and tell me where it's wrong, or can put me in touch with someone who was there before that chance is gone.
Tell me your first machine and what you know about it. Especially tell me what I've got wrong.