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.