I’m inspired to start this project due to myself and others in my community who are fed up with the current state of affairs of the Amiga NG platform. AROS has done a brilliant job since the fall of the Amigas original parent company.
I’m currently developing a OS4.1/MorphOS/68k native AI enabled IDE to help with this massive undertaking. As soon as it’s finished and released work can get started with this and several other projects.
I’m committed to the Amiga, and our community, and am simply finding an engineering solution to the current legal tangle, stymied OS development, and totally unresponsive commercial entities. While I’m still financially supporting the platform and have invested in an extensive collection of hardware and software, I still dream of all the cool things that can happen with this independent project.
This page and the Facebook group will serve for now.
Come join me in the new future playground!
JEd Development Update: Canonical Supervised Compilation Validated on the AmigaOne X5000
Development of JEd has reached an important technical milestone.
JEd is a native IDE project intended primarily for AmigaOS 4.1 and MorphOS. Its long-term purpose is to combine a lightweight Amiga-native editor and build environment with modern development assistance, structured diagnostics, and carefully controlled AI integration.
Milestone 24 concentrated on the foundation required for dependable compiler integration: launching a narrowly authorized compiler command, supervising it, validating its output, and transporting trustworthy results back to the parent application.
The final experiment was successfully validated on an AmigaOne X5000/40 running AmigaOS 4.1.
What was demonstrated
The completed experiment successfully:
accepted and validated a canonical compiler descriptor;
resolved AmigaOS program-relative paths;
safely quoted paths containing spaces;
launched the approved GCC compiler;
compiled a real C source file;
produced a valid 32-bit, big-endian PowerPC relocatable ELF object;
verified that both the child and parent observed the same 647-byte result;
checked the ELF section structure;
verified the exact raw bytes of the compiled .text section;
validated the expected symbol and object semantics;
transferred a typed observation record between processes;
reconciled the child result in the parent;
produced a dynamic success wrapper containing the measured object size;
released all owned resources and exited cleanly.
The final hardware result reported a successful compile, successful semantic validation, a zero child exit status, and an overall successful experiment result.
Why this took careful engineering
A compiler can appear to work while the surrounding system remains unreliable. The purpose of this milestone was not simply to invoke GCC once, but to develop a mechanism that JEd can eventually rely upon.
During the work, several platform and architecture issues were identified and corrected:
incorrect handling of multidimensional character storage;
AmigaOS PROGDIR: path materialization;
quoting paths containing spaces;
typed parent-and-child record ownership;
distinguishing bounded captures from complete object size;
separating compiler diagnostics from wrapper output;
identifying a synthetic ELF fixture that had been mistaken for authoritative compiler output;
defining semantic validation independently of whole-file size;
correcting parser token compatibility;
increasing bounded observation capacity;
distinguishing a formatted readelf digest from the hash of the actual machine-code bytes;
moving a large parser workspace off the limited AmigaOS process stack.
The stack issue was particularly useful. Increasing the observation capacity was correct, but storing a 16 KB parser buffer as an automatic local variable created a 17,904-byte stack frame. The parser was redesigned to use an explicitly owned bounded workspace, reducing its PowerPC stack frame to approximately 1.5 KB.
These lessons are directly applicable to the final JEd architecture.
What this milestone does—and does not—mean
Milestone 24 proves that the supervised compiler mechanism and validation policy work on real AmigaOS hardware.
It does not mean that the complete JEd project workflow or build interface is finished. Production IDE routing was deliberately left unchanged while the mechanism was tested in isolation.
The next phase is Milestone 25: the Controlled JEd Integration Gate. That phase will determine how the validated compiler path can be introduced into JEd without weakening the narrow authorization, typed process communication, memory ownership, stack-budget, and validation guarantees established by the experiments.
No release date is being announced at this stage.
The goal is steady, documented progress backed by automated testing and real hardware validation—not a burst of publicity followed by silence.
Milestone 24 is now committed, tagged, and complete.
16th July 2026
Got to milestone 25:
Integration is going well,and resulted in a native AmigaOS JEd interface opened and saved a source file, invoked supervised GCC 11.2 on an X5000, and generated a verified big-endian PowerPC object file.
1 August 2026
Progress has been happening, up to milestone 28! JEd now has a drop down menu, andis looking more like an IDE. Milestone 29 is, unfortunately, fixing a class level keyboard issue/powered USB hub issue I’ve had with my Simulant keyboard (which I love) but means I cannot evaluate if the shortcut keys work, so once the side quest is done, forward momentum will resume.
Ok, we’re at 17/9/2026, AmiWest is heading towards me, so I’ve put out a developer version of my JEd IDE. So that means I’m at this point with AROSNG:
AROS NG — time to move from idea to architecture.
I’ve been thinking for quite a while about what a next-generation AROS environment could look like if portability were treated as a first-class design goal from the beginning.
The long-term idea is not simply “AROS on another CPU.”
The goal is an Amiga-like environment that can live across modern and legacy architectures while keeping CPU implementation, API compatibility, and binary compatibility as separate architectural problems.
The current direction is:
• ARM64 as the initial bring-up architecture
• QEMU ARM64 as the first reproducible virtual reference platform
• Raspberry Pi-class hardware as an accessible physical ARM target
• x86-64 and RISC-V as additional modern native targets
• PowerPC and 68k retained as important native/legacy targets
• 68k compatibility treated separately from native 68k builds
• OS4 PPC compatibility treated as a later research layer rather than an initial requirement
The intended compatibility priority is:
Native NG first
→ 68k compatibility
→ OS4/PPC compatibility research
The architecture draft also treats endianness, SMP, memory protection, driver portability, filesystem assigns, Workbench-style interaction, graphics/audio abstraction, licensing/provenance, and compatibility trust boundaries as things that need to be considered early rather than patched in later.
ARM64 is only the first reference architecture.
It is not meant to turn AROS NG into an ARM-only project.
The larger goal is portability across ARM64, x86-64, RISC-V, PowerPC, 68k, and other suitable targets through explicit architecture boundaries.
Right now this project is intentionally in:
ARCHITECTURE / COMMUNITY INPUT
—not implementation frenzy.
I’d rather get experienced AROS and Amiga developers involved while the assumptions are still cheap to change.
Some of the questions I’d especially like community input on:
• Which existing AROS subsystems are already portable enough to retain mostly unchanged?
• Which areas have historically caused the most architectural pain?
• What should the first minimal useful ARM64 target include?
• Which graphics path makes the best early reference implementation?
• What should define the first practical 68k compatibility milestone?
• Which parts of the system should remain historically compatible, and which should be allowed to evolve?
• What lessons from current AROS should a next-generation architecture absolutely not repeat?
The point at this stage is not to promise universal compatibility next week.
It is to get the structure right before there is enough code for bad decisions to become expensive.
More to come after AmiWest, but I’d love to hear ideas, objections, warnings, and “you really should talk to X about this” suggestions now.
That is exactly what this phase is for.
