Close
0%
0%

Project Ceylon, a retro-futurism Project

What if Commodore had never gone bankrupt and Amiga development had never stopped?

Similar projects worth following
0 followers
What if Commodore had never gone bankrupt and Amiga development had never stopped? I'm trying to build one plausible answer — in public, warts and all.

Written by Mike as an independent personal engineering project, published through The Weekend Report. Not a company blog, not a press release — a running log of what actually happened, including the parts that didn't work.

Commodore went bankrupt in 1994 and took continuous Amiga development down with it. This is the question that started everything: what would still be true if it hadn't.

I want to be upfront about something before I write another word of this: I am not rebuilding an Amiga 500. I am not rebuilding an Amiga 1200. Nobody is getting a cycle-accurate Motorola 68000 out of me, and if that's what you came here for, this whole series is going to disappoint you early and often.

What I'm actually chasing is a different, weirder question, and it's the one that started this whole thing: Commodore went bankrupt in 1994. Amiga development, as a continuous line, stopped. Not the ideas — people kept the ideas alive in emulators and hobbyist projects and a couple of increasingly sad corporate ownership changes — but the actual forward motion of "what does this architecture become next" stopped cold.

So: what if it hadn't? What would be sitting on somebody's desk in 2026 if that story had never been interrupted?

We're not rebuilding the Amiga of 1987. I'm trying to figure out what might have been sitting on somebody's desk in 2026 if the story had never stopped.

That's an alternate-history engineering question, not a preservation project, and the distinction matters more than it sounds like it should. A preservation project asks "how do we keep the old thing running." I'm asking "what would the old thing have grown into." Those point in almost opposite directions once you actually start working.

Principles versus hardware constraints

The Amiga in 1985 got a handful of things right that most of the industry took another decade or more to catch up on. Real preemptive-ish multitasking on consumer hardware. Custom chips doing real work off the main CPU instead of the CPU doing everything itself. Multimedia — audio, video, graphics — treated as first-class citizens of the machine's identity instead of an afterthought bolted on by a sound card manufacturer. A sense that the hardware and the OS were one coherent idea, not a CPU with a pile of drivers stapled to it.

None of that is 1985-specific. Responsiveness, asynchronous operation, modularity, specialized hardware doing specialized work, multimedia as identity, efficient use of what you've got, a coherent machine/OS relationship — those are principles. They'd be just as correct in 2026 as they were then.

What IS 1985-specific: the exact chipset, the exact address space, the exact CPU family, the assumption that whoever's sitting at the keyboard is the only person who will ever touch this machine and can be trusted completely. Those aren't principles. Those are just what 1985 hardware and 1985 threat models looked like.

Modern hardware and modern security requirements are going to change the implementation of every single one of those good principles. That's not a compromise on the vision — that's the actual work. Anybody who tells you they're bringing back the Amiga unchanged is either rebuilding a museum piece or lying to you about the scope.

Where this is going

I've already gone and looked at NewTek's Video Toaster, because if you're asking "what was the Amiga good at that nobody else was doing," desktop video is most of the answer. That's next.

