What Was Actually Worth Saving From the Amiga?

Mike·September 6, 2026·Work documented: January 21, 2026·27 views

Before building anything, I had to separate what I actually loved about the Amiga from what I just remembered fondly. Those turned out to be two different lists.

Before I could design anything, I had to do something a little uncomfortable: go through everything I remembered loving about the Amiga and sort it into two piles. Pile one: things that were genuinely good architecture. Pile two: things I just remembered fondly because I was younger and everything was more exciting back then.

Nostalgia is a hell of a filter, and it lies to you in a very specific way — it tells you the whole package was great, when usually what was great was three or four ideas wearing a costume made of 1985 hardware limitations.

What earned its place

Multitasking that actually felt responsive was the big one. Not multitasking as a checkbox feature — multitasking that a person sitting at the keyboard could feel. Things kept moving while other things were happening. That's a real, durable design goal, and it's one a lot of "modern" systems still get wrong in their own ways.

Custom hardware as a division of labor was the second one. Agnus, Denise, Paula — I'm not defending the specific chips, I'm defending the idea that they represented: don't make one general-purpose processor do everything. Let dedicated hardware do the parts it's actually good at, and let it do that work without babysitting from the CPU. DMA wasn't just a technical trick, it was a philosophy about where work belongs.

Multimedia as a first-class capability, not a bolt-on. Coherent system integration — the sense that the OS and the hardware were designed by people talking to each other, not two teams that never met. Those all survive the trip to 2026 fine. They're not nostalgia, they're just good engineering that happened to ship in 1985.

What doesn't automatically survive

Here's the harder pile. The old address spaces don't survive — there's no principled reason to drag 24-bit addressing into 2026 out of loyalty. The exact chipset register layout doesn't survive; that's an implementation detail of hardware that hasn't been manufactured in decades. CPU-specific assumptions baked into the OS don't survive. Old memory constraints don't survive — those were constraints, not choices, and constraints from forty years ago don't deserve a vote in 2026's design.

And the big one, the one I keep coming back to: the trusted-single-user-at-the-keyboard assumption does not survive. The Amiga's security model, to the extent it had one, assumed the person touching the machine was the only person who'd ever touch it, and that whatever ran on it could be trusted about as far as the OS could throw it. That was fine in 1985. It's not fine for a machine that's going to sit on a network in 2026. I'll get into exactly what that means for the architecture a few entries from now, but I want to flag it early: this isn't a small asterisk, it's one of the load-bearing decisions of the whole project.

Exact binary APIs don't survive either, for what I'd hope is an obvious reason — there's no binary compatibility target here. Nobody is running original Amiga executables on this thing today. That's explicitly a job for a future emulator, not something baked into the core design.

The actual question

Which parts were principles, and which parts were just 1985?

That's the sorting test I used on everything, and it's the same test I'm going to keep applying as this journal goes on. Every time something from the old machine shows up in a design conversation, that's the question: is this a principle worth carrying forward, or is this just what 1985 looked like wearing a costume made of nostalgia? Next up: the machine that actually got me started down this road in the first place, and the reason it wasn't the Amiga's OS — it was the Video Toaster.