Project Ceylon: Keeping the Architecture, Rebuilding the Assumptions
Project Ceylon keeps the architectural ideas that made the Amiga compelling while rebuilding the assumptions underneath them for modern hardware.
One of the questions hanging over Project Ceylon from the beginning has been pretty simple: if the Amiga architecture had been allowed to evolve continuously for another forty years, how much of the original design would still make sense in 2026?
This week I finally took a fairly hard look at that question.
Not from the standpoint of nostalgia, and not from the standpoint of trying to recreate a machine from 1987 with faster parts. The question was whether the ideas behind the original architecture still held up against modern CPUs, modern memory systems, GPUs, DMA, multicore processing, isolation, modern storage, and the sort of workloads people actually expect from a computer today.
The answer was encouraging.
We did not find a reason to throw the overall architecture away.
What we found instead were several places where the original thinking was still good, but the mechanism underneath it needed to grow up.
That is exactly what I had hoped would happen.
The original idea was better than some of the original limitations
The Amiga's custom chips divided work into specialized areas instead of asking the CPU to do absolutely everything.
That basic idea still makes sense.
What doesn't make sense is reproducing the limitations that existed because of the technology available at the time.
A modern machine does not need to recreate Chip RAM, fixed DMA slots, raster-timed bus arbitration, or a display system built around analog CRT assumptions just because those things existed on the original hardware.
Those were solutions to specific hardware constraints.
So the approach we're taking with Ceylon is to preserve the responsibility and design intent, while replacing the historical mechanism where modern hardware gives us a better answer.
That distinction turned out to be pretty important.
Iris doesn't need to pretend it is Agnus
Iris is our descendant of the Agnus/Alice side of the architecture.
Historically, Agnus had a huge amount of responsibility because it had to coordinate access to shared memory and arbitrate DMA among the custom chips.
That was necessary then.
It would be a bad design choice now.
Modern x86-64 hardware already gives us PCIe, device DMA, memory protection, multiple CPU cores, IOMMU support, and much more sophisticated resource management.
So Iris does not need to become a fake 1980s bus arbiter.
Its role evolves toward coordinating graphics and media resources, ownership, scheduling, and work relationships without trying to own every byte moving through the machine.
That is a good example of what I mean by preserving the architecture without preserving obsolete machinery.
Baton survives surprisingly well
Baton is the descendant of the Copper concept.
The original Copper was built around precise display timing and raster position.
The underlying idea, though, is much broader than "wait for scan line 143 and change a register."
The useful part is deterministic sequencing of operations relative to presentation timing.
That still matters today.
Frames have deadlines. Presentation has ordering requirements. Effects may depend on previous work completing. Buffers have to be ready before display. Video and animation still depend on timing.
So Baton evolves from raster-position programming into a general sequencing and presentation-timing facility.
Same idea. Much better clock.
Loom may be one of the more interesting evolutions
We decided to keep the name Loom for the Blitter descendant.
The original Blitter was an extremely effective solution for moving and manipulating blocks of graphics data without tying up the CPU.
That idea aged very well.
What changes is the implementation.
Loom is becoming a provider-neutral graphics and image execution layer.
An application can ask Loom to perform operations such as copy, fill, scale, composite, transform, clip, blend, or color conversion without caring whether the actual work is done by plain CPU code, SIMD instructions, integrated graphics, or a discrete GPU.
That gives us a very useful property: the operation stays the same even as the hardware gets faster.
On a base machine, the CPU implementation should still be genuinely useful.
Add GPU acceleration and the same workload can move from merely fast to ridiculous.
That fits the performance rule we've been using throughout Ceylon: acceleration raises the ceiling. It does not establish the floor.
I don't want a machine that requires a discrete GPU just to behave like a normal computer.
The microkernel shouldn't become the new bottleneck
Another area we reviewed carefully was communication between all of these pieces.
Ceylon is built on a security-certified microkernel foundation, and that provides some extremely useful isolation and authority boundaries.
But having a microkernel does not mean every pixel, audio sample, disk block, network packet, or video frame should bounce through the kernel as an individual message.
That would be secure and architecturally pure right up until the machine became miserable to use.
Instead, we have increasingly converged on a common pattern: small control messages establish authority and ownership, while high-frequency data moves through bounded shared resources such as buffers, rings, and descriptor queues.
The kernel remains responsible for authority, isolation, scheduling, and containment.
It does not need to sit in the middle of every byte.
Interestingly, we found variations of this same design appearing independently in the graphics, filesystem, random-number, and audio work.
That is usually a good sign.
When several subsystems independently converge on the same pattern, it is probably worth formalizing.
Multicore means we should actually use the computer we have
There is also no reason to act as if we still have one CPU competing with a handful of custom chips for every cycle.
If six cores are sitting there, we should use them.
If work can safely happen in parallel, let it happen in parallel.
If a background encoder can consume five cores while leaving the desktop, input, audio, and foreground work responsive, that is exactly what it should do.
The rule is not "conserve CPU at all costs."
The rule is use resources without making the user pay for it in responsiveness.
That led us to a performance vocabulary I've started calling the Mike Scale.
The normal machine should RUN.
Heavy production work should be allowed to FLY or reach OMG territory when hardware allows it.
But the desktop should not suddenly fall back to WALK because somebody started an encode.
Responsiveness is part of correctness.
Audio is being treated the same way
Aria and Lyra are being developed as shared Ceylon audio infrastructure rather than something every application reinvents privately.
They need to work for ordinary audio playback, but also for the music-production environment we're planning and eventually as part of the Ceylon replacement for the Video Toaster.
That means we are having to think carefully about routing, buses, PCM streams, MIDI, clocks, synchronization, and the relationship between audio time and video time.
Again, the goal is not to make one giant media subsystem that knows everything.
The goal is to give applications stable system facilities so they don't each have to bring along their own miniature operating system.
The Toaster work uncovered another architectural opportunity
While reviewing how the original Video Toaster software fit together, we found something worth preserving conceptually.
The old system did not use one universal mechanism for everything.
Timing-critical work used the mechanism appropriate to timing-critical work.
Applications could use ARexx for loose control and automation.
Media assets could be exchanged through projects and files.
That led us toward a more general Ceylon application-federation model.
Some applications will be able to cooperate more deeply when explicitly authorized.
NuBrush could operate as a standalone graphics program but also participate in the Toaster environment.
The music-production software could operate by itself or become the audio-production side of the same project.
Future applications could embed or link live objects in ways similar to putting a spreadsheet inside a word-processing document.
We're calling the federation coordinator Kirk for now.
Kirk's job is not to carry the video frames or render the graphics.
It maintains the relationships: who owns this object, what application can edit it, is it embedded or linked, what revision is current, what provider can handle this type, and if the provider restarts, is the old relationship now stale.
The actual graphics still go through Loom. Audio still belongs to Aria and Lyra. Files still belong to the filesystem.
Kirk just keeps the crew coordinated.
And importantly, not every application has to participate.
A non-federated application remains isolated and does not get cross-application shared-resource privileges.
It can still copy data or save a file like any normal program.
But live shared objects and shared resources require explicit federation.
That seems like a much cleaner security model than quietly letting every application reach into every other application because somebody wants fancy drag-and-drop.
The architecture survived the review
That is probably the biggest conclusion from all of this.
We went into the review fully prepared to discover that some of the original architectural ideas simply did not survive contact with modern hardware.
Instead, most of the important ideas did survive.
What changed were the assumptions underneath them.
Agnus does not need to arbitrate 1980s memory buses.
The Copper does not need to think in CRT scan lines.
The Blitter does not have to be one fixed piece of silicon.
Audio does not have to live inside an application.
Applications do not have to sacrifice isolation just to cooperate.
And the operating system does not need to route every high-frequency data transfer through its smallest control mechanism.
That feels like the right outcome for Ceylon.
We're not building an old Amiga with modern parts.
We're trying to figure out what the architecture might have become if engineers had been allowed to keep improving it for forty years.
Some of that means keeping ideas that were already very good.
Some of it means admitting that technology moved on.
And some of it means finding opportunities the original designers simply did not have the hardware to exploit.
The next major milestone is still the same: get the complete reference workstation running under QEMU, prove the architecture end to end, and only then start getting serious about the physical machine.
But the architectural foundation feels considerably better defined now than it did a week ago.
And after spending a large portion of the week thinking about DMA, generation counters, application federation, audio clocks, shared buffers, and what exactly a Blitter ought to be in 2026, I went over to my sister's house and had brisket with the family.
It was very good brisket.
Some systems are already adequately optimized.
Originally published on The Weekend Report: https://theweekendersproject.com/report/project-ceylon-keeping-the-architecture-rebuilding-the-assumptions