The OPEN architecture
One Amiga.
One Amiga.
Many ways
to compute.
The family didn't disappear. It spread out. The Team is reconnecting its edges around the platform the whole community recognises.
From original Motorola 68k machines to PiStorm, x86-64 and ARM64 acceleration, PowerPC history and future RISC-V possibilities: AmigaOS stays at the centre. Open interfaces let contributors build on common ground without requiring everyone to own the same computer.
One familiar platformOPEN / EXPANDABLE
AmigaOSM68K base · OPEN interfaces
M68KNative origin
x86-64Host runtime
ARM64Acceleration path
PiStorm68k hardware bridge
PowerPCCompatibility goal
RISC-VOpen future path
An architectural direction, not a promise that one binary already runs on every machine. Platform adapters and native worker availability vary by target.
Cross-platform without losing the soul
Not six competing Amigas.
Not six competing Amigas.
One ecosystem, with more doors.
The same shared APIs can be implemented in different places. The goal is to strengthen what works on real 68k Amigas while giving newer processors useful, compatible roles. Here's where each family fits—and where the work is still in progress.
M68K
FoundationThe original execution model, AmigaOS conventions, graphics and input expectations remain the Team's reference. The baseline includes a 68040 with FPU for AC090 development.
x86-64
Host runtimeAmigaChrome runs on x86-64 cores, with the AC090 JIT and a page in the browser. The open libraries' native bodies run here behind the same 68k faces: utility and the IEEE maths first. Extra host compute serves Open-family services where adapters exist.
ARM64
Engineering pathAC090 has an ARM64 JIT. The native bodies for utility and the IEEE maths are built for ARM64 and match the 68k bodies bit for bit under emulation. ARM64 hardware speed is not yet measured. ARM64 native sections remain an OpenMulticore design target.
PiStorm
Hardware pathwayA bridge between classic physical Amiga systems and modern compute, not a new CPU instruction set. The Open-family goal is software that can serve PiStorm and non-PiStorm owners alike.
PowerPC
Compatibility goalPart of the Amiga story through WarpOS, PowerUP and later machines. The OpenMulticore specification describes possible PowerPC compatibility faces—not universal support today.
RISC-V
Future / openA compelling open instruction-set future. The Team is leaving room for implementers and native worker backends without claiming a supported RISC-V build already exists.
Architecture refers to CPU execution; PiStorm refers to hardware integration. The presence of a name here is not a compatibility certification.
The Team's engineering philosophy
Build for the Amiga.
Build for the Amiga.
Run where capabilities exist.
Start with a real AmigaOS program and a reliable 68k path. Add optional modules or compatible services for accelerated hardware. The system selects what is actually available and falls back cleanly when it isn't.
One shared API
Develop against familiar AmigaOS and published Open interfaces rather than each board maker's private assumptions.
68k stays first
Keep a portable M68K base. Optional architecture-specific modules and service backends are additions, not a mandatory replacement.
Capability decides
OpenMulticore can select compatible worker code and explicit memory grants. The architecture defines how jobs and completions should behave.
No hardware? Run on.
If an extra core or accelerator isn't available, the designed fallback is the main 68k path. Real support is validated per board and backend.
Build-and-run, not build-and-abandon: the Team wants maintainable source, repeatable toolchains, clear performance evidence and software that remains useful across generations of hardware.
See it in practice: AmigaChrome Cradle provisions complete test Amigas, while ACBuild and ACKitchen connect recipes, build jobs, deployment, guest observation and diagnostic evidence.
The growing OPEN family
Open interfaces.
Open interfaces.
Real things to build with.
These projects are separate repositories, standards and application efforts. Some are already usable in defined test environments; others are being designed or brought into the system. Browse the source and help move the boundary forward.
OpenGPU & OpenRTG
A common route for displays, graphics drivers, OpenGPU streams and compatibility layers. The goal is to use host or board acceleration without forcing every program into a bespoke renderer.
View OpenRTG / OpenGPU source ↗OpenMulticore
Publish jobs to extra cores, grant explicit memory access, receive completions and fall back to the main processor. Its architecture-specific backends remain an evolving qualification effort.
Explore the multicore, library and future OS vision ↗Read the MIT-licensed specification ↗
OpenAudio
One audio-facing direction for players, games and creative software, with an emphasis on correct formats, low latency and reusable output services.
Explore the Open project family ↗OpenSocket & OpenTLS
Networking, modern transport and secure communication are prerequisites for useful web, mail, file and development software on AmigaOS.
Explore OpenSocket source ↗OpenMedia
An interface programme for media decode/encode and efficient presentation. Platform-specific hardware paths and media formats must each earn their compatibility claim.
Follow OpenMedia development ↗OpenUp
A cohesive set of applications, libraries and setup tooling, from document creation to networking and printing, designed around AmigaOS rather than a second operating system.
Explore OpenUp's source ↗Open SDK
Headers, docs, examples and build recipes give one shared contract. OpenAmigaGCC 16.2.0-open2, released 12 October, fixes nested library calls in the NDK's inline headers and threads in C++. GCC and the other tools keep their GPL and upstream licences.
View the Open SDK ↗The Port Atlas
A living catalogue of existing Amiga ports, publicly available source, ideas for acceleration, licences and the tests needed to move from candidate to playable software.
Explore the Port Atlas ↗AmigaChrome
An Amiga platform hosted on x86-64 and ARM64 cores, with its own A1200 and AC090 runtime, storage and devices. The Amiga screen shows in a browser window: Fit, Sharp, or Native, where the Workbench takes the window's own size. Real AmigaOS remains the system people meet and use.
Browse AmigaChrome's source ↗
Not a closed garden
Build it.
OPEN.
Build it.
Fork it. Improve it.
Open is not an appendix to AmigaChrome. It's the idea: publish interfaces, make contributions possible, leave room for different hardware makers—and don't ask the next generation to start from zero.
See the open-source family ↗
Reconnecting the edges
Amiga users grew apart in hardware.
Amiga users grew apart in hardware.
Not in what made them Amiga.
M68K developers, PiStorm builders, PowerPC veterans, accelerator makers, emulator authors, Linux developers and people with one carefully preserved A1200 all have something to contribute. One community shouldn't mean one company, one chipset or one way of doing things.
For the player
Find what runs, what needs work and what might be worth reviving. Each port deserves proper source credit and honest playable-status evidence.
Explore games and ports ↗For the developer
Use familiar APIs, open specifications, a published SDK and an m68k-first approach. Contribute improvements to the shared base rather than six incompatible forks.
Explore the SDK ↗For the hardware builder
Build an implementation of the open contract, publish a driver, or offer worker cores. The hardware gets stronger when compatible software follows it.
Read the architecture spec ↗A few things worth being clear aboutAmbitious. Open.
Ambitious. Open.
And honest about what's next.
Will one binary run on M68K, x86, ARM64, PPC and RISC-V today?
No. The Team's philosophy keeps a 68k/AmigaOS base and allows compatible backends or native worker sections when hardware and software support them. x86-64 is an existing AmigaChrome host execution path; other backend and compatibility work varies. RISC-V is currently a direction for future implementers, not an available build.
Does OpenMulticore move the whole of AmigaOS onto extra cores?
No. The design keeps one Exec on the main motherboard CPU. Extra cores execute explicitly submitted, bounded jobs with grants and completion signals. That approach aims to preserve OS compatibility and determinism rather than treating all AmigaOS tasks as safely parallel. The next design gives each application its own 68k core, with calls that belong to the system going to CPU0. It is decided, not yet built.
Is PiStorm another CPU architecture?
No. PiStorm is a hardware acceleration ecosystem that may use ARM processors. It appears alongside CPU architectures to welcome its builders and users into the common Amiga-facing interface strategy.
Is everything here really MIT?
The Team's own AmigaChrome platform and Open-family code is MIT-licensed where the project's repository says so. Compilers such as OpenGCC inherit GCC GPL licensing, and third-party libraries, game engines, images and game data keep their own terms. Read the exact notices before redistributing software.
How can you tell whether a port is ready?
The Port Atlas separates source availability, reported external Amiga ports, provisional internal builds and verified releases. A repo checkout or article is not a qualified AmigaChrome binary. Input, graphics, audio, save files, clean exit, rights and reproducible target builds all have to be checked.