Over the past few weeks I've been reconstructing CHARM-II, an RTOS I originally developed in 1986.

Some previous posts about this project:

• Visualizing a 1986 RTOS in a Modern Browser https://www.reddit.com/r/osdev/s/XeZDemN4Wk
• Visualizing a 1980s Commercial Messaging System Running on a Reconstructed RTOS https://www.reddit.com/r/osdev/s/gu8LBK5iev

While working on those, I realized something that I had completely forgotten about the original development process.

When I started this reconstruction, I thought the challenge would simply be getting the old code running again.

Instead, I ended up rediscovering why I developed it the way I did.

Back in 1986, the RTOS was developed on a SUN-2 with a Motorola 68010 and deployed on a separate 68000 target board.

I had always remembered debugging the kernel on the SUN-2.

What I had forgotten was why I stopped there.

During the reconstruction, I realized that this had been a deliberate engineering decision.

A fully preemptive kernel, including interrupt handling, context switching, and processor state management, is by far the most hardware-dependent and complicated part of an RTOS.

Implementing all of that on the host would have made the project much more complicated.

So I postponed it.

Instead, I developed almost everything else on the host:

• queues
• events
• timers
• scheduling
• message passing
• application logic

By the time the software was moved to the target hardware, most of the debugging had already been completed.

At the time, I don't think I consciously thought of this as a development methodology.

It was simply the most practical way to make progress.

Forty years later, reconstructing the project made me realize how effective that approach actually was.

Interestingly, I ended up following almost the same process again.

The original SUN-2 has been replaced by a POSIX environment.

The target will be a Raspberry Pi Pico.

A browser-based visualization was added along the way, but the overall host-target workflow is remarkably similar.

One thing that surprised me during this reconstruction is that the biggest changes rarely came from the original plan.

The browser visualization, for example, was inspired by WebAssembly that I encountered while working on an unrelated project.

It reminded me that engineering projects often evolve through unexpected discoveries rather than carefully planned roadmaps.

I'm curious whether anyone else has experienced something similar.

Have you ever reconstructed an old operating system, or any long-lived system, and discovered that the original engineering decisions made much more sense decades later than they did at the time?

I have been reconstructing CHARM-II, an RTOS I originally developed in 1986.

In an earlier post, I showed a visualization of the RTOS itself. This time, I wanted to visualize an actual communication application running on top of it.

The application is inspired by a commercial messaging system used by Japanese trading companies in the mid-1980s.

External PCs submit messages to the system. The system communicates with a KDD host, receives incoming messages, and prints them on a shared dot-matrix printer.

For readers outside Japan, KDD (Kokusai Denshin Denwa) was Japan's international telecommunications carrier at the time. Before the Internet became widely available, international business communication often relied on KDD-operated data networks and TELEX services.

Depending on the destination country, communication speeds could be as low as roughly 50 bps.

Another aspect that may seem unusual today is the role of the printer.

In the mid-1980s, it was not yet common for every employee to have a personal computer on their desk. Incoming messages were often printed immediately on a shared dot-matrix printer and then physically distributed to the appropriate departments or personnel.

In many cases, the printer was not just an output device—it was effectively part of the message delivery workflow.

The animation shows:

• PC1–PC3 generating outgoing messages
• TX tasks processing outgoing traffic
• A controller task coordinating communication
• Polling-based communication with the KDD host
• Incoming messages being printed by a printer task

Although the communication flow is visualized using HTML5 Canvas and WebAssembly, this is not merely a graphical simulation.

Internally, the application uses reconstructed CHARM-II primitives, including:

• process management
• queues
• exchanges
• events
• timers

Task communication is performed through CHARM-II-derived mechanisms.

One limitation of the current implementation is that RTOS timing and visualization timing are still coupled.

The application logic is driven by CHARM-II-derived task, queue, event, and exchange mechanisms, but message movement, polling intervals, and printing delays are currently adjusted to make the behavior easier to observe in a browser.

As a result, the logical sequencing of the application is preserved, but the timing characteristics do not yet match those of the original RTOS environment.

At the moment, the browser version should be viewed as a visualization of RTOS-driven behavior rather than a faithful reproduction of RTOS timing.

Separating RTOS logical time from visualization time is one of the next major goals of the project.

An interesting historical parallel is that I used a very similar development approach in the 1980s.

