OPENMULTICORE · THE NEXT COMPUTING FRONTIER
One Exec.
One Exec.
Many cores.
One future.
What if your Amiga could draw on the processing power around it—without ceasing to be an Amiga?
OpenMulticore is the Team's open standard for more than one processor. Nursery connects named capabilities across boards and machines. And beneath it all sits the Team's preservation mission: write new, open implementations of the Amiga's essential libraries, one by one, so the platform's familiar software can endure beyond any single machine or vendor.
Then comes the bigger question: what would a future operating environment look like if the Team built on those compatible foundations—and stopped being limited by one CPU, one box or one era?
THE AMIGA IS STILL IN CHARGE OPEN
AmigaOSExec · CPU0 · Workbench
OpenMulticore · grants · jobs
M68KMain-core fallback
Extra cores68k JIT workers
Native / LANBackend or service
The cores board and openmulticore.library 0.4 are built. Native bodies for utility.library and the IEEE maths run on x86-64 and ARM64 cores. Per-application cores and the native section loader are designs, not yet built.
A different kind of multicore
Your Amiga keeps its soul.
Your Amiga keeps its soul.
The work finds more cores.
Classic AmigaOS was designed around one main processor. Rather than forcing a risky multicore rewrite of Exec, the Team's first step is a compatible contract for explicitly bounded extra work.
One familiar Amiga
Exec, applications and chipset operations stay on CPU0. Existing programs are not silently scattered across processors or made dependent on a new scheduler. Next, as a design: each application may get a 68k core of its own, with calls that belong to the system still going to CPU0.
Processors that introduce themselves
A cores board advertises its units, supported instruction sets and capabilities through an AutoConfig-compatible interface. AmigaChrome can present virtual cores; hardware makers can implement the open specification.
Safe by default, strict on request
By default a job reads any Fast RAM and ROM. It writes only the buffers it was given and its own stack, byte for byte, and never touches Chip RAM. A secure program can ask for strict mode: the job then reads and runs only its grants. Page grants make strict mode fast again.
Familiar code still runs
Extra cores can execute 68k functions through independent translated cores. If no qualifying extra core exists, the same program can fall back to execution on CPU0.
A simple developer contract
Use OMC_Run68k, or submit jobs and wait for their signals. Range jobs split independent slices across cores, with CPU0 as the fallback. Version 0.4 adds two options: OMCF_STRICT for secure programs, and OMCF_PAGES to keep strict jobs fast. In the Team's lab, one job of a million steps took 3.7 ms by default, 597 ms strict, and 3.1 ms strict with page grants.
Only accelerate what benefits
Batch decoding, compression and other independent jobs suit extra cores. Short synchronous calls, UI handling, OS I/O and device access often do not.
INTERNAL DEVELOPMENT MEASUREMENT · 8 OCT 2026
Let the music play. Give the main CPU back.
In the team's recorded AC090 / OpenPlay test, mixing a 32-channel XM module on the main 68040 occupied most of the processor and playback broke up. Handing the mix to another core reduced the recorded main-CPU share.
Recorded 8 October 2026, AC090 68040, OpenPlay/openmodule.datatype; highest of two runs. This is one internal workload measurement, not a universal speed-up or independent hardware benchmark.
87% → 3%Recorded main-CPU utilisation for one module-mixing test.
Nursery · A network of useful things
What if the spare computer next door could help your Amiga?
A service shouldn't care which box has the fastest processor.
Nursery is the companion to OpenMulticore. An Amiga program asks for a named capability—such as media decode, a document render or TLS key work. The system can locate that capability on a board in the same Amiga or an appropriately paired Cradle on the local network.
Service discovery, pairing and encrypted LAN transport have been built in the OpenService programme. Cradle-wide orchestration, the richer Nursery view, complete cluster scheduling and reliable integration across all hardware remain engineering work. No service available? The application must handle the result and use a local fallback when it has one.
ONE NAME. MULTIPLE POSSIBLE PROVIDERS.
Amiga programRequest: media.decode/1, doc.render/1 or opentls.key/1
OpenService / NurseryFind a compatible, permitted implementation
Local AutoConfig boardVirtual or physical compute and service adapter
Paired Cradle on the LANNamed service, bounded buffers and encrypted transport
No service? Local fallbackThe program continues on 68k when it has a local path; the device itself does not perform the fallback work
The Team's build-and-run philosophy
Start in M68K.
Start in M68K.
Grow without throwing anything away.
One programme can keep a useful AmigaOS/68k implementation and gain optional sections for other processors. The full portable loader and matching native-module system are future work; the compatibility-first contract informs what the Team is building today.
A real 68k path
Write a program or kernel of work that still means something on an ordinary Amiga. No exotic accelerator should be required merely to launch it.
Declares what it needs
Use the OPEN interfaces and bounded memory grants to make capabilities explicit, inspectable and testable.
Match code to hardware
The planned loader can select a matching x86-64, ARM64 or later backend when present, otherwise translated 68k on a board or the main CPU.
Compare, then release
Check identical results, overhead, CPU0 responsiveness, memory safety and real AmigaOS behaviour. A design isn't a release until it passes.
A named PiStorm board is hardware, not a CPU instruction set. PowerPC compatibility interfaces, ARM64-native workers and universal fat binaries are not represented as universally available today.
The open libraries · The Amiga Environment Runtime
Every library matters. Rebuild them for tomorrow.
Preserve the behaviour. Rebuild the foundations. Library by library, rewritten from scratch, built to last.
The Amiga is an environment the Team provides, not a machine it emulates. The contract is each library's calls, structures and behaviour, with 68k code as the program format. The ABI tests are the spec: what passes them is the Amiga.
Each library is a clean-room rewrite, an open twin of its OS 3.2 original. It keeps the documented API, the ABI and the library vectors, and gives them new, tested implementations. Programs see the same calls, the same registers and the same structures. The code comes from the NDK 3.2 headers, the autodocs and side-by-side tests against OS 3.2. AROS is studied for how it works, never copied. The Team's code is MIT licensed; GCC and other third-party tools keep their GPL and other licences.
01 / ONE FIRMWARE
The same kickrom on every tier
A minimal kickrom acts as firmware. It starts first, then loads the rest. On a real Amiga it sits in the Kickstart ROM, stays small and loads 68k builds from disk. On an x86-64 or ARM64 host it has no size limit and loads native builds.
02 / A FACE AND A BODY
Same calls, the right code
Each library keeps a 68k face: its jump table, library base and structures. Behind the face is a body chosen for the machine. A real Amiga runs the 68k body. On x86-64 and ARM64 cores the JIT calls a native body built from the same C. Both give the same results, bit for bit.
03 / THE TESTS ARE THE SPEC
Side by side with OS 3.2
Every library is tested beside OS 3.2's own. The same calls go through both, corner cases included, and each difference is listed. A library ships when its list is empty.
| Tier | The firmware loads | Runs the code | Extras |
|---|---|---|---|
| Real Amiga | 68k bodies, from disk | the 680x0 | what the machine has fitted, such as an RTG card |
| PiStorm and the Pi appliance | native ARM64 bodies | the AC090 JIT on ARM64 cores | OpenGPU on the Pi's GPU, and the host services |
| x86-64 hosts | native x86-64 bodies | the AC090 JIT, with a core per application later | OpenGPU on the GPU, and the host services |
The rewrites of the OS 3.2 libraries, devices and resources go under the name OpenBench. Where each one stands, and how it compares with OS 3.2's own call for call, is on the OpenBench page, generated from the Team's status table. Replacing every library is a long programme and is not complete.
The first native bodies, measured
On an x86-64 host, 50 of the 88 entries run native by default, where the native body beats the translated 68k one. Short tag and string calls stay on the 68k body for now, because a native call costs about 20 ns.
One busy x86-64 host: read the ratios, not the absolute figures. ARM64 hardware is not yet measured.
BEYOND MULTICORE · THE TEAM'S LONG-TERM OPERATING-SYSTEM DREAM
THE EXPERIENCE
THE COMPUTE FABRIC
A NEW OPEN OS
OPEN, END TO END
DISTRIBUTED, NOT DISTANT
HUMAN IN CHARGE
What if the Amiga's next operating system had no hard edges?
Imagine a personal computer that still feels immediate, understandable and yours—but knows how to call on the right processor, the right machine and the right service wherever they're available.
Yours, not the infrastructure's
Keep the directness of the Amiga: responsive interaction, discoverable devices, transparent control and a personality that doesn't disappear beneath layers of cloud configuration.
A machine made of capabilities
M68K, x86-64, ARM64, future RISC-V and specialised cores could become compatible resources. Programs ask for work to be done, not for the user to memorise the wiring.
Built on libraries the Team understands and owns
Compatible, newly implemented libraries could become the bridge toward a separate Amiga-inspired OS, free to explore a new scheduler, memory protection, component lifecycles and APIs. That's research, not an announced replacement for AmigaOS.
Publish the rules
Open interfaces, transparent formats and permissively licensed original code can encourage hobbyists, university teams, board makers and commercial developers to build compatible pieces.
The room becomes the computer
A classic A1200, a PiStorm accelerator, a Cradle on an x86-64 host and future compute boards could work together, with explicit trust, discoverable services and local-first fallbacks.
Safe by design
Permissions for resources, signed or verifiable components, observable scheduling and controllable service trust would matter as much as raw throughput.
This is deliberately a vision. The Team has not shipped a separate custom operating system, a universal distributed scheduler or transparent cross-architecture application execution. This long-term research ambition would continue alongside—not quietly rewrite or replace—compatible AmigaOS and OpenUp. A future custom OS would need its own licence, compatibility, security, build and release gates.
A thought experiment in silicon
Imagine a Nursery full of RISC-V cores.
A different architecture doesn't have to mean another incompatible Amiga.
One proposal sketches four RISC-V compute nodes with eight cores each—32 cores coordinated by a Cradle, offering services or carefully bounded jobs to Amiga programs. It is an exploration of affordable, open compute alongside familiar machines.
There is no qualified RISC-V compute cluster or native OS image in the project today. The design still needs its worker pool, health model, security identity, scheduler and real benchmarks before it can move from proposal to platform.
8RISC-V cores
Node 01
Node 01
8RISC-V cores
Node 02
Node 02
8RISC-V cores
Node 03
Node 03
8RISC-V cores
Node 04
Node 04
32 cores total · Research proposal, not deployed hardware. A future Nursery scheduler would need admission control, scheduling fairness, telemetry, failure recovery and encrypted trust between machines.
What exists · What needs work · What the Team dreams about
Bold ideas deserve precise status.
The purpose of this project isn't to announce things before they work. It's to build in public, test with evidence and give contributors the information they need to help.
The Team's foundations
- openmulticore.library 0.4: jobs, range jobs, and strict and page-grant options, with CPU0 as the fallback.
- AutoConfig cores and services boards, workers, memory grants and test tools.
- Native bodies for utility.library and the IEEE maths on x86-64 and ARM64 cores, the same bit for bit as the 68k bodies.
- openservice.device, chosen media, TLS and document services, and LAN pairing.
- A recorded AC090 and OpenPlay audio test on two cores. Independent checks are still to do.
The next proving ground
- Open libraries, one at a time, each tested beside OS 3.2's own: utility and the IEEE maths first; graphics, intuition and icon being rewritten.
- Unified release qualification on real guest systems, host/board targets and PiStorm hardware.
- Multicore native section loader, placements, signing and SDK distribution.
- Cradle Nursery dashboard and service-host lifecycle management.
- Verified throughput on multiple cores with real games, codecs and productivity work.
The custom OS ambition
- Open replacements for exec, dos and the rest of the firmware, the last step to a full open ROM.
- An independent, modern Amiga-inspired operating environment with new kernel, scheduler and security concepts.
- Reliable multi-machine orchestration and portable, distributed capabilities.
- RISC-V cluster and additional silicon backends.
- An open ecosystem where legacy Amiga and new systems can cooperate without being identical.
OpenMulticore source & spec ↗
Nursery & OpenService source ↗
AmigaChrome Cradle ↗
OPEN architecture ↗
The Team's original OpenMulticore and OpenService components use the MIT licence. GCC and the OpenAmigaGCC compiler toolchain remain under GPL terms, and external engines, ROMs and third-party libraries retain their own licences. Core JIT and service transport do not automatically make a board, program or remote path production-ready.
The people and the purpose
One team. Decades of engineering experience. Modern software development. Rigorous testing. One goal: to give the Amiga the future it deserves.
Human architected. AI tested. Team delivered.
The next chapter isn't owned by one processor.
Join the people building open interfaces, real applications, better devices and perhaps, one day, a new operating environment inspired by the computer that brought the community together.