There’s something unforgettable about your first computer—especially when it’s an 8-bit marvel packing 64KB of RAM and a well-worn keyboard that’s seen countless hours of coding.
I’ve been hooked on building games and applications since my early teens. While other kids were busy collecting Panini stickers, swapping Garbage Pail Kids, or arguing over who had the best Top Trumps card, me and my high school friends were busy trying to write software… and maybe, just maybe, make a few bucks doing it.
👾 Enter the Commodore 64
Ah yes, the golden days—back in the early ’80s when one of my friends’ parents bought them a Commodore 64, this basically meant we all had a Commodore 64. Communal computing was a thing before cloud was even a concept.
That entire summer? Gone. Spent hunched over our CRTs, flipping through the Commodore manual and a 6502 Assembly book that may as well have been ancient Greek. But oh, the joy of discovery! The joy of discovery was intoxicating—every new concept felt like unlocking a cheat code to our favorite game.
One day we stumbled across this concept called interrupts. Before that, our proudest achievement was a spaceship that could move and shoot a bullet. The only problem? When the bullet was in motion… everything else froze. We were like, “Wait, what the hell? Why can’t we walk and chew gum at the same time like real games do?”
🎮 But First..Why Were We Lucky? Sprites, Baby!
Looking back, we didn’t fully appreciate how much of a blessing the Commodore 64’s hardware really was. It had actual sprite support, which meant we could move objects around the screen—spaceships, aliens, bullet blobs—without redrawing the entire frame or glitching out like we were launching fireworks.
Our friends with ZX Spectrums? They weren’t so lucky. They were handcrafting graphics directly in memory, manually XOR’ing pixels, and praying their screen didn’t turn into a glitchy mess every time a character moved.
We, on the other hand, got to say things like,
“Hey C64, here’s my sprite. Put it there. Now move it 3 pixels to the right. Great. Thanks.”
It was almost like having a GPU assistant… if that assistant lived in a beige breadbox and made a loud clicking sound when you pressed Return.
The built-in sprite hardware didn’t just make development faster—it made it fun. It gave us early wins. And those little wins, those spaceship-that-doesn’t-freeze moments, kept us moving from failure to failure without ever losing enthusiasm.
But even with sprites, we hit a wall that would haunt us for weeks.
Sure, we could move a spaceship around, but the moment we fired a bullet, everything else locked up like Windows ME trying to run Photoshop. We were still thinking in single-threaded caveman logic: do one thing, then do another thing, then wonder why our game looked more like a stop-motion film with continuity issues.
That’s when it happened….we stumbled across a concept that would change everything: interrupts.
One summer afternoon, we discovered we could tell the VIC-II chip “Hey, when you finish drawing raster line 100, stop everything and run MY code!” It was like having a backstage pass to reprogram the hardware 50 times per second—or 60 times if you lived in North America, because apparently even television standards couldn’t agree on basic math.
Games written for Europe’s PAL systems (50Hz) ran slower than their NTSC (60Hz) counterparts in North America. Same code, different speed. Pac-Man on PAL? Like wading through molasses. On NTSC? Like he’d just downed three espressos.
And developers? Most didn’t care. They’d time everything perfectly for their home region, ship it worldwide, and let the rest of us deal with music playing at chipmunk speed or games that moved like underwater ballets.
“Stares into the distance, eye twitching slightly, before violently shaking head”
Right, anyway—back to our actual achievements. Our first success? Making the background change color mid-screen. Revolutionary stuff.
Then came sprite multiplexing—our sleight of hand to turn 8 measly hardware sprites into 16.
By frantically repositioning them between screen draws, we felt like digital magicians pulling rabbits out of silicon hats.
But the real magic trick? The status bar hack.
We still remember the first time we pulled it off on the C64.
A classic from the retro game dev playbook—using raster interrupts to split the screen into two very different worlds.
At the top: pure chaos.
Multi-directional scrolling, parallax background hacks, sprite collisions, pixelated explosions—
everything flying around like a caffeine-fueled shootout in 8-bit space.
The VIC-II scroll registers were pushed to their emotional limit, simulating movement the poor C64 was never meant to handle.
Then—right at raster line 200—BAM: interrupt triggered.
Suddenly, the storm stopped.
The bottom quarter of the screen froze into calm, composed professionalism.
A static HUD appeared: score, lives, ammo, maybe a sad little PETSCII face when your health hit zero.
No scrolling. No chaos.
Just the quiet confidence of a librarian reading aloud while a bar fight raged above her.
“We weren’t writing code—we were negotiating with electrons.”
By the end of that summer, we’d gone from “spaceship that can’t multitask” to “smooth parallax scrolling with perfect sound synchronization.”
We were literally racing the electron beam and winning.
Interrupts turned us from code peasants into hardware wizards.
We were no longer just programming—we were conducting a symphony of precisely timed chaos.
💾 Sending Floppy Disks to Fortune
We became pros at mailing out demo floppy disks—yes, actual 5.25-inch floppy disks—to every game company we could think of. Think cold-emailing with more plastic.
And then it happened.
One day, at the age of 16, we got a call: Capcom wanted us to develop a title. Boom. Euphoria. Joy. Panic. Did we know what we were doing? Not really. Did we do it anyway? Hell yes.
I remember that moment so clearly that I can practically hear the dial-up tone just thinking about it.
The game? Black Tiger—a port for the Commodore 64. We built the whole thing in about 13,000 lines of 6502 assembly, painstakingly typed into a machine that judged every keystroke with a loud clack. No Git. No cloud. Just a pile of floppy disks and blind faith.
At one point, we thought we lost the entire source code—months of work gone—because one disk vanished. Panic. Despair. Existential teenage meltdown.
Found it the next day… under a pizza box.
Classic… devops, the old-fashioned way.
⏩ Fast Forward: 24 Years of Business, One AI Renaissance Later…
Flash forward to today. I’m in my early-to-mid-50s (we don’t do exact numbers here) and recently closed my company after a successful 24-year run.
But you know what?
It’s an insanely exciting time to be a developer again.
We’ve gone from reading dusty manuals to chatting with AI that casually knows every language, every framework, and somehow always knows exactly what you meant to type before you finish typing it.
So here’s the experiment:
Can my buddy and I recapture that teenager energy and build an entire application—just the two of us—using modern AI tools, some retro grit, and an irresponsible amount of coffee?
Let’s find out—but first, let me figure out how to post this blog to GitLab Pages.
“Hey ChatGPT…”
Next up: I’ll break down exactly what we’re using to build this thing—from frontend frameworks and serverless backends to our AI-powered coding sidekicks and dangerously cluttered VS Code setups. Basically, a modern dev stack… built with retro soul.