Back then, the actual communication infrastructure was not always available during development, so I built host-side simulators and protocol emulators on PCs and SUN-2 systems. Most application debugging was performed there before deployment to the real target environment.

The original 1986 system used:

• SUN-2 (68010) host
• 68000 target

The current reconstruction uses:

• POSIX host
• WebAssembly visualization environment
• Raspberry Pi Pico target (planned)

The underlying idea remains surprisingly similar: build a host environment first, verify most of the application there, and move to the target hardware later.

The next steps are:

• Completing the Pico port
• Separating RTOS logical time from visualization time
• Building a clean-room public version that can be openly distributed

Feedback is welcome.

I've been reconstructing a RTOS I originally developed in 1986.

As part of that work, I started building a browser-based visualization to better understand and inspect its behavior.

The attached video shows two views of the same RTOS concepts.

On the left is a text-based track demo inspired by the way I inspected task activity in the 1980s.

On the right is a modern Canvas/WebAssembly visualization.

The presentation is completely different, but the underlying concepts are not.

Same primitives.

Same scheduler.

The current visualization is already connected to recovered CHARM-II-derived kernel primitives. For example, critical section ownership is controlled through the original queue-based synchronization mechanism rather than through a visualization-only simulation.

When I started this project, I thought I was simply porting an old RTOS to a modern environment.

As I dug deeper into the recovered source trees, I realized the original project was structured in a way I had almost forgotten.

Back in 1986, the system was developed using a SUN-2 workstation based on a Motorola 68010, while the target hardware used a 68000 processor.

The host machine was used for kernel development and debugging. The target system was used for actual deployment.

At the time, this was a practical arrangement because the 68010 was largely compatible with the 68000.

When I began rebuilding the system in 2026, I initially considered doing something similar with Apple Silicon as the host and a Raspberry Pi Pico as the target.

After looking into the details, I discovered that sharing the "ARM" label was far less meaningful than sharing the 680x0 family had been in the 1980s. The gap between a modern ARMv8-A application processor and a Cortex-M microcontroller is enormous.

That realization led me in a different direction.

Today I use POSIX to exercise the kernel logic, WebAssembly to visualize and inspect behavior, and a Raspberry Pi Pico for target-specific validation.

Another thing I rediscovered was how much work had originally been done on the host side.

The 68000 target implementation contains trap handlers, interrupt entry points, and a fully preemptive context-switch path.

The SUN-2 implementation does not.

Instead, most of the kernel logic appears to have been exercised using cooperative scheduling boundaries, avoiding hardware-specific interrupt and context-switch complexity during development.

Without planning to, I ended up following almost exactly the same approach.

The current POSIX implementation is also cooperative rather than preemptive.

Queue operations, event handling, timer processing, scheduling logic, process management, and most of the kernel code are exercised on the host side. Target-specific interrupt and context-switch behavior is being deferred to the Pico port.

Looking back, it feels less like porting an old RTOS and more like rediscovering the development methodology behind it.

The browser version still contains recovered CHARM-II-derived code, so I'm only sharing videos and screenshots for now.

My current plan is to continue the reconstruction work, complete the Pico port, and then use everything learned from the process to build a clean-room implementation that can be released publicly.

The reconstruction itself is not the final goal.

What interests me now is understanding why the original system was built the way it was, and seeing how much of that thinking still makes sense forty years later.

Recently I rediscovered the source code and printed documentation for a small 68000 RTOS I worked on around 40 years ago.

The original system was developed in a fairly typical late-1980s host/target setup:

SUN-2 (68010) host
      ↓
68000 target

Most of the RTOS was written in C, with CPU-dependent context switching isolated in assembly.

At the time this wasn't really about future portability. I had been heavily influenced by the Whitesmiths C style and tended to separate machine-dependent code and use abstract type definitions throughout the codebase. Looking back, those decisions probably helped the code survive.

One thing that surprised me during this reconstruction is that the overall architecture still feels familiar today:

• scheduler
• ready queue
• events
• message queues
• memory management

The implementation details have changed, but the core ideas have not.

Rather than attempting a cycle-accurate restoration, I'm trying to recreate the original development structure in a modern environment:

POSIX on WSL2 host
        ↓
Raspberry Pi Pico target

At first, I chose the POSIX environment mostly because it seemed like the easiest way to start experimenting with the recovered code.

