Execute .elf on Apple silicon

Thanks to this MakeCode Arcade on Raspberry Pi (including RetroPie, Recalbox, Batocera etc.). @Vegz78 and @mmoskal did a great job - thanks you.
I have managed to run my games on my Raspberry Pi with minor issues.
But then I thought maybe I could run it on my Apple silicon Mac. Then I could run my game on a more portable platform. It is ARM64 like my Raspberry Pi and UNIX based.
It is easy to get the .elf file and compile, but execute it on my Mac is much harder.

chmod a+x *.elf
zsh: exec format error: ./arcade-Save-funcktionFruit-Crush.elf

There is some problems:
EVTEST - Find the keyboard key value
/sd/arcade.cfg - Modifying file/folder at root/high level folders (Hope you understand me)
ALSA - I don’t think Mac use ALSA

zsh: command not found: alsamixer

1 Like

Thank you for your feedback and interesting undertaking here, @MK97-2007! If your prayers through your @mmoskal tag are heard, we might achieve a quantum leap in this subject, compared to the progress I have made lately, and could not have done to begin with without his guidance. Legend has it that his brain works like a compiler, that he can see pictures and play through whole games just by looking at the machine code, and that he sees the world like the green letters in the Matrix. But sadly, he seems very busy and seldom appears on the forum with his faucet of oracle wisdom.

If you have any issues, please post them on GitHub, if there’s anything I can do to help.

Bear with when I try to reason from a layman’s, hoping that someone from the @makecode team could give you a better answer.

But the executable file format is different between Win(PE/EXE), Linux(ELF) and Mac(Mach-O), and the compiled machine code within is different between various architectures; arm, x86_64 etc.

Since my Hackintosh is Intel based, I have no personal experience with both how much closer you are on your Apple silicon architectures-wise for running these 32-bit MCA arm .elf game files, if they support 32-bit, and manage to run Linux .elf executables.

Then, there’s the supporting runtime, which mainly are found in different folders with rpi in their name in the libs folder in the pxt-common-packages repostitory. This is all Linux, with ALSA, framebuffer, Linux Input Subsystem for controllers etc. If this somehow could be set up and matched as a runtime on your Mac through homebrew, or if there are similarities in the MacOS, I do not know;

The closest thing, but much less different in terms of executable and runtime, that I have done, was to allow the 32-bit MCA .elf executables to run on a pure 64-bit Batocera ARM Linux distro. Here I cheated with an ugly hack, where I just copied all the required runtime/dynamic library files from another 32-bit distribution together with the launcher.

This might be more difficult on your Mac(do not know for certain), and probably not possible on Windows(but maybe there is a solution there as well).

In a more principled perspective, I have come to believe(maybe falsely) that it should be possible to compile and run MCA games natively on all Win, Mac and Linux, and on most common architecture without too large workloads and modifications, if you really know what you are doing(I don’t yet). And the thread below is dedicated to different ways of getting them running on different platforms as apps in different ways. Some of the @makecode people are also experimenting all the time, so I hope you also join and post your findings:

  1. Is the golden prize, which is the native executable, where I suspect that the right combination of commands on a local pxt server, then through the right crosscompile docker image or toolchain already could get you running Linux executables on any architecture platform with what is already in the pxt source code. Regarding Mac and Windows, I am a little more uncertain what might already be there and what might have to replace or modify the Linux/RPi libs.

  2. Is the the silver prize, to run MCA games as bytecode in a (bundled and small?)VM, almost like a standalone native executable, that they already have for Mac, Windows and Linux, which is a bit slower than native, but which should not be a concern on regular computers and on anything but the weakest microcontrollers. @mmoskal has claimed that this solution has regressed a little over time, but unless I am confusing the VM hardware in experimental/beta mode of the arcade online editor with something totally different, the VM seems to be updated and up and running again. But I have not yet managed to put these pieces together in a working solution.

  3. Then there are a lot of other exciting experimental projects going on, where they have tried UWP apps and now building a whole PWA in React that probably can be packaged as a cross platform standalone app somehow at https://arcade.makecode.com/kiosk. But, unless one can make this more nimble without 100MB+++ chromium browser or .NET/Mono or whatever for each game file at 3-400kb, this seems a bit overkill compared to the 2 above. But maybe it can be done differently?

And probably many other possibilities. Personally, I am researching points 1 and 2, and experimenting at the moment with trying to find very small virtual containers or machines that can ship with and run the arm Linux .elf games different places. I want it standalone or bundled with each game, and as small as possible, without any need to install some special Java virtual machine, special application/launcher or whatever on the host machine. I am no personal fan of 137MB Java VM taking up hard drive space for apps I seldom run and nagging about updates all the time, and especially not the recent trend where every app ships their own 137MB of different versions of Java VMs(together with their 3-400kb apps), filling up even more precious HDD space.

I hope you find something that works and that I do not send you on a wild goose hunt with misinformation stemming from my current level of knowledge.

1 Like

Happy B day @Vegz78 !!!

1 Like

Thanks for a great answer.
Speaking of virtual machines, I have UTM installed and can install Debian(the same as my Raspberry Pi). I have though about it, but I would like to run it natively. But MacOS won’t let you play with operation system.

1 Like