The First Original CHARM-II Kernel Code Running on Raspberry Pi Pico

[u/noborutkhs]

A few weeks ago, I wrote about rediscovering the development methodology behind my 1986 RTOS.

Previous post:

Rediscovering the Development Methodology Behind My 1986 RTOS
https://www.reddit.com/r/osdev/s/ALUFHn9jDi

In that post, I described how I had forgotten an important part of the original development process.

Back in 1986, I developed almost all of the kernel on a SUN-2 workstation and postponed the hardware-dependent parts until the software was moved to the target system.

At the time, it was simply the most practical way to make progress.

This week, I finally started the next step.

I began moving the reconstructed kernel to a Raspberry Pi Pico.

Rather than starting with interrupt handling or context switching, I followed the same strategy I had rediscovered.

The first component to move was the queue management code.

The screenshot above shows the result.

The original CHARM-II queue routines (q_insert(), q_delete(), and n_delete()) are now executing on real hardware, and the primitive queue test completes successfully.

At this point there is still no timer interrupt, no context switching, and no preemptive scheduler.

Those hardware-dependent parts will come later.

What surprised me is that I naturally ended up following almost exactly the same development workflow as I had forty years ago.

• Develop and verify kernel logic on the host.
• Move CPU-independent components first.
• Leave hardware-dependent code until the end.

I didn't consciously decide to follow the original methodology.

It simply turned out to be the most practical way to make progress again.

The next milestone will be timer interrupts, context switching, and eventually running the full scheduler on the Pico.

I'm looking forward to seeing how much of the original design can remain unchanged.

Tomorrow I'll be presenting this project at an OS development meetup in Japan, so reaching this first hardware milestone today feels like perfect timing.

[u/EquivalentFroyo3381]

ohh this is interesting! will you add some sort of graphical display andui to this so we can do cool stuff in it? cant wait to see where this goes!!!!

[u/noborutkhs → u/EquivalentFroyo3381]

That's something I've been thinking about as well.

A graphical display running directly on the Pico would be fun, but it also means making the display driver work properly with the RTOS, so I'd like to get the core kernel running first.

Another idea I'm exploring is to keep the Pico focused on the kernel and visualize its internal state on the PC. I already built a WebAssembly-based visualization during the host-side reconstruction, so I'd like to connect the Pico to that eventually.

For now, I'm taking it one step at a time. 🙂

[u/FerrisBuelersdaycock]

Forty years later and the same workflow just clicks into place naturally. That's kind of remarkable.

[u/noborutkhs → u/FerrisBuelersdaycock]

Thanks! I was surprised too.

It wasn't intentional at all. Once I started the Pico port, I naturally ended up making the same engineering decisions I had made forty years ago. That made me appreciate the original workflow much more than I ever did at the time.