Project Ceylon Development Log — September 26, 2026: Remember That Day Off I Was Going to Take?
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 correctly.
That work is now being treated separately from the larger modernization effort.
The first corrective stages are about fundamentals:
- establish real buffer identity and ownership;
- make publication explicit;
- prevent stale generations from being accepted;
- introduce bounded backpressure;
- make the presentation relationship trustworthy;
- then route live NuGUI presentation through Nu-Iris instead of around it.
Only after that foundation is proven does it make sense to start piling performance work on top.
Because optimizing the wrong path very efficiently is still the wrong path.
And yes, there is a much bigger Iris list now
Once we started looking seriously at where Nu-Iris eventually needs to go, the list got large quickly.
Some of the things now on the research and modernization horizon include:
- damage-aware presentation;
- stale-frame suppression;
- reusable buffers;
- frame pacing and presentation feedback;
- faster CPU copy and composition paths;
- tiled composition;
- multicore rendering support;
- SIMD where it actually helps;
- direct scanout where appropriate;
- zero-copy or reduced-copy surfaces;
- high-rate 1080p qualification;
- media-friendly pixel formats such as YUV;
- multiple outputs;
- restart-safe presentation;
- measurable latency and throughput;
- future hardware-accelerated providers.
That does not mean all of that suddenly became an A1 Alpha requirement.
It means the architecture now has a clearer road from:
"I can put pixels on a screen"
to:
"I have a display subsystem I can build a workstation on."
Those are not the same milestone.
I know that much more viscerally now than I did a few weeks ago.
The first corrective work is already paying off
The good news is that this was not just an afternoon spent writing a depressing report.
We started correcting the foundation.
The current integration work has already established several things that were previously too implicit:
real buffer identity,
clear ownership,
immutable publication through trusted state,
bounded two-buffer backpressure,
and protection against stale generations being accepted as current.
That is exactly the kind of boring infrastructure that makes later optimization possible without turning the display stack into a collection of timing accidents.
There is still an important next step:
the live NuGUI path itself has to be routed through the Iris service.
Until that happens, I am not calling the end-to-end architecture finished.
First Light remains First Light.
But the next light needs to be honest about the path that produced it.
Meanwhile, I started thinking about the machine this eventually runs on
Because apparently discovering one architectural problem was not enough for the day, I also spent time looking farther ahead at Ceylon's eventual certified hardware.
Not because A1 Alpha suddenly moved to bare metal.
It hasn't.
A1 remains QEMU-first.
But the whole point of the A-series is eventually to reach a stable enough software environment that the B-series can carry it onto known physical hardware.
And that raises a practical question:
What kind of computer should Ceylon actually be sold on?
Not a laboratory controller.
Not an exotic industrial board that costs three times as much because somebody promises to sell the exact same model for ten years.
A normal, reproducible PC.
Something serviceable.
Something expandable.
Something where replacement parts do not require an archaeological expedition.
The current direction is toward ordinary commercial PC hardware with a controlled bill of materials rather than weird custom hardware for the sake of being different.
One candidate baseline we looked at uses a commercial ASUS CSM motherboard with a Core i5-12500-class processor and 32 GB of DDR4.
Nothing exotic.
That is intentional.
I want the storage to be accessible
One requirement I care about more than I expected is physical serviceability.
If somebody buys a Ceylon machine someday, I do not want routine storage replacement to mean disassembling half the computer.
So the current hardware thinking includes front-accessible storage.
The idea is straightforward:
system storage inside,
additional independent drives accessible from the front,
and no requirement to turn the thing into a RAID appliance.
If a user wants another drive, replaceable storage, project media, scratch space, backups, whatever — I want that to be easy.
Likewise, users should be able to install their own NVMe drives or add-in hardware.
Certified hardware means:
this is the configuration we have qualified and will stand behind.
It should not mean:
the case is sacred and thou shalt not touch it.
If you install unsupported hardware, that hardware is obviously outside the certified configuration.
But it is still your computer.
That distinction matters to me.
And the machine should remember what changed
That hardware discussion led into another idea I like quite a bit.
Ceylon's System Information utility should not merely tell you what hardware is installed right now.
The operating system should maintain a protected history of meaningful hardware changes over the life of the machine.
Shipped with this memory.
DIMM replaced on this date.
Original NVMe removed.
New drive installed.
PCIe card added.
Firmware changed.
Network device replaced.
And so on.
Not because I want to spy on somebody's upgrades.
Because if a machine comes back for support two years later, "this is not the hardware configuration we shipped" is useful information.
The important part is that ordinary applications should not be able to rewrite that history.
A privileged service should own it.
The user-facing System Information application gets a controlled read-only view.
Support tooling can get the deeper diagnostic view when appropriate.
Again, simple idea on the surface.
Much more useful once you think about supporting real machines for years instead of demoing one on a workbench.
Today was really about correcting the story
There is a pattern developing in Ceylon that I am starting to appreciate.
The project gets something working.
Then we go back and ask what "working" actually proved.
Sometimes the answer is exactly what we expected.
Sometimes it isn't.
First Light proved that Ceylon could produce visible graphical output.
It did not prove that the final Nu-Iris architecture was already carrying those pixels.
Now we know that.
And because we know it before Alpha, we have the opportunity to fix the architecture instead of documenting the shortcut as if it were intentional.
That is progress.
Not the glamorous kind.
There is no new desktop screenshot tonight.
There is no airplane to crash yet.
There is no synthesizer riff to play.
But the display stack is becoming more honest about what it is, what it isn't, and what still has to happen.
And the future hardware is starting to look less like an abstract "bare-metal target" and more like a computer I could actually put on somebody's desk and expect them to live with.
So, no.
I did not take the day off.
Apparently I am very bad at that.
Maybe tomorrow.
No promises.
Project Ceylon is an independent retro-futurist operating-system project exploring what a modern creative workstation might look like if some of the best ideas of earlier personal computers had continued evolving instead of being discarded.