Close
0%
0%

Project Ceylon: What If the Amiga Never Died?

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

Similar projects worth following
What if Commodore had survived and the Amiga had continued evolving for another 30 years? Project Ceylon is an independent attempt to build one plausible answer: a modern x86-64 microkernel workstation that carries forward the Amiga’s emphasis on responsiveness, multimedia, specialized subsystems, and a coherent machine/OS design—without reproducing 1980s hardware. Ceylon is not an Amiga emulator or museum reconstruction; it is an alternate-history engineering experiment asking which Amiga principles remain valuable on a modern machine. Ceylon already boots and runs under QEMU. Core platform mechanisms, storage, IPC, shared memory, scheduling, protection domains, and major portions of the device/service architecture are working. Graphics, audio, networking, recovery, the desktop, NuDOS and NuBASIC are being integrated toward the first externally testable A-series alpha. The first alpha will go through a small curated technical evaluation before a broader public QEMU release.

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.

ChatGPT Image Sep 28, 2026, 10_45_17 PM.png

that just turned out nice.

Portable Network Graphics (PNG) - 2.31 MB - 09/29/2026 at 03:47

Preview

FirstLight.png

Actual Project Ceylon runtime capture from QEMU. Early “first light” framebuffer output during bring-up. This is not a UI mock-up or rendered concept image; it is output produced by the Ceylon system during development. The incomplete text rendering visible here reflects the state of the display path at that milestone.

Portable Network Graphics (PNG) - 40.93 kB - 09/19/2026 at 22:18

Preview

Project Ceylon Architecture Sep 19, 2026, 04_27_31 PM.png

Project Ceylon Architecture

Portable Network Graphics (PNG) - 2.12 MB - 09/19/2026 at 21:32

Preview

Project Ceylon ProgressSep 19, 2026, 04_27_31 PM.png

Current Progress and Roadmap

Portable Network Graphics (PNG) - 2.05 MB - 09/19/2026 at 21:30

