xqemu VS box64

These projects are called compatibility layers, or "translation layers" sometimes. I think XQEmu (OG XBox on PC) works the same.

Yes:

https://xemu.app/

https://xqemu.com/

Are both original Xbox emulators built off of QEMU. I've only used Xemu, but performance was pretty good for the games I tried on it (it doesn't have a way to upscale rendering yet though).

It's indeed a bit like a kexec.

On system initialization, kernel routines are copied into RAM by the bootloader[1]. Executables run in ring 0, and have a jump table to call kernel routines in their own address space (IIRC) [2].

As such, loading any executable counts as a soft reboot.

Also, there is a functioning open source emulator, Xqemu [3] (and its sibling/fork focused on speed and compatibility more than accuracy, xemu [4])

I recommend reading "17 mistakes Microsoft made in the Xbox security system", which is very informative [5].

[1]: https://xboxdevwiki.net/Boot_Process

[2]: https://xboxdevwiki.net/Kernel

[3]: https://xqemu.com/

[4]: https://xemu.app/

[5]: https://xboxdevwiki.net/17_Mistakes_Microsoft_Made_in_the_Xb...

There is one emulator currently that does do that, the "XQEMU" emulator for the original Xbox https://xqemu.com/

It's in its infant stages at the moment according to the "Emulation General" wiki and focuses heavily on "accuracy" over performance

Other emulators such as CXBX-Reloaded have made larger strides, currently emulating roughly 10% of the software library

It's also worth stating, while the Xbox seems like an "easy" target, being based on an ia-32 (Pentium III) PC with an Nvidia GeForce chip (somewhere between a Geforce 2 and 3 at the time) it is an absolutely monstrous beast with minimal documentation about its hardware and numerous "gotchas"

It also has a very small library of 'exclusive' content which detracts from gaining many developers

I see it can do more now, already tried some stuff. But see it is now more mature than months ago. Will try factorio again https://github.com/ptitSeb/box64/issues/665

Also, in the discussions of box64 is this thread: https://github.com/ptitSeb/box64/discussions/524 My guess is that you have to install both box64 and box86, the latest mesa drivers with vulkan support. And then try to launch the game with proton. There is also this issue that shows factorio running on a Rock 5B: https://github.com/ptitSeb/box86-compatibility-list/issues/284

macOS runs x64 executables just fine through Rosetta so I don't see why Wine couldn't make use of that hardware acceleration.

It's also possible to only simulate the entrypoints through Rosetta and then execute native aarch64 code from there. On Linux https://github.com/ptitSeb/box64 does exactly that, for example. However, with the performance Apple has been able to squeeze out of Rosetta, I'm not sure of that workaround is even necessary.

Recently, I got a server from Oracle Cloud, having 4 cores and 24GB of RAM. Then, using a software called Box86 and its 64 bit version called Box64, I succeeded in running Factorio! Unfortunately, 1.1.80 ran at 3 UPS! I went through each major version, testing each individual one down to 0.12. Here are my results!

You could try https://github.com/ptitSeb/box86 and https://github.com/ptitSeb/box64/ , I believe they allow you to emulate x86_64 on aarch64, though I have no experience with them, so cannot say for sure.

git clone https://github.com/ptitSeb/box64.git

If you have time and patience take a look at box86 and box64. These are basically like translation layers that allow x86/x86_64 applications to run on ARM. I personally haven't use them yet, so I can't provide a guide or vouch for game compatibilities. But by the look of the progress made by them so far it looks promising.

You can follow progress of this on https://github.com/ptitSeb/box64/issues/635

This analogy falls apart quickly and really isn't great like trimming sandwiches might be like using box64 and box86 and you would be using a bread machine (compiler) to make another bread machine (another/newer compiler). You need to read up on what a compiler to a specific CPU instruction set does to see why a binary made for one can't just run on another without translation or taking the source code and making a binary (what your sample script does) that runs on that CPU arch.

Actual impact is not sure, but I can speculate. Short term customers pay more for ARM. Long term RISC-V products just got relatively cheaper for high end and might see a BoARM to go along with Box86 and Box64 so compiled programs on android (Dalvik byte code programs wont need it) will 'just work'. I wonder if this had anything to do with Google making RISC-V Android version a thing. As long as a big percentage of the device cost is the CPU it should still be competitive.