Code Like It's 198x

02 Why This Exists

I've spent much of my career rescuing systems that weren't "old" — they were abandoned. Systems whose original authors were gone, whose design intent had evaporated, whose abstractions had outlived their understanding.

I've seen what happens when only the "what" survives and the "why" dies: teams panic, rewrite, lose data, burn out — and quietly destroy functioning machines because nobody can still think the way the original builders thought.

The oral history of early computing is evaporating. Engineers are retiring. Design intent is being lost. What remains is documentation without wisdom.

Someone's got to preserve it. Why not me?

03 What I'm Building

Code Like It's 198x is a comprehensive curriculum teaching you to make games for vintage computers and consoles — from the Commodore 64 to the PlayStation 2, across the 8-bit, 16-bit, and 32-bit eras. The goal is to cover every system worth covering.

But the games are the sugar coating. The real curriculum is how computers actually work when you peel away modern illusions.

I'm not teaching frameworks. I'm teaching machines.

Each system is its own world, with its own physics, its own limits, and its own philosophy. You'll learn to reason about memory maps, cycle timing, raster interrupts, and sound chips — not APIs. You'll learn what the machine is, not what the language pretends it is.

04 How You'll Learn

Most tutorials tell you to learn assembly because it's faster. That's true, but it's not motivating. You don't feel why it matters until you've hit the wall yourself.

Code Like It's 198x uses game-first learning. You discover concepts through necessity, not lectures. From the very first lesson, you're building something real — not trudging through theory waiting for it to become relevant.

For home computers that had BASIC, the curriculum starts there deliberately. You'll build games in BASIC. You'll get good at it. And then, in the final tier, you'll try to implement professional techniques — smooth scrolling, sprite multiplexing, raster effects — and watch BASIC fail. Six frames per second. Raster jitter. The ceiling.

By the time you reach assembly, you won't be told you need it. You'll want it. You'll have felt the limits yourself, and you'll understand exactly what you're escaping from.

For consoles without BASIC, you go straight to the metal from day one — but still game-first. Always building. Always seeing results.

The curriculum uses spiral learning throughout. Concepts are introduced early in simplified form, then revisited with increasing depth and truth as you progress. We use careful "lies to children" — telling you what you need to know now without overwhelming you, then peeling back the abstraction later when you're ready. You gradually wake up inside the machine.

05 The Comparative Lens

Systems aren't taught in isolation.

Code Like It's 198x treats hardware like a biological lineage. You'll see how the Z80 and 6502 solve the same problems differently. How graphics pipelines evolved from character displays to bitmap modes to hardware sprites to blitters. How sound synthesis philosophies diverged — the SID chip's analogue warmth versus the AY-3-8910's digital precision versus the Amiga's sampled audio revolution.

This produces something deeper than platform-specific skills. You learn the tree of technological ancestry. You start to see why machines were designed the way they were, what problems each generation was trying to solve, and how solutions from one platform influenced the next.

When you understand the evolutionary pressures, you understand the machines. And when you understand multiple machines, you understand computing itself in a way that no single-system tutorial can provide.

06 Original and Enhanced

The curriculum covers systems as they originally were — but it doesn't stop there.

Modern enhanced hardware like the MEGA65, ZX Spectrum Next, and Amiga Vampire extends classic systems with capabilities their designers could only dream of. More memory. Faster processors. New graphics modes. Hardware features that would have seemed like science fiction in 1985.

Code Like It's 198x covers both. You'll learn to work within the original constraints, mastering the techniques developers used when every byte mattered. Then, where enhanced hardware exists, you'll learn to take advantage of expanded capabilities while still understanding the foundations they're built on.

This isn't about choosing between authenticity and capability. It's about understanding the original so deeply that you can appreciate — and exploit — what the enhancements make possible.

07 Why Vintage Systems Matter

Those early machines had walls. You could map them. You could learn every corridor. You could know where everything lived. You could stand at memory address $D020 on a C64 and feel the border colour change under your feet.

A single human mind could fully contain the machine. That's vanishingly rare now.

I learned very early that I wasn't issuing requests to an invisible god. I was cooperating with a finite, mechanical creature. Memory was a landscape. Screen space was physical territory. Sound wasn't "audio" — it was voltage being persuaded to sing. Time wasn't hidden — it marched across the screen as raster lines.

