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.

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 — September 21, 2026: Turning a Working System Into a Trustworthy One

    Mike2 hours ago 0 comments

    Mike · September 21, 2026

    Tags: Project Ceylon, Operating Systems, NuGUI, Kirk, Systems Engineering, QEMU, Development Log

    Today was one of those days where Project Ceylon kept answering one question with another.

    The good news is that the questions are getting better.

    A few weeks ago, most of the work was still about proving that individual pieces could function at all.

    Can the machine boot?

    Can a service start?

    Can storage respond?

    Can the keyboard produce an event?

    Can one isolated component communicate with another?

    Those are still important questions, but they are no longer enough.

    The questions now sound more like:

    Can this service be trusted as a dependency?

    Can it recover if something disappears underneath it?

    Can we reproduce the machine configuration tomorrow?

    Does the thing we call the “production path” actually match what the virtual hardware is doing?

    And when we start building the desktop on top of all this, are we building on real foundations or accidentally cementing test code into the operating system?

    That was the theme of September 21.

    Kirk Moves Into Long-Duration Qualification

    One of the biggest milestones today involved Kirk, Ceylon’s local service-discovery and coordination layer.

    Kirk exists so applications and services do not need to know everything about each other ahead of time.

    It handles things such as service discovery, provider identity, generations, lifecycle changes, capability negotiation, attachments, detachments, revocation, and reconnection.

    It is deliberately not the data pipe for everything.

    Audio samples do not go through Kirk.

    Pixels do not go through Kirk.

    High-frequency mouse movement does not go through Kirk.

    Kirk is the control plane.

    That distinction is important because it allows the operating system to coordinate independently developed services without turning one component into a giant central bottleneck.

    Today Kirk completed the remaining bounded functional tests needed before the long-duration qualification stage.

    That included stress testing, capacity edges, unauthorized requests, malformed requests, revocation, reincarnation, isolation between services, and repeated boot verification.

    The result was strong enough that Kirk is now provisionally approved for application-development integration.

    That does not mean final qualification is complete.

    The remaining test is an autonomous eight-hour active soak that is currently running independently. During that run, the system is collecting evidence about memory stability, latency, structured logging behavior, resource use, and continued functionality after sustained operation.

    Most importantly, the test is autonomous.

    Nobody is sitting there babysitting it for eight hours.

    It starts, exercises the service, records checkpoints, gathers measurements, and will produce a final evidence package when it finishes.

    That is how this kind of qualification should work.

    We Audited the Foundation Before Building More on It

    With Kirk running in the background, I did not want the rest of the project sitting idle.

    So the next task was a full A1 production-readiness baseline.

    The question was simple:

    What can we safely build on right now?

    Thirty-two platform services and facilities were inventoried.

    Every one of them was classified according to its actual maturity rather than how much I might want it to be finished.

    That distinction matters.

    The audit did not hand out “production ready” labels just because something compiled or worked once.

    Instead, the services were examined for things such as:

    • authority and security boundaries,
    • restart behavior,
    • generation handling,
    • shared-memory semantics,
    • queue bounds,
    • failure behavior,
    • target evidence,
    • logging,
    • resource behavior,
    • provenance,
    • and what higher-level software depends on them.

    The result was not a wall of green checkmarks.

    In fact, nothing was classified as fully production complete...

    Read more »

  • 33 — Ceylon Development Log — September 20, 2026: Back to Solid Ground

    Mikea day ago 0 comments

    Development window: September 20, 2026

    The last several days of Project Ceylon development have been dominated by one job: getting the system back to a known, reproducible state after moving the underlying MicroKernel platform forward.

    By mid-afternoon on September 20, we had already proven quite a bit.

    The new stack booted. Multiprocessing worked. The IOMMU was operational. The system controller started. PCI enumeration worked. USB worked. The random-number service initialized. Both block devices initialized.

    That sounds like a nearly finished migration.

    It wasn't.

    What followed was several hours of discovering just how many small assumptions can accumulate around a working machine — and how moving one layer underneath them can expose assumptions that had been invisible for months.

    The encouraging part is that, by the end of the night, Ceylon was back on solid ground.

    Not just "it booted once."

    We now have a repeatable baseline.

    One Migration Problem, Twenty-Seven Rust Targets

    One of the first major discoveries concerned the IPC buffer used by Ceylon's Rust components.

    The older platform arrangement placed that buffer at one address. The new MicroKernel environment places it much higher in the process address space.

    A stale linker assumption remained in Ceylon's Rust target profiles.

    That sounds small. It wasn't.

    The same assumption existed across 27 Rust target profiles, which meant what initially looked like several unrelated failures could actually share one cause.

    We corrected the integration centrally.

    Representative binaries then resolved the IPC buffer at the proper new address, the previous memory fault disappeared, and the controller continued to run normally.

    More importantly, another failure disappeared with it.

    The RNG interface, which had previously faulted during testing, completed 256 out of 256 stress requests successfully.

    That was a useful reminder of a rule we've increasingly adopted during this migration:

    Fix the version contract first. Diagnose individual services second.

    The RNG wasn't broken.

    Storage wasn't suffering from the same memory failure anymore.

    One platform assumption had been wrong in several places.

    Then the PCI Addresses Moved

    With the IPC issue corrected, storage progressed further — only to stop at PCI resource admission.

    The addresses assigned to the block controllers no longer matched Ceylon's expected platform profile.

    At first that looked like another configuration mistake.

    It turned out to be more interesting.

    Earlier testing had consistently produced one set of PCI BAR addresses. The new runs consistently produced another.

    We reproduced the new layout with identical QEMU machine inputs and then traced the first divergence back through the boot process.

    Ceylon wasn't moving them.

    The firmware was.

    The earlier environment had been using SeaBIOS 1.16.2. The current environment was using SeaBIOS 1.16.3.

    That release includes changes in PCI resource allocation, and our testing showed the resource map changing before Ceylon executed its platform-service code.

    That distinction mattered.

    This wasn't a Ceylon driver changing addresses incorrectly.

    It was the machine presented to Ceylon changing underneath it.

    Turning the SeaBIOS Problem Into Research

    Instead of immediately reverting the firmware, we stopped and asked a different question:

    Could the new behavior be useful?

    If firmware is responsible for assigning PCI resources, perhaps Ceylon shouldn't duplicate those assignments as handwritten constants forever.

    So we ran a bounded feasibility experiment.

    The exact QEMU, SeaBIOS and device topology was booted ten separate times.

    Every run produced the same normalized PCI resource manifest.

    Ten out of ten. Identical.

    We then deliberately changed the PCI topology by adding an HDA audio device.

    The resource layout changed predictably.

    We removed it.

    The original manifest returned.

    That established something potentially useful for later development:...

    Read more »

  • 32 — Ceylon Development Log — September 19, 2026: The Controller Was Ready. It Still Wouldn’t Run.

    Mikea day ago 0 comments

    Mike · September 19, 2026 Work continued through approximately 5:00 AM Central, September 20.

    Tags: Project Ceylon, Workshop, MicroKernel, Scheduling, Debugging, Hackaday, A1 Alpha

    Today I submitted Project Ceylon to the Hackaday Retrocomputing Contest.

    And then, almost immediately, Ceylon reminded me why I am writing this development journal instead of waiting until everything is polished and pretending the path was obvious.

    A controller that should have started did not.

    Not crashed.

    Not faulted.

    Not obviously misconfigured.

    It just sat there.

    That turned the rest of the day — and quite a bit of the night — into one of those debugging sessions where the useful result is not a dramatic fix.

    It is eliminating one wrong explanation after another until the problem finally becomes small enough to understand.

    First, the public side

    The Hackaday project page got a fairly substantial cleanup today.

    I uploaded the current architecture and progress graphics, clarified the staged alpha plan, and added an older framebuffer capture as historical proof that Ceylon has already produced native graphics under QEMU.

    That image is the project's earlier First Light milestone.

    First Light did not happen today.

    The important distinction is that the Hackaday page now has more evidence of what already exists instead of relying mainly on descriptions of where the project is going.

    The alpha plan also became clearer.

    The first A-series release will go to a small curated group of technical testers. The things they break, misunderstand or expose will be addressed before a broader public QEMU evaluation.

    That is slower than throwing an image onto the Internet and calling it an alpha.

    I think it is also more useful.

    Then the controller refused to start

    The main engineering problem today was a controller Protection Domain that never produced its expected startup marker.

    The first obvious question was whether I had simply failed to start it.

    That would have been convenient.

    The generated configuration said otherwise.

    The controller had the correct resume flag.

    The system initializer could see it.

    It was included in the generated startup collections.

    Its executable was loaded.

    Its scheduling context was present.

    The initializer attempted to start it.

    The child identifier was valid.

    So the easy explanation disappeared.

    The machine thought this thing should exist.

    The question became:

    What does the MicroKernel think the controller is actually doing?

    Looking inside the running system

    A diagnostic observation finally gave us the controller's kernel-visible state.

    Its instruction pointer was sitting exactly at its generated entry point:

    0x2025d8

    Its stack pointer looked correct.

    Its priority was 199.

    It was assigned to CPU 0.

    Its scheduling context was bound.

    Most importantly, its thread state was Restart — a runnable/startable state.

    That was a significant result.

    The controller was not inactive.

    It was not blocked waiting on a message.

    It was not sitting in a fault state.

    And it had not wandered halfway through startup before failing.

    It appeared to have never moved from the front door.

    A bad observation can be worse than no observation

    The next scheduler snapshot initially looked suspicious.

    The controller was still waiting while a higher-priority supervisor was running.

    Except the supervisor was still inside its own initialization routine when the snapshot was taken.

    That means the observation itself was too early.

    A priority-250 thread running while a priority-199 thread waits is not evidence of a scheduler bug.

    It is the scheduler doing exactly what it was told to do.

    So that result was classified as an observation-timing problem, not a system failure.

    That may sound like splitting hairs.

    It is not.

    One of the easiest ways to manufacture a fake operating-system bug is to instrument the system in a way that changes the thing you are trying to observe.

    So we stopped and changed the observation...

    Read more »

  • 31 — Ceylon Development Log — September 18, 2026: Why an Operating System Needs a Game

    Mike2 days ago 0 comments

    Mike · September 18, 2026

    Tags: Project Ceylon, Workshop, Games, Developer Platform, Research, A1 Alpha

    Today Ceylon's first native game stopped being a side idea and became something much more useful: a plan for a real application that can entertain people, stress the operating system, test recovery, and teach us how third-party software should be built on the platform.  We are not ready to start building it yet, but we did the research to build one once we reach the point we are ready for one.

    Project Ceylon Nightly: Why an Operating System Needs a Game

    There is an easy way to demonstrate an operating system.

    Draw a window.

    Put some text in it.

    Move a mouse cursor.

    Play a sound.

    Save a file.

    Those are all important milestones, and Ceylon needs them.

    But eventually a collection of technical demonstrations stops answering the harder question:

    Can this machine actually run something interesting?

    That is why I have been spending time on a native game for A1.

    Not a port.

    Not a browser game.

    Not an SDL demo quietly carrying another operating system's assumptions underneath it.

    A real Ceylon application.

    Why a game is a useful systems test

    Games are brutal in useful ways.

    People notice input lag immediately.

    They notice timing glitches.

    They notice dropped frames.

    They notice audio hiccups.

    They notice when controls feel wrong.

    They notice when a pause in storage, logging or background work interrupts the foreground experience.

    A benchmark can tell me that Ceylon completed a million operations.

    A game can tell me whether graphics, input, audio, timing, memory, storage, scheduling and application lifecycle can all cooperate while somebody is actively using the machine.

    That is much more interesting.

    The goal is not to write a fake game whose only purpose is to tick API boxes.

    If we do this, I want the game to actually be worth playing.

    That matters because an entertaining game creates design pressure that a technical demo does not.

    Controls have to feel good.

    The world has to make sense.

    Difficulty has to be fair enough that people can learn.

    Sound has to communicate something.

    The graphics have to remain readable under pressure.

    Those are human-factors tests as much as software tests.

    The research started with Sinistar, but it did not stop there

    The historical starting point was Williams' Sinistar.

    Not because I want to remake Sinistar.

    I do not.

    What fascinated me was how much that game managed to do on extremely small hardware.

    The world did not simply wait for the player.

    Workers collected resources.

    Other enemies hunted you.

    The larger threat was being assembled while you were busy elsewhere.

    The player was constantly deciding between the problem directly in front of the ship and the bigger problem developing somewhere else.

    And under all of that, the programmers built a tiny multitasking-style executive to coordinate the game's independent behaviors.

    That is the part I care about.

    They were not building a miniature operating system because that sounded clever.

    They were solving a game-design problem: how do you make many things appear alive at once when the machine cannot afford heavyweight machinery for every object?

    That is a remarkably relevant question for Ceylon.

    Looking beyond one game

    One of today's research goals was deliberately broadening the survey so the new game does not become "Sinistar with different artwork."

    I have been looking at preserved source and development material from a number of early games and asking what each one did unusually well.

    Defender made a world larger than the viewport and compressed that world into a useful radar display.

    Robotron produced overwhelming actor density while keeping the player's controls extremely crisp.

    Joust got enormous depth from a tiny control vocabulary and a good movement model.

    Tempest treated demo and self-test behavior as part of the machine rather than as an afterthought.

    Missile Command used hard...

    Read more »

  • 30 — Ceylon Development Log — September 17, 2026: When a Crash Needs to Leave Evidence

    Mike2 days ago 0 comments

    Mike · September 17, 2026

    Tags: Project Ceylon, Workshop, Logging, Fault Recovery, Systems Engineering, Research

    A real fault exposed an important distinction today: Ceylon can detect and contain a crashed component, but that is not enough. If the machine is going to recover from failures, it also needs to remember exactly what happened.

    Project Ceylon Nightly: When a Crash Needs to Leave Evidence

    Today started with something that, on the surface, looked encouraging.

    One of Ceylon's isolated execution components hit a real illegal-instruction fault.

    The system detected it.

    The fault stayed contained.

    The rest of the machine did not fall over with it.

    That is exactly the kind of behavior a componentized operating system is supposed to provide.

    But the fault also exposed a hole.

    Ceylon knew what had happened well enough to print useful information to the debug serial console, yet the same information never entered the structured logging path we have been building for the operating system.

    In other words, the architecture worked well enough to catch the failure, but the evidence stopped at the equivalent of somebody yelling across the workshop.

    That is not good enough for the system Ceylon is intended to become.

    The difference between a debug message and an incident record

    Serial output is incredibly useful while an operating system is under construction.

    It is simple.

    It is immediate.

    When something goes wrong at a very low level, there is a good chance the serial console is still alive.

    I do not want to get rid of it.

    But serial output is not a durable incident history.

    If a component faults, gets reclaimed, and is restarted, I eventually want to be able to answer questions such as:

    What fault happened?

    Which exact component instance failed?

    Which build was running?

    What instruction or address was involved?

    What did the supervisor decide to do?

    Was the component reclaimed?

    Was it restarted?

    Did the restart succeed?

    Did any diagnostic information get dropped along the way?

    A line of text on a debug console cannot answer those questions reliably after the fact.

    A structured incident record can.

    The good news: the logging architecture is not broken

    The useful discovery today is that we do not need to throw away Ceylon's logging system and start over.

    The existing design already has most of the right ingredients.

    Ceylon has bounded shared-memory error transport.

    It has explicit drop accounting.

    It has a collector boundary separate from the producer.

    It has a path for structured records to reach durable storage.

    That part is important because I do not want a faulting or supervising component trying to perform filesystem I/O while it is dealing with a failure.

    The intended path remains:

    component or supervisor → bounded shared-memory record → collector → durable local log → management/query tools

    The problem is much narrower.

    The execution-manager fault path never enters it.

    Right now that path effectively looks like:

    fault → supervisor → debug serial

    What it needs to become is:

    fault → supervisor → structured fault event → bounded error mailbox → collector → durable incident record

    Serial can remain as a secondary human-readable path.

    It simply cannot be the only record.

    One fault should become one coherent story

    Once I started looking at this, it became obvious that simply logging "component crashed" is not enough either.

    Ceylon is being designed around restartable, generation-safe resources.

    That means one execution slot may host one component instance, be reclaimed, and later be reused for another instance.

    So a useful fault report needs to identify more than a slot number.

    It needs to identify the exact generation of the thing that failed.

    It also needs a correlation identifier so we can connect the complete lifecycle:

    FAULT OBSERVED ↓ CONTAINMENT ↓ RECLAIM ↓ RESTART ATTEMPT ↓ NEW GENERATION ↓ RECOVERY SUCCEEDED / FAILED / QUARANTINED

    That turns a collection of unrelated...

    Read more »

  • 29 — Ceylon Development Log — September 16, 2026: Static Foundations, Dynamic Systems

    Mike2 days ago 0 comments

    *Mike · September 16, 2026*

    **Tags:** Project Ceylon, Workshop, Microkernel, Virtual Memory, Systems Engineering

    ---

    Ceylon is learning how to become dynamic without abandoning a static, bounded and predictable foundation: leased execution workers, mirrored VSpace cohorts, bounded page capabilities, and a capability-pool question still open.

    ## Project Ceylon Nightly: Static Foundations, Dynamic Systems

    Today was one of those days where the most important progress was not a new screen, a new driver, or another user-facing feature.

    It was figuring out what the machine underneath all of those things needs to become.

    Over the last several development cycles, Ceylon has been moving onto an updated microkernel foundation and a newer generation of its surrounding system-construction tooling. That upgrade brought substantial capabilities with it, but it also invalidated a few assumptions that had quietly worked their way into the earlier architecture.

    That forced us to stop and answer a more fundamental question:

    How dynamic can Ceylon become while preserving a system that is deliberately static, bounded, isolated and predictable at its foundation?

    The answer is turning out to be: surprisingly dynamic.

    ## The execution problem

    One of the first challenges was application execution.

    Traditional operating systems tend to build processes and threads dynamically. Ceylon's underlying platform is intentionally different. Much of the system is constructed ahead of time, with explicit resources, explicit authority and tightly controlled relationships between components.

    Initially, that looked like it might become an obstacle.

    Instead of fighting that design, we tried a different approach.

    We built a bounded pool of isolated execution workers ahead of time, then allowed Ceylon to lease those workers dynamically.

    The underlying execution resources remain static.

    Their use becomes dynamic.

    That means an execution worker can move through a lifecycle resembling:

    FREE
      ↓
    LEASED
      ↓
    ACTIVE
      ↓
    QUIESCING
      ↓
    RESETTING
      ↓
    FREE

    Each lease carries generation information so stale references can be rejected rather than accidentally referring to a newly reused resource.

    More importantly, multiple isolated workers can participate in one logical application environment while retaining separate protection domains.

    That has some useful security properties of its own: sharing memory does not automatically mean sharing authority.

    ## Making isolated workers feel like one address space

    That led directly to the next problem.

    If two workers are supposed to behave somewhat like threads in one application, they need to agree about memory.

    We proved that two—and later four—isolated workers can map the same backing memory at the same virtual address and successfully exchange actual pointers.

    Not offsets.

    Not handles pretending to be pointers.

    The same numeric address.

    One worker can create an object in shared memory, publish a pointer to it, and another worker can dereference that pointer directly.

    That was an important result because it suggested that Ceylon could build a logical shared application address space across independently isolated execution contexts.

    There are caveats.

    Ordinary writable program globals remain private to each worker unless we deliberately place them into shared backing memory. Private stacks and thread-local state also need to remain private.

    But that is an architectural problem we can define clearly rather than an indication that the model is impossible.

    ## The virtual-memory problem

    The next step was harder.

    Static shared mappings are useful, but a modern workstation eventually needs runtime memory behavior:

    mapping and unmapping memory;
    shared heaps;
    guard pages;
    permission changes;
    executable-code transitions;
    sparse reservations;
    deterministic cleanup;
    controlled reuse.

    At first, the upgraded platform appeared not to expose enough authority for that.

    The obvious response would have...

    Read more »

  • 28 — Ceylon Development Log — September 15, 2026: Locking the Baseline Before Moving Forward

    Mike2 days ago 0 comments

    *Mike · September 16, 2026*

    **Tags:** Project Ceylon, Workshop, Microkernel, Validation, Systems Engineering

    ---

    A day spent proving the new low-level foundation: DMA and interrupt isolation, multicore FPU safety, runtime boundaries, and an integrated harness that learned to trust shared state instead of notification counts.

    September 15 was one of those days where a lot of work happened without producing something flashy on the screen. That is not a complaint. For an operating system project, these are some of the most important days.

    The focus was on getting Project Ceylon's current reference build into a state where we could confidently say: this is the known-good machine, and anything we change from here has to prove that it is at least as trustworthy. That baseline is now locked.

    ## The last known-good build

    Before beginning the next major low-level system update, I wanted a reproducible reference point. Not the last version that seemed to work. Not whatever happened to be in the build directory. A real baseline.

    That meant capturing the exact source revision, system image, kernel image, dependency versions, test results and performance measurements associated with the current working system.

    The reference build completed its regression suite successfully, including 407 workspace tests, 86 documentation and contract checks, RTC and time synchronization tests, software-emulated and hardware-assisted virtualization boot testing, and baseline IPC, notification, shared-memory and floating-point performance measurements.

    That build is now the project's GOLDEN-PRE23 reference. It gives us something extremely valuable: a control group. From this point forward, a major platform change cannot simply say, "it boots." It has to answer a much harder question: is it actually better—or at least no worse—than the system we already know works?

    ## Why I am being so conservative

    The low-level platform underneath Ceylon is going through a fairly substantial upgrade. This affects process isolation, memory ownership, shared memory, device access, DMA isolation, interrupts, multicore execution, inter-process communication, floating-point and SIMD state, and runtime and linker behavior.

    Those are not areas where I want to rely on optimism. A bug in a graphical application is irritating. A bug in the part of the system that decides which device is allowed to write to which physical memory is an entirely different class of problem.

    The goal is to eventually take Ceylon from the virtual development machine to real x86-64 hardware. The more of these architectural assumptions we can prove now, the fewer surprises we should encounter when that transition begins.

    ## DMA isolation passed

    One of today's major validation areas involved device DMA. In simple terms, DMA allows hardware devices to access memory without asking the CPU to copy every byte. It is important for high-performance storage, networking, graphics and media processing—and it needs strict boundaries.

    The test system defines separate, bounded DMA windows for multiple virtual devices and verifies that a device cannot wander outside the memory assigned to it. The validation included attempts below and above an allowed window, across its boundary, through unmapped holes, into memory owned by another device, and into memory belonging to another authority domain.

    Those tests passed in both software-emulated and hardware-accelerated environments. That may not make for a glamorous screenshot, but for the kind of workstation Ceylon is intended to become, this is foundational.

    ## Interrupt ownership found a real defect

    The interrupt tests did exactly what good validation is supposed to do: they found something. A network device still had an interrupt assignment left over from an earlier configuration, even though that network path had evolved into a polling-based design.

    The stale route was removed, the candidate was rebuilt, and the interrupt tests were repeated. The corrected...

    Read more »

  • 27 — Ceylon Development Log — September 14, 2026: Strengthening the Foundation

    Mike2 days ago 0 comments

    *Mike · September 15, 2026*

    **Tags:** Project Ceylon, Workshop, Microkernel, Systems Engineering, Roadmap

    ---

    A long day of audit closure and microkernel migration work froze a reproducible Ceylon baseline and advanced the new foundation to the B0 validation gate.

    Today turned into a much longer development tranche than I expected. What started as preparation for an underlying system update ended up consuming most of the afternoon and evening, but we finished the day in a very good place.

    The first major milestone was freezing a new known-good Ceylon baseline. That means we now have a version of the system that is not simply working, but documented, reproducible, independently reviewed, tested under multiple execution environments, and backed by a performance baseline we can use for future comparisons.

    That distinction is important. When you are building an operating system, especially one intended to grow into a serious multimedia and workstation platform, eventually "it boots" is no longer a useful definition of success. You need to know exactly what code produced the system, whether another clean build produces the same functional result, whether failure paths behave correctly, and whether future changes make the system better or worse.

    ## Why We Are Updating the Microkernel

    With that baseline safely preserved, we moved on to the next major step: updating the microkernel foundation underneath Ceylon. This is not an update for the sake of having a newer version number.

    Recent architectural research into memory management, shared memory, device access, DMA, process isolation, execution contexts, and high-performance data paths exposed opportunities that make more sense if we modernize the underlying kernel environment first.

    As the project grows, memory cannot just be thought of as RAM an application gets. We need increasingly sophisticated control over which subsystem owns a region, which processes may map it, which devices may access it directly, when memory is pinned or reclaimed, how stale mappings are rejected, how shared data moves without unnecessary copying, and how those rules remain enforceable when something crashes or restarts.

    Those are foundational operating-system problems, and they directly affect performance. If we get the architecture right, Ceylon can eventually move large amounts of graphics, audio, storage, and media data through the system without constantly copying it from one private buffer to another.

    ## Research Before Implementation

    A lot of the recent work has actually been research rather than coding. I have been looking closely at how mature operating systems and multimedia platforms solve problems such as shared buffers, registered memory, DMA ownership, resource lifetime, high-performance queues, and hardware isolation.

    The goal is not to copy another operating system. It is to understand which ideas have proven durable, why they work, where they fail, and which lessons make sense for Ceylon. That research has already generated several promising architectural directions for later development.

    But before implementing those ideas, it became clear that updating the microkernel now would give us a much better foundation to build them on. So that became today's job.

    ## A Longer Tranche Than Expected

    Updating something this far down in the system affects considerably more than changing a dependency number. Low-level memory configuration changed. Device isolation changed. Interrupt handling needed to be reviewed. Runtime and linker assumptions had to be checked. Hardware-access paths needed to be validated.

    Because we had just established a clean baseline, I was not willing to make enough changes to get the machine to boot and call it finished. The updated system had to pass the same tests as the previous baseline. By the end of the night, it did.

    The new candidate builds successfully, boots under both of our primary virtualized execution modes, reaches the authentication system,...

    Read more »

  • 26 — Ceylon Development Log — September 12, 2026

    Mike2 days ago 0 comments

    *Mike · September 13, 2026*

    **Tags:** Project Ceylon, Workshop, Governance, Architecture, Shared Memory, Community Research

    ---

    September 12 was a day of architecture review, development governance, and a closer look at what modern Amiga users actually want from a workstation.

    ## From Prototype to Engineering Discipline

    September 12 was not primarily a "new feature" day for Ceylon. It was a day spent making sure that what we are building can survive the transition from an interesting operating-system experiment into a system that can actually be maintained, verified, extended, and eventually trusted.

    That meant doing two things in parallel: taking a hard look at the current Ceylon source tree and formalizing the rules that will govern development from this point forward, while also stepping outside the code to ask what current Amiga users are actually asking for when they talk about a modern system. Those exercises reinforced each other surprisingly well.

    ## A Full Architecture Review

    The source review captured 119 maintained Rust, C, Python, shell, and Microkit composition files. The documentation checker and its tests are passing after correcting the XML block-comment handling discovered during the review.

    The review gave us a clearer picture of where Ceylon is strong and where parts remain proof-grade. The architecture remains centered on seL4 and Microkit for protection, capabilities, mappings, interrupts, notifications, and controlled lifecycle management, while higher-level Ceylon services own storage, networking, input, graphics, application execution, authentication, management, and the user environment.

    One principle was reinforced throughout: the microkernel is there to enforce isolation and authority, not to become the high-frequency data bus of the operating system. Ceylon's preferred model remains small typed control messages, shared or registered buffers for bulk data, descriptor and SPSC rings for streaming, batched publication and completion, and notifications for meaningful state changes rather than per-byte or per-pixel kernel traffic.

    ## Restarting a Process Is Not the Same as Recovering a Service

    A protection domain being restartable does not automatically mean the service it contains is restart-safe. A restarted driver or service may still have stale shared-memory cursors, outstanding requests, device queue state, DMA ownership, external consumers holding old references, replay state, or hardware that was never properly quiesced.

    Ceylon therefore needs explicit reincarnation contracts for restartable services: how state is torn down, what becomes invalid, how generations advance, what happens to work already in flight, and how clients reconnect. That is the difference between saying "we can restart a component" and actually being able to recover a workstation after something fails.

    ## Shared Memory Is Becoming a Platform Contract

    The source review found several synchronization approaches already present in the tree. That is normal during bring-up, but it cannot remain that way in a multiprocessing production system.

    We identified the need for standardized Ceylon shared-memory publication patterns covering SPSC rings, request/result pages, immutable snapshots and seqlocks, and descriptor/data-window rings. Each needs defined ownership, memory ordering, overflow behavior, restart behavior, generations, cache assumptions, and notification rules. Storage, graphics, audio, networking, input, media processing, and application services all depend on moving data between isolated components quickly without sacrificing correctness.

    ## Proof Paths Cannot Quietly Become Production Paths

    An implementation good enough to prove a concept is not automatically good enough to become permanent architecture. Several Ceylon paths intentionally use simplified copies, single outstanding operations, or other bounded bring-up mechanisms. Those are useful for proving behavior, but they are not necessarily how...

    Read more »

  • 25 — A Night Off, a Looney Tunes Movie, and a Hard Look at Ceylon

    Mike2 days ago 0 comments

    *Mike · September 11, 2026*

    **Tags:** Project Ceylon, Workshop, Code Audit, Governance, Status Update

    ---

    A night away from Ceylon turned into dinner, a movie, a serious software audit, and a complete rewrite of the rules for building the operating system.

    September 10 was a genuine night off.

    No Ceylon work. No documentation. No architecture review. No testing. Nothing.

    That was intentional.

    I have been spending enough time buried in Ceylon lately that taking an entire evening and simply not touching it was probably overdue, so that is exactly what I did.

    September 11 started out considerably less serious.

    I grabbed McDonald's for dinner and went to see Coyote vs. Acme.

    The easiest way I can describe it is as something in the general neighborhood of Who Framed Roger Rabbit and Space Jam, but without all of the bells and whistles.

    It is a simpler movie than either of those, and that is not necessarily a bad thing.

    There is plenty there for kids, while the parents get the nostalgia of seeing Wile E. Coyote, Acme, and the familiar Looney Tunes world given the live-action treatment again.

    It is not trying to be some enormous effects-driven spectacle. It is just a fun family movie with enough familiarity to keep the adults entertained too.

    My verdict: 3 out of 5 stars.

    Good for the kids. Nostalgic for the parents. Worth seeing for what it is.

    Then I came home and somehow the evening became considerably more serious.

    We conducted a fairly extensive software audit of the current Ceylon codebase.

    The point was not simply to ask whether Ceylon builds, boots, or passes tests. We went back through the actual engineering assumptions behind several parts of the system: shared-memory behavior, synchronization, ownership, unsafe code, restart behavior, performance concerns, and the places where proof-of-concept implementations eventually need to become production-quality implementations.

    We found some issues.

    That is not a bad result.

    In fact, that is exactly what I wanted an audit to do.

    The important thing is that we are finding these weaknesses now, while the system is still under active development and they can be corrected deliberately, rather than allowing questionable assumptions to become deeply embedded in the operating system.

    The audit also forced us to take a harder look at the rules governing Ceylon development itself.

    The result was a complete rewrite of the Ceylon software-development contract.

    The new contract is much more rigorous about what "finished" actually means.

    Code existing is not enough.

    A test passing is not enough.

    Even getting something working on the target is not, by itself, enough.

    The new development rules put much more emphasis on complete specifications, architectural ownership, requirements traceability, testing, target evidence, documentation, gap analysis, independent review, and keeping a durable record of why engineering decisions were made.

    The idea is straightforward:

    As Ceylon gets larger, I do not want it slowly turning into a collection of local fixes, undocumented assumptions, and architectural compromises that nobody can explain six months later.

    The architecture needs to remain intentional.

    So September 10 was a night completely away from Ceylon.

    September 11 was McDonald's, a Looney Tunes movie, and then several hours of finding problems in an operating system and rewriting the rules for how we build it.

    Apparently that counts as balance around here.

    I am also about halfway through another fairly substantial piece of Ceylon documentation.

    That one is not ready to discuss yet.

    There will be plenty to say about it when it is.

    ---

    *Originally published on The Weekend Report: https://theweekendersproject.com/report/a-night-off-a-looney-tunes-movie-and-a-hard-look-at-ceylon*

View all 35 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