The Open ROM: the gateway to full multicore.
A Kickstart that is ours from the first instruction: open source, rebuilt in modern C++ with GCC 16.2, and designed from the start for more than one core.
OS 3.2.3's Kickstart was written for one 68k CPU. Its way of keeping things safe is to stop everything else: Forbid() and Disable(). That works on one core and blocks any second one. The Open ROM keeps every call, register and structure a program expects, and changes how the inside works so that more cores can run Amiga programs at once. With a single core it behaves exactly as OS 3.2 does.
Where it stands
Four stages, each step marked as it really is. "Done" means it has run, not just been written.
17 of 26steps done
- 17Done
- 7In progress
- 2To do
Open exec with OS 3.2.3's other modules
Our exec replaces OS 3.2.3's, and every other module is still 3.2.3's. This is the first boot, and the 0.30 preview.
- Done Open exec's self-test ROM boots and passes all 31 checks
- Done All 152 of exec's jump-table slots wired
- Done An AmigaShell and Workbench reached over OS 3.2.3's modules, once, by hand in a lab
- Done Exec built as a module of our ROM image builder
- Done Exec hands library and device loads to open ramlib
- Done A scripted, repeatable boot test: it says pass or fail from the lab's log, and keeps a screenshot of every boot
- Done The faults seen in that boot fixed: the 68040's start-up (exec now sets the 68040 up itself), the expansion boards and their fast RAM
An all-open ROM to a Shell
No OS 3.2.3 module left in ROM. Strap, dos, the handlers and the Shell all ours.
- Done ROM-safe builds of the open modules, with no writable globals
- Done 62 modules built with our GCC 16.2 toolchain
- Done Exec scans the address ranges our ROM header lists
- Done A module manifest and a ROM build anyone can repeat: the 1M trial ROM is built from source, and records each module's commit
- Done Get our trial all-open ROM past romboot: it now configures seven expansion boards
- In progress A boot volume: the lab's hard drive and the floppy boot (OS 3.2's Install disk starts its Workbench); an IDE boot isn't shown yet
- Done strap, then dos, then CON: and RAM:, then the Shell, run on a 68k, by hand in a lab
- Done The display and input stack behind CON:: graphics, layers, intuition, console, keymap, input
Workbench from an all-open ROM
Everything a Workbench needs, from our own code. The 1M trial ROM, built from source with nothing of OS 3.2.3's in it, boots OS 3.2.3's own Startup-sequence to the OpenBench desktop in the boot test. Clicks have activated windows on it since 17 October.
- Done ramlib and the disk libraries that start after DOS
- In progress intuition finished for Workbench: prefs, the display's own size and clicks are in; the rest is being checked against OS 3.2.3
- Done gadtools as a ROM module
- In progress graphics: an RTG Workbench at 16 bits is in; AGA modes above 1x fetch and more monitors are not finished
- Done workbench.library and icon.library
- In progress The remaining ROM modules: audio, ramdrive, battclock and card are in; scsi.device's boot from an RDB disk isn't shown yet
- To do exec complete: the capture vectors and a Software Failure requester (the ROM is for the 68040, so there is no 68000 build)
The gateway to full multicore
The same ROM, with more than one core running Amiga programs at once.
- In progress Every call marked pure, locked or anchored in its jump table
- In progress Per-object locks and atomic calls in place of Forbid() for cross-core safety
- In progress Per-application 68k cores on x86-64 and ARM64 hosts: exec's first step, a task's own code on a core of its own, is in draft
- To do Native library bodies on the calling core, behind the same 68k jump table
As of , morning. Everything still missing for a fully free system is in A free Amiga OS: what's done, and what's left. The 0.30 release on 31 October carries Stage 1 as a preview. Finishing Stage 3, an all-open ROM to Workbench, is our November goal. Progress library by library is on OpenBench.
New since 14 October
The all-open ROM has grown past OS 3.2.3's: one 1M image, packed, that carries much of what used to come from the disk.
A packed 1M ROM
Modules and files sit in groups, each its own compressed stream (LZ4, LZE or LZMA), unpacked when it's needed. The groups used only now and then are unpacked on first use. The target is 1M, never larger.
The ROM: volume
Programs reach files straight from the ROM: 23 verified commands, asl, locale, version, datatypes and our datatype classes, ARexx's libraries, openinput, realtime, the small handlers, a CD filesystem, our 11 prefs editors, OpenMonitor and OpenDock. A newer copy on disk still wins.
The 68040, set up by exec
The ROM is for the 68040. Exec sets the 68040 up at cold start, so the ROM keeps only a small stand-in 68040.library for programs that open it, 31,176 bytes smaller.
43 commands verified
43 of OS 3.2.3's C: commands, rewritten by the Team, give the same results as the originals on the open ROM, run from a file and made resident. The run found and fixed six differences.
Its own desktop look
OpenIcons are the ROM's default icons. OpenBar puts a clock, network, sound and a Prefs button in the Workbench bar, and Workbench opens at the display's own size.
More in the ROM
RTG graphics are ROM modules: OpenRTG and the ACRTG board's drivers. Native prefs are in the ROM too, and so is OpenSocket's bsdsocket.library, unpacked on first use.
Why it's the gateway to multicore
You can't add cores to an Amiga from the outside while exec, dos and the libraries all assume they are alone. With the ROM our own, every library is written to share.
Every call has a class
Pure calls touch no shared state and run on any core at any time. Locked calls guard shared state with their own lock. Anchored calls belong to the 68k's own world, such as tasks, interrupts, the screen and the file system, and are carried to that core as a message and answered.
A core per application
On x86-64 and ARM64 hosts, an application can get a 68k core of its own. It shares one address space, so programs keep passing pointers as they always have, and it takes memory from its own region so it never waits on another core's allocation.
Native bodies
Each library is a thin 68k face over a body. On a real Amiga the body is 68k code. On a host the same C++ core builds natively and runs on the calling core, so the work goes at host speed, with the same results.
The single-core rule: with no other cores, the class changes nothing, placement tags are ignored, and the cost is one test of a flag. Multicore is the direction, not yet shipped. See Multicore & OS.
What changes from OS 3.2.3
Programs see the same Kickstart. Here is what's different underneath.
| Area | OS 3.2.3 | Open ROM |
|---|---|---|
| Source | Closed, Hyperion and Cloanto | Open source, MIT licence. Written clean-room from the NDK 3.2 headers, the autodocs and side-by-side tests. No Kickstart, Hyperion or AROS code. |
| Language and compiler | 68k assembler and C, built with the compilers of its day | Library cores in lean C++ (gnu++23, no exceptions, RTTI, static constructors or libstdc++), compiled with GCC 16.2. Jump-table entry points stay C, and the reset and context switch stay 68k assembler. |
| Calls programs see | OS 3.2.3's LVOs, registers and structures | The same LVOs, registers and structures, each jump table checked against the NDK 3.2 .fd files. Side-by-side tests against OS 3.2 list every place they still differ. |
| Multicore | One CPU. Forbid() and Disable() are how code stays safe | Every call is pure, locked or anchored. Cross-core safety comes from per-object locks and atomic calls, never Forbid(). With one core it behaves exactly as OS 3.2 does. |
| Shape | A fixed 512 KB Kickstart | One 1M image, the same on every machine. Its modules and files are packed in groups, each unpacked when it's needed, and a ROM: volume carries commands, libraries and the prefs editors, so less comes from disk. |
| Processor | Any 68k from the 68000; a 68040 or 68060 needs its CPU library from disk | The 68040. Exec sets it up at cold start, so no 68040.library is needed; a small stand-in keeps the name for programs that open it. |
| Library bodies | 68k code only | A 68k body for real Amigas, and on x86-64 and ARM64 hosts a native body of the same C++ core behind the same 68k jump table, giving the same results. |
| ROM modules | Each module keeps writable data where the ROM allows | No module keeps writable globals, SysBase included, so every module is ROM-safe and any core may call it. |
| Mixing | All or nothing | Open modules can sit in a second ROM window and replace OS 3.2.3's one at a time, so each one is proved alone. The 1M trial ROM now carries nothing of OS 3.2.3's. |
| Library loading | OS 3.2.3's ramlib patches OpenLibrary | Exec hands misses to open ramlib's port, a documented hook rather than a patch. ramlib also looks in ROM:, and a newer copy on disk wins. |
| Versions | 47.x | 47 so OS 3.2 programs asking for 47 get them, with revision 100 and up for the open ones; ROM module builds are version 48. |
Compiled with GCC 16.2, as C++
The library cores are lean C++: gnu++23 with no exceptions, no RTTI, no static constructors and no libstdc++, so they are as small as C and need no runtime. They are compiled for the 68k with GCC 16.2.0 from our OpenAmigaGCC toolchain.
Checked at build time
Every jump table is compared with the NDK 3.2 .fd files during the build, and a core that calls anything except libgcc, or pulls in any C++ runtime, fails the build.
Tested six ways
Each core is tested at -O0 and -O2 on the 68000, 68020 and 68040 under a 68k emulator, against an independent model of the right answers. Then it is compared with OS 3.2's own on a real instance.
Where it stands
Exec's cores build with GCC 16.2, and its test ROM boots and passes 31 of 31 when built with it. All 55 modules of the 1M trial ROM are built from source with GCC 16, for size (-Os) by default and exec for speed (-O2). The 68k faces stay assembler and C.