That changed my relationship with technology forever.

08 The Real Goal

This isn't nostalgia. It's training.

I want to create engineers who are comfortable with constrained machines, finite memory, visible costs, and mechanical truth — because these are the engineers who can rescue, extend, and preserve systems instead of replacing them.

Modern developers trained only on abstraction struggle when the abstractions leak. They've never seen the physical machine underneath. They've never had to account for every byte, every cycle, every constraint.

Code Like It's 198x is cognitive inoculation against bullshit abstraction. It's training minds that can walk into a legacy system in 2038 and not flinch.

09 The Preservation Mission

We've already lost so many talented minds. Galaxy-brained developers who showed us ways of doing things nobody else had ever thought of. And while we can decompile their work, or even examine their source code where it survives, so much has been lost — companies changing hands, tapes and disks going missing, formats that simply aren't readable anymore.

But even when the code survives, the thinking doesn't.

We can reverse-engineer what they did. We can't reverse-engineer why they tried it. The dead ends they explored. The moment of insight that made it work. The reasoning that led them down one path instead of another. That dies with them, and no amount of decompilation brings it back.

There's knowledge about these systems that exists only in the heads of aging developers who worked on them professionally. If it's not documented soon, it'll be lost forever.

I'm not just teaching code. I'm archiving mental models, hardware constraints, design tradeoffs, cultural patterns, and computational philosophy.

This is computing anthropology disguised as a tutorial site.

11 The Pattern Library

As you progress through the curriculum, you'll build up a library of reusable code patterns and techniques — some platform-specific, some universal.

These aren't just code snippets. They're grouped by category and complexity, showing how techniques evolved over time as developers learned to make these machines sing. You'll see how a simple sprite routine becomes a multiplexer, how a basic sound effect becomes a music engine, how naive collision detection becomes pixel-perfect.

The Pattern Library is yours to use in your own projects. It's the accumulated wisdom of decades of game development, preserved and organised for practical use.

12 The Vault

The Vault is an encyclopedia of vintage computing — but not the kind that just lists specs and release dates.

It's the connective tissue. The people, the companies, the games, the systems, the tools — all woven together against the backdrop of the world that produced them. Popular culture. The geopolitical environment. The economic pressures. The technological possibilities. The dreams people had and the constraints they worked within.

Understanding how to code for a C64 is one thing. Understanding why games looked and played the way they did in 1985 is another. What films were influencing designers? What was happening in the world that shaped the themes they explored? What tools did they actually have access to? What were the business realities of publishing a game? Who were these people, and what drove them?

The Vault connects all of this. A game links to its developers, who link to the companies they worked for, who link to the systems they published on, who link to the tools they used, who link to the cultural moment that made it all possible. Follow the threads and you start to see the era as a living thing, not a museum exhibit.

This means documenting people as they actually were — including those whose views or actions might be considered unacceptable by today's standards. History doesn't improve by sanitising it. These were real people, brilliant and flawed, products of their time. Understanding who they were, what they believed, and how that shaped their work is part of understanding the work itself. We can acknowledge genius without endorsing everything a person said or did.

The Vault is how we answer the question that matters most: why did they do it that way?

13 A Note on AI

I want to be honest about how this project is being built.

The scope of Code Like It's 198x is enormous — potentially thousands of lessons across dozens of systems. I'm one person with a day job. To bootstrap something this ambitious, I'm using AI assistance to help draft lessons, generate initial code examples, and accelerate the writing process.

But AI assistance has limits. Language models can pattern-match and synthesise, but they don't know these machines the way someone who spent years pushing a C64 to its limits knows them. They can't tell you about the trick they discovered at 2am that nobody else had tried. They can't explain why one approach felt wrong even though it worked. They hallucinate details. They miss nuance.

Every lesson is tested against real hardware (or cycle-accurate emulation). Every piece of code is assembled and run through the toolchains I've built. I verify what I can. But I know there are gaps — things that technically work but aren't how it was really done, or explanations that miss the deeper insight.

The goal is to rely on AI less over time, not more. As real experts contribute, as the community grows, as people who lived this era share what they know — that's when the curriculum becomes what it needs to be.

AI is the scaffolding. Human expertise is the building.