Y'all are going to see this thing change shape more than once over the course of this journal. I'm not going to clean that up after the fact and pretend I knew where I was going the whole time. I didn't. I still don't, entirely. That's kind of the point of writing it down as it happens instead of after.

  • ◆ Project Ceylon Development Journal · Entry 5

    Mike3 hours ago 0 comments

    Project Nu-Day: Okay, Y'all, Let's Actually Build Something

    Mike·September 6, 2026·Work documented: February 13, 2026·17 views

    All that research had to turn into something eventually. Project Nu-Day was the first real attempt: a modern media workstation, built for x86-64, inspired by the Toaster and DigiPaint but not trying to be either.

    At some point, research has to turn into a project, or it's just a very well-organized way of reading old documentation forever. So: Project Nu-Day. That was the name for the first real attempt to build something out of everything I'd been chewing on — the Amiga's good ideas, the Video Toaster's approach to real-time media, DigiPaint's painting engine — aimed at modern, ordinary, commodity x86-64 hardware.

    What Nu-Day was actually trying to be

    The goal was a media workstation. Not an operating system for its own sake — a machine built around the idea that graphics, video, and painting-style tools deserved to be first-class citizens of the platform, the same way they were on the Amiga, but running on hardware you could actually buy in 2026 instead of hardware you'd have to find on an auction site.

    I was explicit with myself from the start that this was not an emulator project. I wasn't trying to run Amiga binaries. I was trying to build a new thing that took the same philosophy — specialized hardware doing specialized work, multimedia as identity, responsiveness that a person can feel — and applied it fresh, on hardware nobody in 1985 had any reason to design for.

    Virtual first, on purpose

    From day one I decided this was going to be developed virtual-first — inside QEMU, not on bare metal. I'll spend the entire next entry on why that decision mattered as much as it did, because it's not just "easier for development," it's a real architectural strategy. For now: I wanted a laboratory before I wanted a machine.

    Early hardware abstraction thinking

    Even at this early stage, I knew I didn't want the media/graphics ambitions hard-wired to one specific piece of hardware. The whole point of "specialized hardware doing specialized work" only holds up if the software layer knows how to talk to specialized hardware in general, not just one card I happened to own. That idea was still pretty vague at this point — more of a discipline I was trying to hold myself to than an actual abstraction layer with real boundaries — but it's the seed that eventually turns into a much more serious conversation once GPU work enters the picture.

    Nu-Day was ambitious for what it was, and I want to be honest that at this point I did not yet see the shape of the problem I was actually walking into. That comes later, and it comes from a direction I did not expect: not from the media ambitions failing, but from the media ambitions succeeding just enough to reveal how much operating system I was quietly agreeing to build underneath them.

    Next up: why the very first real infrastructure decision was to build the computer inside QEMU before building anything resembling the computer itself.

  • ◆ Project Ceylon Development Journal · Entry 4

    Mike3 hours ago 0 comments

    Old Source Code Is Useful. Copying It Isn't the Point.

    Mike·September 6, 2026·Work documented: February 4, 2026·20 views

    Having thirty-year-old source code available doesn't mean the job is to transcribe it. Here's how I actually use historical material as research instead of a shortcut.

    I said in the last entry I'd come back to this, because it's the kind of thing that's easy to say correctly in one sentence and then get wrong in practice if you're not paying attention. So: having the Video Toaster's source available doesn't mean the job is "go copy the good parts into a modern language." That's not research, that's just slow transcription with extra steps, and it would also potentially be a licensing mess I have no interest in stepping into.

    What I'm actually doing with it

    When I read old source — Toaster code, DigiPaint's painting engine, whatever else turns up as this project goes on — I'm reading it for behavior and architecture, not for lines to lift. What data structure did they reach for when they needed to composite video in real time on hardware with no headroom to spare? What order did they do operations in, and why that order and not another one? Where did they put the boundary between "the hardware does this" and "software does this," and does that boundary still make sense on completely different hardware forty years later?

    Those are architectural questions. The answers to those questions are useful to me. The literal C (or 68k assembly, in some of the older stuff) that implements those answers on a machine that hasn't been manufactured in decades is a lot less useful, because it's solving problems — memory pressure, clock speed, a specific bus architecture — that mostly don't exist on the hardware I'm targeting anymore. Studying WHY something worked survives the trip to modern hardware. WHAT LINE OF CODE did it survives a lot less well.

    Provenance matters, and clean-room separation isn't paranoia

    I try to keep a clean separation between "I read this and now I understand the problem better" and "I am now writing code." That's not me being precious about it — it's just good practice any time you're working with someone else's historical material, licensed release or not. If I understand a design decision well enough to reimplement it from a description of the problem, without the original code open in another window while I type, that's a real, defensible clean-room boundary. If I'm translating line by line, that's not research anymore, that's a port, and it comes with a completely different set of obligations I'm not trying to take on here.

    This matters doubly because NewTek's release explicitly comes with usage terms, and even generous ones deserve to be respected on their own terms rather than stretched to cover something the release wasn't meant for.

    A concrete example: DigiPaint

    DigiPaint's painting engine had to do real-time brush rendering and color manipulation on hardware that measured its memory in kilobytes it could actually spare for the framebuffer. Reading how they approached that taught me something about where the actual hard constraints in a painting tool live — it's rarely the brush math itself, it's how aggressively you can avoid touching memory you don't have to touch. That's a genuinely portable lesson. It shows up again in completely different form when I get to display architecture a few entries from now, and — spoiler for an entry I haven't written yet — getting that lesson wrong is a real part of why an early display approach didn't survive contact with actual requirements.

    So: old source code, useful. Old source code as a find-and-replace target for a modern rewrite, not useful, and honestly a little bit of a trap. Next up, the project this research actually turned into: Project Nu-Day.

  • ◆ Project Ceylon Development Journal · Entry 3

    Mike3 hours ago 0 comments

    Then I Found the Video Toaster Source Code

    Mike·September 6, 2026·Work documented: January 29, 2026·34 views

    NewTek released the Video Toaster's source publicly years ago. That's where the real research thread started — not the Amiga's OS, but the thing that made the Amiga famous in the first place.

    If you want to know what the Amiga was actually good at — not what it was capable of in theory, what it was famous for, what put it on television sets — the answer is the Video Toaster. NewTek built a desktop video production system on top of the Amiga that could do real broadcast switching, graphics, and character generation on consumer hardware, at a fraction of what dedicated video hardware cost at the time. That's not a footnote in the Amiga's history. For a lot of the outside world, that WAS the Amiga's history.

    So when I started asking what a modern continuation of this machine should be able to do, the Toaster was the obvious first research thread. Not the OS internals — the actual flagship application people bought the machine to run.

    If you've never seen one of these running, here's a good demonstration of what it could actually do, live, on hardware that cost a fraction of the broadcast gear it was replacing:

    Finding it was still there

    Here's the thing that got me excited enough to stay up later than I should have: NewTek actually released the Video Toaster source publicly a while back, and it's still sitting out there, maintained by a small community, at discreetfx.com. Full source. Developer documentation. The Flyer. ToasterCG. DigiPaint. All of it, or at least a meaningful chunk of it, available for anyone willing to go dig.

    I want to be careful here, because it would be really easy to overstate what this means. This isn't a green light to lift code. I'll get into exactly how I think about that boundary in the next entry, because it deserves its own space and it's more subtle than "copy good, don't copy bad." For this entry, I just want to talk about what's actually there and why it mattered to me.

    What became researchable

    Desktop video switching, in source form, from a company that was actually shipping it commercially. Graphics and character-generation code from ToasterCG, which — for the era — was doing professional-quality titling and scrolls on hardware that cost a fraction of the broadcast equipment it was replacing. DigiPaint's painting engine. Developer documentation that explains not just what the code does but why it was built that way, which is honestly the more valuable half.

    That's a real body of research material about how a small team in the late '80s and early '90s solved genuinely hard real-time media problems on genuinely limited hardware. Reading it doesn't hand you a modern architecture. It hands you a set of real, tested decisions about where the hard parts of a media system actually are, made by people who had to ship something that worked on live television.

    A note on link rot

    I checked every one of these links before publishing this, because half the pain of pointing people at 30-year-old software history is that the links are usually dead by the time anyone follows them. Most of what's below is still live. One document I originally wanted to cite — a PDF that was supposed to be the NewTek Video Toaster Developer's Handbook — turned out, when I actually opened it, to be a scanned document from a printer with nothing to do with the Toaster. So it's not in the list below. I'd rather tell you a source didn't pan out than link you to something that looks official and isn't.

    Sources & Research

    I'm not going to reproduce any of that source code here — that's not what this journal is for, and it's not how I want to treat someone else's work. What it's for is the next entry: how I actually think about...

    Read more »

  • ◆ Project Ceylon Development Journal · Entry 2

    Mike3 hours ago 0 comments

    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.

  • Project Ceylon Development Journal · Entry 1

    Mike3 hours ago 0 comments

    Commodore went bankrupt in 1994 and took continuous Amiga development down with it. This is the question that started everything: what would still be true if it hadn't.

    I want to be upfront about something before I write another word of this: I am not rebuilding an Amiga 500. I am not rebuilding an Amiga 1200. Nobody is getting a cycle-accurate Motorola 68000 out of me, and if that's what you came here for, this whole series is going to disappoint you early and often.

    What I'm actually chasing is a different, weirder question, and it's the one that started this whole thing: Commodore went bankrupt in 1994. Amiga development, as a continuous line, stopped. Not the ideas — people kept the ideas alive in emulators and hobbyist projects and a couple of increasingly sad corporate ownership changes — but the actual forward motion of "what does this architecture become next" stopped cold.

    So: what if it hadn't? What would be sitting on somebody's desk in 2026 if that story had never been interrupted?

    We're not rebuilding the Amiga of 1987. I'm trying to figure out what might have been sitting on somebody's desk in 2026 if the story had never stopped.

    That's an alternate-history engineering question, not a preservation project, and the distinction matters more than it sounds like it should. A preservation project asks "how do we keep the old thing running." I'm asking "what would the old thing have grown into." Those point in almost opposite directions once you actually start working.

    Principles versus hardware constraints

    The Amiga in 1985 got a handful of things right that most of the industry took another decade or more to catch up on. Real preemptive-ish multitasking on consumer hardware. Custom chips doing real work off the main CPU instead of the CPU doing everything itself. Multimedia — audio, video, graphics — treated as first-class citizens of the machine's identity instead of an afterthought bolted on by a sound card manufacturer. A sense that the hardware and the OS were one coherent idea, not a CPU with a pile of drivers stapled to it.

    None of that is 1985-specific. Responsiveness, asynchronous operation, modularity, specialized hardware doing specialized work, multimedia as identity, efficient use of what you've got, a coherent machine/OS relationship — those are principles. They'd be just as correct in 2026 as they were then.

    What IS 1985-specific: the exact chipset, the exact address space, the exact CPU family, the assumption that whoever's sitting at the keyboard is the only person who will ever touch this machine and can be trusted completely. Those aren't principles. Those are just what 1985 hardware and 1985 threat models looked like.

    Modern hardware and modern security requirements are going to change the implementation of every single one of those good principles. That's not a compromise on the vision — that's the actual work. Anybody who tells you they're bringing back the Amiga unchanged is either rebuilding a museum piece or lying to you about the scope.

    Where this is going

    I've already gone and looked at NewTek's Video Toaster, because if you're asking "what was the Amiga good at that nobody else was doing," desktop video is most of the answer. That's next.

    Y'all are going to see this thing change shape more than once over the course of this journal. I'm not going to clean that up after the fact and pretend I knew where I was going the whole time. I didn't. I still don't, entirely. That's kind of the point of writing it down as it happens instead of after.

    You can keep up to date with this project by going to https://theweekendersproject.com/report/series/project-ceylon

View all 5 project logs

Enjoy this project?

Share

Discussions

Does this project spark your interest?

Become a member to follow this project and never miss any updates