What I didn't fully anticipate was how effective that decision would be in the age of AI-assisted development.

In the late 1980s, the SUN-2 was dramatically more productive than the ICE-based target environment. Faster compilation, better editors, hard disks instead of floppy-based workflows, and a much more comfortable debugging experience made it the obvious place to develop most of the system.

Today the advantage of the host environment is even larger.

The POSIX side allows AI agents to participate directly in the development loop:

• OCR recovery of printed source code
• source analysis
• build system generation
• compiler warning investigation
• API reconstruction
• scheduler prototyping
• automated testing and validation

In hindsight, if I had started by implementing everything directly on the Pico target, AI would still have been useful, but only in a limited way. Most development would still revolve around the traditional cycle of:

edit
↓
build
↓
flash
↓
run
↓
observe

By rebuilding the architecture on POSIX first, the AI can work in the same environment as the source code, compiler, build system, and tests. The feedback loop becomes dramatically shorter.

What surprised me is that this is conceptually very similar to why we used the SUN-2 in the first place.

In the 1980s, the host workstation amplified the developer.

In 2026, the host environment amplifies both the developer and the AI agent working alongside them.

The current prototype runs as a cooperative scheduler on POSIX. The next step is bringing the same architecture to Raspberry Pi Pico, followed by experiments in visualization and observability that would have been impossible on the original hardware.

The original company no longer exists, and the licensing status of the recovered source is unclear, so the goal is a clean-room modern reimplementation rather than publishing the original code.

I'm curious whether anyone else here has worked on similar host/target RTOS workflows from the 68000 era—or has found that AI agents become dramatically more effective when working in a host-side simulation environment rather than directly on embedded targets.

I've been gradually reconstructing CHARM-II, a custom Motorola 68000 RTOS I wrote in the late 1980s.

At first I assumed the reason so much of the code survived was portability. The code used Whitesmiths-style typedef abstractions and was mostly written in C.

After digging deeper, I realized something else had happened.

The original plan was to write everything in C first, then optimize critical parts in assembly if necessary. But during integration testing, performance was already good enough. In fact, the system significantly outperformed a competing Intel 80186-based polling solution, so the assembly phase never happened.

A second project later reduced communication overhead even further by using an intelligent RS-232 controller board, so again there was no reason to rewrite the code.

As a result, roughly 90% of the RTOS remained in C.

Forty years later, that accidental decision is making it possible to bring the code back to life on a modern POSIX host.

I wrote a longer article about the discovery here:

https://medium.com/@noborutakahashi/why-90-of-my-1980s-rtos-survived-in-c-for-40-years-3ff6d524eb4a

I'd be interested to hear if anyone else has encountered old systems that survived largely because the planned optimization work never became necessary.

Recently I rebuilt one of the small demo programs I originally wrote for a custom 68000 RTOS around 40 years ago.

The original sample code itself is long gone, but I still remembered testing similar task/scheduler visualizations on a SUN-2 X Window environment back then.

This version runs on a POSIX host, but the structure is still very close to the original design.

The demo has 6 cooperative tasks moving concurrently around tracks.
Only one task may enter the Critical Zone at a time.

Just like the original version, the screen animation is done entirely using VT100/ESC terminal sequences.

At this stage I'm intentionally focusing on reconstructing the scheduler/event structure first before recreating the original 68000 context-switch assembly.

Next step is bringing the same structure onto Raspberry Pi Pico.

While rebuilding parts of a custom 68000 RTOS I wrote around 40 years ago, I ran into something surprising.

The codebase was heavily influenced by Whitesmiths C style, with typedef-based abstraction everywhere instead of using raw machine types directly.

Back then I wasn't really thinking about “future portability” in the modern sense — I just liked the style and wanted to isolate machine/compiler differences.

But 40 years later, that decision turned out to matter a lot.

Most of the scheduler/event/queue code compiled on modern POSIX systems with surprisingly few changes once I enabled:
-std=gnu89

One particularly funny detail was that the original compiler didn't properly support void yet, so the codebase used things like:

typedef int VOID;

which allowed function declarations to stay structurally consistent across compilers.

The original demo/sample code itself is gone, but I still remembered testing similar scheduler visualizations on a SUN-2 X Window environment at the time.

Now I'm reconstructing the same architecture on POSIX and Raspberry Pi Pico.