Hi everyone,

I read on aros.org that John Knipper added a hosted AROS target for Apple Silicon Macs (darwin-aarch64), including the AArch64 CPU support layer.

Is this build available for download somewhere yet? If so, could someone point me to where I can find the binaries or nightlies to test it out?

Thanks!

maybe it still needs to be published, but it would be awesome to have a native version

This is simply shocking. ARM AROS hosted on Mac Mx...

Apple laptops are fantastic, they're really beautiful, but unfortunately the software is lacking, though we're just at the beginning.

I don't expect the author's goal to be a full native port to modern Apple systems. The MorphOS example demonstrates how difficult this is. I think his goal is to provide a fully functional guest operating system, which already offers fantastic possibilities: - we have a mobile AROS on modern hardware, - this isn't emulation, like Qemu or VMvare, but actual, real-world processor speed. I think the applications are portable between the Raspberry Pi port because it's the same ARM platform (please correct me if I'm wrong).

I also don't expect Apple users to be interested in such a system, but Raspberry Pi enthusiasts, if they also have a Mac, certainly have a reason to be interested in AROS.

I'm really excited about what's been happening in Amiga systems lately, and when it comes to AROS, I'm downright amazed.

On older cell phones an Android version of AROS works too!!!

https://youtu.be/...

Hi all,

The first official release in a brand new repository is in: https://github.co...tag/v0.2.0

It packs a lot of features, from resizing the Macaros window to dynamically change the resolution (only works with compatible apps or no apps running at all), cut and paste from the host to Aros, and extFat driver, but it also has an Aros port of Zed, the code editor (using my Rust cross-compiler), and last it has my port of Ferail my crossplatform file manager.

https://www.jkn.m...e-silicon/
macOS 12 Monterey or newer. Apple Silicon only.

https://www.jkn.m...e-manager/
https://www.jkn.m...

It's the first release so expect it to be a bit (lot of) rough around the edges.

I'll be happy to hear what you'll think.

Thanks,
John

Great news and great file manager!
I was intrigued by what you wrote about emu68k.library, and I tried to run my 68k program, but it didn't work. Do I need to configure it somehow?

My bad, let me build a new version, thanks the report, bear with me for the first version. But know the 68k bridge is still a work in progress.

Hello and welcome to arosworld.org, @jonx. Glad to have you here!

Your emu68k.library is something that many people waited for years. Could you let me know how much coupled it is with aarch64? Would it be possible to implement a secondary interpretter engine that could be compiled for other architectures (I'm specifically thinking about x86_64)?

I'm wondering what the compatibility level is between Macaros and Aarch64 on the RPi at the application exchange level. While preparing the toolchain for the RPi, I noticed that there are separate Aarch64 targets: Raspi and Native, among others. I chose Raspi for myself to have the greatest compatibility with my hardware, but it would be nice to be able to test the binaries before sending them to the RPi. With the current version of Macaros, my binaries don't work – they invoke guru, which is likely due to recent changes in the AROS repo. Out of curiosity, I tested two programs from Macaros on a Raspberry Pi 3b+: Zed and Ferrail. Zed caused guru, but Ferrail launched on the Raspberry Pi and worked correctly. Does this mean that these binaries are generally compatible with both the RPi and Macaros? I'll check if my programs will work on it with the next Macaros update.

@Bohun:
I experimented with the AROS Raspberry Pi versions of my games on MacAros and had these results:

1.
Jonx had provided an important tip on GitHub: Everything for MacAros must be compiled with the "-ffixed-x18" flag. So it was unavoidable to compile own binaries of my projects for MacAros because macOS reserves the x18 CPU register for its own use. Otherwise the binaries crash.

2.
On MacAros, gl.library relies exclusively on Softpipe, and gpufx.library does not yet accelerate some important functions.

3.
One promising approach was: Accessing Apple's hardware-accelerated OpenGL driver directly via hostlib.resource and polling Apple's GameController.framework directly. This allowed the games to run with hardware acceleration on MacAros. But after a few minutes, they crashed anyway. I will have to keep looking into this.


I’d love to find a solution for MacAros, because its harness allows for much faster automated tests than the Raspberry Pi does. That would make the development process a lot easier.

Hey guys, sorry, I needed some time off from my computer and will leave for a month of holidays at the end of next week.

But shortly, like @A500Fan is saying, everything for Macaros must be compiled with the "-ffixed-x18" flag. Apple uses this register for its own purpose and there is no way to use it, or even to save and restore it: the kernel zeroes x18 on every return to user space, so a hosted process cannot keep anything alive there.

@amigamia: thanks! The library itself is not very coupled to aarch64. The DOS launch routing, the hunk handling, the guest memory model, the typed marshalling and the library policy are plain portable C. What is aarch64 and macOS specific is the execution backend: it emits aarch64 instructions and uses Apple's MAP_JIT executable memory. There is already a second engine in the tree, a portable C interpreter, which I use as a differential oracle against the JIT (same register state, same sandbox, same callback model, byte exact comparison). It is not complete, it only covers the test corpus subset, so today it is not a general backend.

So yes, a secondary interpreter engine is exactly the realistic path for x86_64: define a proper CPU backend interface, finish the interpreter behind it, move the generic part of emu68k.library out of arch/all-darwin, then bring up hosted x86_64 with the interpreter. A real x86_64 JIT is a much bigger and separate project (fewer registers, different flag semantics, big endian loads, W^X rules per OS), and it should go through a small backend neutral IR rather than a second decoder emitting x86 directly.

@Bohun: at ABI level the two aarch64 targets are the same thing. Same little endian LP64, same ELF, same struct layouts and LVOs from arch/aarch64-all, and the native port is also built with -ffixed-x18, so one aarch64 AROS binary should run on both. Two things break that in practice:

x18. If your binaries are not built with -ffixed-x18 they can die at any random point on Macaros, and that matches the guru you see.
Host services. Anything that goes through hostlib.resource or the Mac side (display, clipboard, host media) has nothing to bind to on bare metal, and the other way round, code that touches real hardware has nothing on the hosted side. That is a dependency problem, not an ABI break.
Also a Macaros release is a snapshot of the AROS tree at build time, so building against a much newer tree can give you a module skew. I'll push an update before I leave. About Zed on the Pi 3b+, I would not conclude much from it: it is a very big Rust binary and 1 GB of RAM is likely not enough. Feraille running is the more meaningful result, and it is what I would expect.

@A500Fan: (1) confirmed, x18 is not negotiable on macOS. (2) gl.library is softpipe only for now, and gpufx does not accelerate everything yet, but before going around it, have a look at what it already does. gpufx.library is the AROS side front door to the Metal compute and blit path, and it is what FFView uses (FFViewX does its YUV to RGB conversion and scaling there). Measured on the booted system: 5 to 7 times faster on the video colour conversion, 10 to 13 times on the present scaling, with output identical to the CPU path. What is missing is the full GPU scene rasteriser, the 2D primitives are there.

The important part is that gpufx shares the same Metal device and command queue as the display window, so textures stay on the GPU and nothing fights for the device. If you open your own GL or Metal context through hostlib you get a second device competing with the window, plus its own memory, and I suspect this is a part of why your games die after a few minutes. Tell me which functions you need and I can look at adding them to gpufx, that is a much better place for you than Apple's GL driver, which is deprecated anyway.

(3) about the crashes themselves, look at threading first. GameController and anything AppKit related expect the host main thread, and an AROS task is not it. Calling back into AROS from a host thread that exec does not know about is another classic trap, and Objective C running on a thread with no autorelease pool will bite you after a while, not immediately, which fits "a few minutes". If you can get me a crash report from the harness I'll have a look. And yes, aros-ctl is meant exactly for that kind of automated testing, tell me what is missing for your games.

Both repos are public (https://github.com/jonx/Macaros, jonx/AROS on aarch64-darwin-graft).

For @A500Fan (graphics):
gpufx design and status: https://github.co.../README.md
The AROS side library source: https://github.co...libs/gpufx and the API header https://github.co...es/gpufx.h
The Metal side, inside the display shim so it shares the device and queue: https://github.co...etal_gpu.m
FFView, the real consumer: https://github.co...g/ffview.c (the GPU path is gpufx_blit() around line 192-265, the OpenLibrary("gpufx.library" with software fallback is around line 454). Build script for the FFViewX variant: https://github.co...videox.sh, context in https://github.co.../README.md
Smallest possible example to start from: https://github.co...pufxtest.c

For the x18 part (@A500Fan and @Bohun):
The finding and why save/restore cannot work: https://github.co...ION-LOG.md (section "x18 must be reserved on the hosted-Darwin aarch64 target"
The 20 line probe that shows the kernel zeroing it: https://github.co.../x18probe/
Build flags in general: https://github.co.../README.md
For @Bohun (host services versus bare metal): https://github.co.../README.md

For @amigamia (emu68k):
What it is: https://github.co.../README.md and the engine https://github.co.../README.md
The portable parts: public API https://github.co.../emu68k.h, DOS routing https://github.co...k_route.c, the library https://github.co...ibs/emu68k (placed under all-darwin today, but it is generic C), host runtime https://github.co...ted/emu68k
The aarch64 specific part and the portable interpreter, which is the interesting one for him: https://github.co...ted/jit68k and https://github.co...d_interp.c

The harness for@A500Fan: https://github.co.../README.md and the tool itself https://github.co...t/aros-ctl

For you, @amigamia
https://github.co...ability.md
The component-by-component portability map, the CPU and platform backend boundaries, the interpreter-first route to x86-64, and why a JIT is a separate project with its own cost.

If you can, please post on the Macaros issues and discussions section so that all this benefits to everyone

And abut Zed causing Guru on Raspi, it's because I needed to customize many things in Aros to get it to work like adding new functions into Aros, stdc, and many things go through the host bridge for now. So this can't work anywhere else for now. Happy to hear that Ferail works. The port to Aros is only at the very beginning but if you think it's an interesting tool that you would use, I'll be happy to work on this a bit more very soon.