Preview

  • Project Ceylon Development Log — October 4, 2026: Slow, Boring, and Exactly What We Need

    Mike • 3 天前 • 0 comments

    Mike · October 4, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, Testing, Diagnostics, Refactoring, NuDOS, NuBASIC, SDK, Rust

    Project Ceylon is under a hard hold on new development right now.

    That does not mean work has stopped.

    It means forward development has stopped.

    There is an important difference.

    For the next couple of days, the goal is to test, appraise, repair, and retest what is already there until we are as close as we can reasonably get to a known-good platform.

    That is the point I want to resume coding from.

    Not "mostly working."

    Not "we think this path is okay."

    Not "the logs looked healthy last time."

    The closest thing to a known-good system we can actually prove.

    We are finding things

    The testing is doing exactly what it is supposed to do.

    We are finding issues.

    Some are ordinary bugs. Some are incomplete implementations. Some are places where two parts of the system each make sense by themselves but do not quite agree once they have to work together.

    That is why the hold exists.

    If we find a real problem now, I would much rather stop and fix it correctly than carry it forward underneath another three layers of code.

    That is slower in the short term.

    It is much faster than discovering later that a new feature was built on top of an assumption that was never actually true.

    This phase is not especially exciting to watch.

    There may be a few development logs over the next several days that amount to little more than:

    still testing, still appraising, still repairing.

    That is fine.

    I am not going to manufacture a dramatic milestone every evening just to make the journal look busy.

    The project is busy enough on its own.

    The goal is a trustworthy starting point

    What I want at the end of this pass is a baseline we understand.

    I want to know which parts of Ceylon are genuinely solid, which parts are fragile, which assumptions have survived contact with integrated testing, and which ones need to be removed before they become permanent architecture.

    That means looking at the machine from more than one angle.

    Individual subsystems still have to prove their own behavior, but we are also continuing to test the paths between them and the complete behavior of the system when those pieces are connected together.

    We have already learned the hard way that a green local test can coexist with a broken computer.

    So this is not about collecting more green boxes.

    It is about understanding what those green boxes actually prove.

    Advancement is on hold

    I have made this a hard rule for the current tranche:

    no new implementation work until this qualification and repair pass is complete.

    That includes application work.

    There are several things waiting in the wings that I would very much like to start building against the system.

    They can wait.

    If Ceylon is going to host applications, development tools, media software, games, and eventually more serious workloads, then the platform under all of that has to be the part we trust first.

    The temptation to move ahead is real.

    It is especially real when a new idea looks more interesting than another hour of testing restart behavior.

    But "interesting" is not a release criterion.

    The planning work has not stopped

    The implementation hold does not mean I have stopped thinking about what comes next.

    Quite the opposite.

    Some of the time that would normally go into coding has gone into tightening the specifications for work we already know is coming.

    We put together a much more serious plan for a Ceylon SDK and application toolchain.

    The initial idea is straightforward: start with a Linux-hosted development path that can build, package, deploy, launch, diagnose, rebuild, and replace a Ceylon application through supported system interfaces.

    The important part is what does not count as success.

    • A program linking on Linux is not enough.
    • A host-side simulation is not enough.
    • A build artifact...
    Read more »

  • Project Ceylon Development Log — October 3, 2026: The Computer Has to Prove Itself

    Mike • 4 天前 • 0 comments


    Mike · October 3, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, Diagnostics, NuDOS, Testing, Architecture, Reliability

    A couple of days ago I wrote that a green test is not the same thing as a working computer.

    Today we spent more time making that statement inconveniently literal.

    The work was not particularly glamorous.

    No dramatic desktop screenshot.

    No new application showing off.

    No sudden miracle where every unfinished subsystem decided to cooperate at once.

    Instead, we kept digging into something that has become increasingly important as Ceylon gets larger:

    how do we prove that the pieces are actually complete, that they are talking to each other correctly, and that the complete machine still behaves the way the architecture says it should?

    That question is starting to change how the project is being built.

    The diagnostic work is becoming part of the system

    We have been developing a more formal system-diagnostic approach rather than relying on a pile of independent unit tests and a few end-to-end smoke tests.

    The reason is simple.

    Ceylon now has enough moving parts that it is entirely possible for several components to pass individually while the complete path is still broken.

    A provider can initialize.

    A client can initialize.

    A protocol can compile.

    A local test can return PASS.

    And the two sides can still disagree about identity, lifetime, ordering, authority, or what a successful response actually means.

    That is not a theoretical concern anymore.

    We have already seen it.

    So the diagnostic model is being built around two questions:

    Does each part do what it is responsible for?

    and:

    Do all of the parts still work together when connected as the actual computer?

    Both have to be true.

    One without the other is not enough.

    We are finding incomplete work, not just bugs

    One useful consequence of this is that the diagnostic work is exposing a category of problem that is slightly different from an ordinary bug.

    Sometimes the code is not wrong.

    Sometimes the code is simply not finished enough to support the behavior we thought the system already had.

    That distinction matters.

    A bug means an implemented behavior does the wrong thing.

    An implementation gap means some part of the required behavior was never completed, never connected, or never qualified in the first place.

    Those are easy to confuse when you are looking at a large system from the outside.

    Something starts.

    Something logs a plausible message.

    Something returns a success code.

    It is very tempting to mark the box complete.

    The diagnostic work is forcing us to ask harder questions.

    Did the request actually reach the next service?

    Did the next service interpret it the same way?

    Did the resource being referenced still belong to the same generation?

    Did a successful response correspond to the exact operation that was submitted?

    Did the result make it all the way back to the user-visible behavior?

    And if one of those answers is "we don't know," then the feature is not proven.

    Inter-system communication is where the interesting failures live

    This is becoming one of the bigger lessons from Ceylon.

    Individual components are relatively easy to reason about.

    The boundaries between them are where things get interesting.

    Once two protection domains or services have to cooperate, suddenly we have to care about:

    • who owns the object;
    • who is allowed to refer to it;
    • which generation of that object is current;
    • whether a response belongs to the request we think it belongs to;
    • what happens if either side restarts;
    • what state survives;
    • what state must be invalidated;
    • whether retries are safe;
    • and whether a timeout means "failed" or merely "we no longer know."

    That is where a lot of operating-system correctness actually lives.

    Not in the middle of one function.

    At the seam between two things that each believe they are doing the right thing.

    The new diagnostic work is being designed to exercise those seams deliberately.

    NuDOS...

    Read more »

  • Project Ceylon Development Log — October 2, 2026: Tested Good. Except for the Part Where It Wasn't.

    Mike • 5 天前 • 0 comments

    Mike · October 2, 2026

    I've spent an extraordinary amount of time lately testing things that have already been tested.

    That sounds stupid.

    Unfortunately, it has also been productive.

    As Ceylon has grown, we've started putting much more emphasis on testing the computer as a complete system instead of proving individual pieces in isolation. That work continued today: building out the system-level diagnostic and qualification approach, exercising communication between services, looking for incomplete implementation paths, and following failures far enough upstream to understand why they existed in the first place.

    We're getting considerably better at finding problems.

    I'd be lying if I said I was always thrilled about what we're finding.

    It's probably a good thing I'm ex-Navy. I have enough expletives in reserve to cover almost any engineering situation.

    Some of them got exercised today.

    "Tested good" has acquired an asterisk

    One of today's more frustrating examples involved storage.

    We spent several hours troubleshooting something that, according to the existing evidence, was already good.

    Eventually we got far enough down the rabbit hole to discover part of the problem: code involved in that path was still effectively development-level implementation. It had been sufficient for the testing being performed at the time, but it had never subsequently been brought all the way up to the standard the finished subsystem actually required.

    That's an ugly class of problem.

    I don't think somebody sat down and deliberately decided to cheat a test. The more likely explanation is considerably more mundane and therefore more useful: development code was written to get a path working, the test passed, attention moved somewhere else, and nobody came back later to ask whether the code that made the test pass was actually suitable for the finished system.

    That is exactly the sort of oversight we're trying to eliminate.

    The annoying part is that the test wasn't necessarily lying.

    It may have accurately demonstrated what it was designed to demonstrate.

    We just hadn't asked it enough questions.

    That's becoming the real engineering problem

    Ceylon has enough pieces now that component testing alone isn't sufficient.

    A storage service can pass its tests. A filesystem component can pass its tests. IPC can pass its tests. A client can pass its tests. Put them together, exercise a path nobody thought was particularly interesting, and suddenly two components disagree about something that each assumed the other one handled.

    That is where more of the work is moving.

    We're testing inter-system communication and deliberately looking at the seams: what one service sends, what another thinks it received, who owns state, what happens after something restarts, whether incomplete paths are reachable, and whether a successful result actually represents the operation we think it does.

    When one of those tests fails, we're also getting stricter about not simply fixing the immediate failure.

    We want to know why the bad code was there, why it wasn't caught earlier, whether the specification or implementation was incomplete, whether the test was too narrow, and whether a temporary development shortcut became permanent by accident.

    Then comes the question that matters most:

    What do we change so we don't make the same mistake somewhere else?

    That is becoming part of the development process itself.

    We're not just fixing Ceylon.

    We're fixing the way we build Ceylon.

    NuDOS walked into this at exactly the right time

    NuDOS was another substantial piece of today's work.

    We're working toward a much more complete specification for Ceylon's command environment, including the actual logic, behavior, failure cases and interfaces required to implement it.

    The first gap analysis found plenty to work on. An adversarial pass found more.

    Questions that sound trivial at the command-line level become much less trivial...

    Read more »

  • Project Ceylon Development Log — October 1, 2026: The Mouse Moved, Asteroids Is Real, and the Hardware Stopped Sitting Still

    Mike • 6 天前 • 0 comments

    Mike · October 1, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, NuGUI, Input, Asteroids, Clarise, Plug-and-Play, QEMU

    Today was one of those days where several things that had been "almost there" finally became a lot more concrete.

    The short version:

    the real keyboard and pointer path passed, the Asteroids demo turned out to be a real application core instead of a future placeholder, and Clarise proved the same Ceylon image can cope with different PCI resource layouts without rebuilding the operating system around them.

    That is a fairly satisfying day.

    Especially because all three of those things point at the same larger goal:

    Ceylon needs to stop behaving like a carefully staged demonstration and start behaving like a computer.

    The mouse problem was not a mouse problem

    The first win was NuGUI input.

    Keyboard input has been working for a while, and the pointer path has been under qualification for several development tranches.

    Today the remaining QEMU tablet issue finally got pinned down.

    The parser was rejecting the virtual tablet because it reported itself as:

    class 3, subclass 0, protocol 0

    That was enough to send the existing HID logic down the wrong path.

    Nothing particularly dramatic was wrong with the mouse.

    The machine was simply looking at a perfectly valid HID device and deciding:

    "Nope. I don't know what that is."

    Which, in retrospect, is a wonderfully accurate description of quite a bit of operating-system development.

    The parser was corrected.

    Then we went back through the actual path instead of declaring victory because one pointer event appeared.

    The input path is now real

    The path being qualified is the one I actually care about:

    QEMU virtual USB device → xHCI controller → Ceylon HID provider → semantic input service → bounded transport → NuGUI

    No shortcut that writes fake mouse movement directly into the GUI.

    No host-side test pretending to be the target.

    No "we proved the parser works, therefore the desktop works."

    The complete keyboard and pointer transport passed.

    Then it stayed up under an 11-minute soak.

    The broader workspace test run completed:

    480 tests, 0 failures.

    And the existing Nu-Iris R2 through R8 regression sets stayed green.

    That last part matters because input work should not quietly damage the display path while everybody is celebrating that the mouse moved.

    So this is a genuine milestone.

    Not "pointer code exists."

    Not "a cursor twitched."

    The underlying interactive path is now behaving like something we can build on.

    Next comes focus, which sounds easier than it is

    The next NuGUI step is focus routing and static application activation.

    That sounds almost trivial.

    Click a window.

    That window gets input.

    Launch an application.

    It becomes active.

    Done.

    Except operating systems have a way of turning every sentence containing the word "just" into a week of work.

    Focus has to answer questions like:

    Which application owns keyboard input right now?

    What happens when a window disappears?

    What happens when an application crashes?

    Can stale input reach a replacement instance?

    What happens when pointer focus and keyboard focus differ?

    What does activation mean if the application has restarted?

    Those are not glamorous questions.

    But they are the difference between a desktop that usually works and one that occasionally types your command into the wrong application.

    The important part is that we have reached that layer now.

    We are no longer debugging whether QEMU can produce a pointer packet.

    We are deciding what the operating system should do with it.

    That is progress.

    Then I went looking for Asteroids

    A1 Alpha is supposed to include a simple Asteroids-style demo as a lightweight native proof-of-life application.

    The idea is deliberately modest.

    Juggernaut is the heavier game workload.

    Asteroids is supposed to answer a much simpler question:

    Can Ceylon run a small, responsive native arcade application cleanly?

    Input.

    Timing....

    Read more »

  • Project Ceylon Development Log — September 29, 2026: The Website Is Real. So Is the Next Display Bug.

    Mike • 09/30/2026 at 05:43 • 0 comments

    Mike · September 29, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, Nu-Iris, Display Architecture, Website, Build in Public, QEMU

    Yesterday I wrote that Project Ceylon finally had a front door.

    Today I actually moved some furniture in.

    The new Ceylon site is no longer just a landing page saying, essentially, "yes, this project exists."

    It now has the beginnings of a real public archive: project information, the development journal, supporting pages, and the plumbing needed to keep publishing without hand-editing a static page every time I do something questionable to the operating system.

    And while that was happening, Nu-Iris finally crossed an important line.

    R4 was promoted.

    Then R5 immediately found another problem.

    So the day ended with the public side of Ceylon looking considerably more finished and the display stack reminding me, once again, that appearances are dangerous.

    Seems appropriate.

    The website became a project site

    The biggest visible change today is at:

    ceylonprojectng.com

    Yesterday it was a proof that the routing, certificates, hosting and deployment worked.

    Today it is much closer to what I actually wanted:

    a real home for Project Ceylon.

    The development journal has been brought over so the project history can live with the project instead of existing only as a scattered collection of posts elsewhere.

    The current site now has the pieces I expect from a proper technical project:

    • a public project overview;
    • development-journal archive;
    • individual journal pages;
    • responsive layouts;
    • RSS;
    • sitemap support;
    • sensible navigation;
    • pages that remain readable even without JavaScript;
    • a publishing boundary between public work and things that are not ready to be public.

    That last one got tested harder than the pretty pages did.

    Good.

    Publishing has failure modes too

    Once you have a site backed by real content, the dangerous question becomes:

    What can accidentally become public?

    Drafts should not appear.

    Unpublished material should not leak into archive pages.

    Private or unannounced research should not wander into RSS.

    A page that has been deliberately withheld should not show up because somebody forgot one filter in one renderer.

    So the publishing path got tested the same way I increasingly test the OS:

    not just by asking whether the expected thing works,

    but whether the thing that is not supposed to happen stays impossible.

    One deliberately missed leak was found during that work.

    It was fixed.

    Then the site was checked again across the normal pages, archive, RSS, and sitemap behavior.

    That matters to me because I want the development journal to remain pretty open.

    Research into things I have already publicly discussed can be written about as research, even when the idea later gets discarded.

    That is part of the point of building this thing in public.

    But "building in public" does not mean "publish every unfinished thought, internal note, or unannounced project because a content query happened to find it."

    There still has to be a boundary.

    Now the site has one.

    The journal is becoming part of the engineering record

    Something else happened once all of these entries started living together.

    The journal stopped feeling like a sequence of blog posts and started looking like a development history.

    That is useful.

    You can see the project change its mind.

    You can see Nu-Day turn into Ceylon.

    You can see early assumptions fail.

    You can see First Light happen and then later learn what First Light actually proved.

    You can see storage break for reasons that had nothing to do with storage.

    You can see the Alpha scope get smaller and more concrete.

    And you can see just how often a supposedly minor question turns into a week of architecture work.

    I like that.

    I do not want to rewrite the history into a neat story where every early decision was obviously leading to the current design.

    It wasn't.

    Some of this has been exploration....

    Read more »

  • Project Ceylon Development Log — September 28, 2026: Ceylon Got a Website. Then We Started Talking About Robots.

    Mike • 09/29/2026 at 03:51 • 0 comments

    Mike · September 28, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, Local-First, Federation, Real-Time, Robotics, Nu-Iris

    Today Project Ceylon got a real home on the web.  And then, because apparently I am incapable of doing one normal thing at a time, the day wandered through local-first computing, federation, real-time scheduling, CNC controllers, Raspberry Pis, Roombas, and the possibility of building an actual robot running Ceylon.

    So this one may be a little all over the place.

    In other words, fairly representative of the project.

    Ceylon finally has its own front door

    The new public site is now up at:

    ceylonprojectng.com

    There is also a new site for the parent company at:

    inspirebycraft.com

    Both are currently simple landing pages.

    That is intentional.

    I wanted the routing, hosting, certificates, and deployment path proven before turning either one into a giant content-management project.

    The new sites are running through the same established Cloudflare Tunnel infrastructure already serving The Weekenders Project, without disrupting the existing site.

    That was the first goal:

    put the new doors on the building without knocking down the house next door.

    Done.

    The next stage will be turning the Ceylon site into the proper project home instead of relying on Hackaday alone.

    Hackaday is still where I want this development journal and the contest-facing build story to live.

    The Ceylon site can do the slower-moving jobs:

    • explain what the project is;
    • maintain architecture and roadmap material;
    • provide downloads when we reach that point;
    • host documentation;
    • collect project history;
    • eventually support Alpha feedback and release information.

    For the moment, though, it exists.

    That feels surprisingly significant.

    Ceylon has spent most of its life as source trees, specifications, QEMU windows, terminal logs, and increasingly questionable amounts of coffee.

    Now it has an address.

    The project identity is getting clearer too

    Putting up a public site forced another useful exercise:

    How do I explain what all of these names actually mean?

    The structure is becoming fairly simple.

    Inspire by Craft is the parent maker company.

    The IBC Systems Division is the computing side.

    Project Ceylon is the operating-system and workstation program.

    And The Weekenders Project is a separate community project under the same parent.  That probably sounds like corporate housekeeping.

    It is.

    But names start mattering once you expect people other than yourself to look at what you are building.

    The parent-company line also finally settled into something that feels like me:

    Jack of all trades. Master of some. Makers of things. Some pretty. Some useful. Some pretty useful.

    That is probably a better description of how I got into this mess than any mission statement I could write.

    Local-first is becoming more than a preference

    Yesterday I wrote about wanting Ceylon to remain useful without depending on a remote service to grant the computer permission to exist.

    Today that turned into more concrete federation work.

    The question was:

    How should two or more Ceylon machines work together without turning the whole system into a cloud product?

    The answer is starting to take shape as three levels:

    Standalone → Fed-Light → Managed Federation

    Standalone is exactly what it sounds like.

    The machine works by itself.

    Fed-Light is the interesting middle ground.

    Two nearby Ceylon systems should be able to discover one another, explicitly establish trust, and share selected services or resources without requiring a central management server.

    No "every machine on the LAN is automatically trusted."

    No ambient network authority.

    Discovery can happen automatically.

    Trust cannot.

    That should require an intentional adoption step.

    Once adopted, the systems can negotiate permissions, attach to allowed services, and revoke that relationship later.

    Then,...

    Read more »

  • Project Ceylon Development Log — September 27, 2026: Apparently Housekeeping Is Systems Engineering Too

    Mike • 09/28/2026 at 05:59 • 0 comments

    Mike · September 27, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, NuGUI, Workpad, Local-First, Development Process

    Today I deleted almost 300 GiB of Project Ceylon development debris.

    And somehow that turned into a desktop-design discussion.

    That sounds about right.

    The short version is that the machine had accumulated months of build trees, validation copies, temporary workspaces, old artifacts, abandoned experiments, duplicated toolchains, test images, and assorted other things that all made perfect sense when they were created and considerably less sense after they had been sitting there for a while.

    The filesystem had reached about 77% used.

    By the time the cleanup was finished, it was down around 53>#/strong###.

    Free space went from roughly 300 GiB to 600 GiB.

    And, most importantly:

    the canonical Ceylon source stayed exactly where it was supposed to be.

    That last part is what made the cleanup interesting.

    Deleting files is easy.

    Deleting the right files in an operating-system project without quietly throwing away the one copy of something important is a different job entirely.

    "rm -rf" was not the plan

    The cleanup was deliberately conservative.

    Every candidate had to earn the right to be deleted.

    Build trees?

    Probably disposable.

    Generated output?

    Usually disposable.

    Temporary validation copies?

    Maybe.

    A directory that looks temporary but contains tracked source?

    Absolutely not.

    That distinction caught one remaining root-owned workspace that otherwise looked like cleanup material.

    The deletion process checked it against the canonical repository, found tracked source inside it, and kept it.

    Exactly what I wanted.

    By the end of the run, 391 out of 392 residual root-owned paths were removed.

    The one exception was preserved because it still contained canonical source.

    That is a much better result than "we deleted everything and the machine still seems to boot."

    Cleanup found things I actually wanted to keep

    The more useful surprise came before the final deletion pass.

    A proper inventory of the old workspaces found a few pieces of engineering work that had not yet been cleanly reconciled back into the main project.

    That is the dangerous part of long-running experimental development.

    You make a fix in a validation tree.

    Then another fix in another tree.

    Then a branch exists because you were trying to prove one very specific thing at 2:00 AM.

    A week later, the fix is good, the test passed, everybody remembers the result...

    ...and the actual source of truth may not yet contain the thing that produced it.

    That is how projects slowly become folklore.

    So before anything was removed, the cleanup process stopped and identified those unique changes.

    No merging by accident.

    No "well, I think this one was already included."

    No guessing.

    The cleanup became a reconciliation exercise before it became a deletion exercise.

    That may be the least glamorous sentence I have ever written for Hackaday.

    It is also probably one of the more important ones.

    This project is getting too big to rely on memory

    I have a decent memory for how Ceylon got here.

    That is not the same thing as having a process.

    As the project has grown, I have become increasingly suspicious of statements that begin with:

    "I'm pretty sure..."

    I'm pretty sure that patch was incorporated.

    I'm pretty sure that workspace is obsolete.

    I'm pretty sure that toolchain is the current one.

    I'm pretty sure we qualified that exact image.

    No.

    "Pretty sure" is how six months from now becomes miserable.

    The system now has enough moving parts that provenance, reconciliation, qualification evidence, and cleanup discipline are becoming part of the engineering itself.

    Apparently housekeeping is systems engineering too.

    I did not expect that to become one of the themes of this project, but here we are.

    Meanwhile, I have been thinking about the desktop again

    The cleanup work was not the only thing happening today.

    I...

    Read more »

  • Project Ceylon Development Log — September 26, 2026: Remember That Day Off I Was Going to Take?

    Mike • 09/27/2026 at 09:57 • 0 comments

    Mike · September 26, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, Nu-Iris, NuGUI, Display Architecture, Debugging, Hardware

    Remember yesterday when I said I was probably going to take a day or two off?

    Yeah.

    About that.

    I did not take the day off.

    Instead, I went looking at Ceylon's display architecture and discovered that one of the project's oldest visible milestones was both completely real and not quite what we thought it was.

    Which is a very Project Ceylon way to spend a Saturday.

    The short version is this:

    First Light was real. NuGUI really did put graphical output on the screen.

    But the live path that produced those pixels did not travel through Nu-Iris the way the architecture said it eventually should.

    We had graphics.

    We had the screenshot.

    We had a working visible result.

    What we did not yet have was proof that Nu-Iris itself was actually the presentation authority for that result.

    That distinction turned out to matter a lot.

    First Light still counts

    I want to start there, because it would be easy to overcorrect this story.

    Ceylon's First Light milestone was not fake.

    Pixels appeared on screen through Ceylon code running in the QEMU machine.

    NuGUI produced visible graphical output.

    That happened.

    What changed today is our understanding of how those pixels got there.

    The live path was effectively:

    NuGUI → shared display memory → notification → PCI/display service → Bochs framebuffer

    The standalone Nu-Iris service and its intended onboard presentation path were being bypassed.

    So the mistake was not:

    "We thought we had graphics, but actually we didn't."

    The mistake was:

    "We treated visible graphics as stronger evidence about the architecture than it really was."

    Those are very different problems.

    One is embarrassing.

    The other is useful.

    This one is useful.

    A screenshot can prove less than you think

    This may sound like nitpicking.

    After all, if the pixels showed up, who cares which service touched the framebuffer?

    I care.

    Because Nu-Iris is supposed to become Ceylon's display and presentation subsystem.

    That means it eventually needs to own things such as:

    • presentation authority
    • buffer ownership
    • frame publication
    • backpressure
    • stale-frame handling
    • pacing
    • damage tracking
    • software-rendering presentation
    • future accelerated presentation
    • multiple output providers
    • media-oriented surfaces
    • failure and restart behavior

    If NuGUI can quietly bypass all of that and write through a lower-level path, then Nu-Iris can look complete while the actual desktop is not using it.

    That is exactly the kind of architectural drift I have been trying to prevent elsewhere in the system.

    So once we found it, the answer was not:

    "Well, the picture appeared, so close enough."

    The answer was:

    Stop. Figure out what is actually live. Document it. Then fix the architecture deliberately.

    The current display path is very old-school

    The audit also showed just how primitive the current Bochs presentation path still is.

    And I mean that affectionately.

    Sort of.

    The current path copies a full framebuffer using straightforward CPU writes.

    At 1024×768 with 32-bit pixels, that is 3,145,728 bytes for a full frame.

    There is no sophisticated damage system avoiding unnecessary work.

    No page flipping.

    No DMA presentation path.

    No SIMD-optimized copy path.

    No modern zero-copy surface handoff.

    No clever hardware acceleration hiding underneath it.

    It is basically:

    Here are the pixels. Move the pixels.

    And you know what?

    For First Light, that was fine.

    The problem is not that the early implementation was simple.

    The problem would be pretending that the early implementation is the architecture we want to carry forward.

    It isn't.

    So Nu-Iris just became its own modernization project

    This is one of those moments where fixing one discovery turns into a new development tranche.

    The immediate job is not "make Iris faster."

    The immediate job is more basic:

    make the live desktop actually use Nu-Iris...

    Read more »

  • Project Ceylon Development Log — September 25, 2026: Okay, So What Exactly Is A1 Alpha?

    Mike • 09/26/2026 at 07:31 • 0 comments

    Mike · September 25, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, A1 Alpha, NuBASIC, Juggernaut, Audio, Applications

    One of the problems with building an operating system in public is that eventually somebody asks a perfectly reasonable question:

    "So what exactly is in the first release?"

    And for a while, my answer to that was basically:

    "Well... a lot of things."

    Which is not a release plan.

    It is a shopping list with optimism attached.

    Over the last couple of days, Ceylon has finally reached the point where I needed to stop treating A1 Alpha as a vague future event and define what it actually means.

    Not the final A1 release.

    Not the later commercial hardware version.

    Not every application I eventually want.

    The first proof-of-life release somebody besides me will be able to boot inside QEMU, use for a while, complain about, break in unexpected ways, and hopefully understand well enough to tell me what is wrong with it.

    That turned into a much bigger conversation than I expected.

    Because once you define the first release honestly, you have to answer two questions:

    1. What absolutely has to be there?
    2. What are we willing to admit is not there yet?

    Today was mostly about answering those.

    Alpha is not the finish line

    The first thing I needed to get straight in my own head was what the word Alpha means for Ceylon.

    A1 Alpha is not a miniature version of the final operating system.

    It is a checkpoint inside A1.

    The sequence is more like this:

    A1 Alpha → feedback → fixes → continue A1 → freeze the intended A1 environment → then begin B1 hardware work

    That distinction matters.

    The A-series is the virtual/reference-machine line.

    The B-series is where Ceylon eventually moves onto certified physical hardware.

    So I do not need to drag every future B-series requirement backward into the first Alpha just because I know it will matter someday.

    That would be a fantastic way to make sure Alpha never ships.

    The Alpha has one job:

    prove that Ceylon has become a usable computer instead of a collection of qualified subsystems.

    That is the line I am trying to cross.

    Authentication almost became one of those things that blocked everything

    Authentication is a good example of where defining Alpha helped.

    Ceylon absolutely needs real authentication.

    The full A1 release will have it.

    But does the first Alpha need to boot into a login screen and refuse to do anything until the entire authentication path is production-complete?

    After looking at what Alpha is actually for, the answer is no.

    The Alpha will boot under a defined local alpha principal.

    That does not mean "accept anything somebody types into a password box."

    It means authentication is not required to prove the desktop, applications, storage, audio, development environment and interaction model.

    The full A1 still requires the real authentication system.

    Alpha does not.

    That one decision removes a major dependency from the proof-of-life path without weakening the architecture we are actually building.

    There is a difference between postponing a feature and pretending it does not matter.

    This is the first one.

    So what actually ships?

    This was the useful part.

    Instead of saying "desktop and some apps," I finally locked the initial Alpha application list.

    The basic system needs:

    • NuGUI
    • NuDOS
    • Ceylon Terminal
    • File Manager
    • basic Settings/System Information
    • a Welcome/Help application

    That gives somebody an actual machine to navigate.

    Then the development side:

    • NuBASIC Level 1
    • a simple source/text editor

    I have said before that NuBASIC matters to me.

    I grew up in an era where getting a computer home usually meant you also got a way to make the computer do something yourself.

    I want some of that back.

    Not because BASIC is the only language Ceylon should ever support.

    Obviously it isn't.

    But because a first-time user should be able to boot the Alpha, open the programming environment, type something, run it and immediately understand that this...

    Read more »

  • Project Ceylon Development Log — September 24, 2026: 55 Out of 55 Passed. Then We Found the Test Was Wrong.

    Mike • 09/25/2026 at 05:14 • 0 comments

    Mike · September 24, 2026

    Tags: Project Ceylon, Retrocomputing, Operating Systems, NuGUI, Debugging, Testing, QEMU

    Yesterday I wrote that "worked once" is no longer one of our engineering states.

    Apparently Ceylon took that personally.

    Today we got NuGUI through 55 out of 55 requirements.

    The compositor was producing reproducible pixels.

    Client crash containment worked.

    Bad handles were rejected.

    The negative tests passed.

    The independent review looked good.

    For a little while, it looked like we had reached the point where the new NuGUI work could be promoted into the main Ceylon line.

    Then we did the reconciliation work.

    And storage disappeared.

    Not "a disk test was flaky."

    Not "one read failed."

    Both drives were being rejected.

    The really irritating part?

    One of the smoke tests had already told us storage passed.

    It was wrong.

    That, more than anything else, is what today's work was about.

    First, the good news: NuGUI really did make a lot of progress

    I do not want the later failure to erase what actually worked.

    NuGUI's current D2 work is a substantial step forward.

    The compositor is no longer just an architectural sketch with a few pieces hanging off it.

    We now have bounded per-client resources.

    We have shared ring behavior with explicit ordering.

    We have damage-carrying presentation.

    We have real client-fault containment.

    We have stale-handle rejection.

    We have visible target output.

    And we have been deliberately testing what happens when applications misbehave instead of assuming polite applications forever.

    One of today's more satisfying tests involved deliberately crashing a client with a real invalid-instruction fault.

    Not once.

    Three times.

    The compositor survived.

    Another client kept running.

    The stale client handles were rejected afterward.

    That is exactly what I want from the architecture.

    If one application falls over, the desktop should not throw itself down the stairs in sympathy.

    The test suite also reached 55/55 requirements for the D2 scope.

    That is a real milestone.

    But it turns out there is a difference between:

    "This component passed its requirements."

    and:

    "This entire set of changes is safe to promote into the operating system."

    Today was mostly about that difference.

    Promotion is where things got interesting

    The D2 work is not a tiny patch.

    It spans 29 commits and more than a hundred files.

    Along the way, pieces of the low-level development environment changed too: SDK pieces, kernel-facing dependencies, Rust support, launch configuration and some older diagnostic paths.

    That does not automatically make the work wrong.

    But it does mean promotion cannot be treated like copying one compositor binary into a directory and calling it done.

    The question became:

    What exactly are we promoting?

    And more importantly:

    What assumptions changed underneath the part we were actually testing?

    That is where storage raised its hand.

    The smoke test said storage passed

    During reconciliation, both storage devices were rejected.

    That should have been impossible according to the smoke result.

    So we did what you do when the machine and the test disagree:

    we assumed the test was guilty until proven innocent.

    It was.

    The smoke check was not actually proving that usable volumes had been published.

    It was counting the presence of expected-looking log activity.

    Those are not the same thing.

    A system can print a line that looks encouraging while still failing the actual thing the line was supposed to represent.

    That sounds painfully obvious when written down.

    It is also exactly the kind of mistake automated testing can hide beautifully because the output is green and everybody wants to move on.

    The corrected question is not:

    Did storage print the right message?

    It is:

    Did the expected volumes actually appear and remain usable?

    That is what the test should have been asking in the first place.

    So today we got one of those wonderful development milestones that...

    Read more »

View all 47 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

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