Afaik the main issue is not the CPU architecture, but the Graphics APIs. Macos has only very old OpenGL and doesn't support Vulkan at all. And you're right, they probably don't have the effort to spare to implement Metal.

As for the CPU architecture, probably the dynamic recompilation step that turns ARM code to x86 could be skipped.

Just to show, how viable it is, there's a closed source emulator for Android that's probably base on Yuzu (with surprising good performance):

https://www.youtube.com/watch?v=Ex_AArUJ8cY

The suspicion coming from it having the same bugs as yuzu itself.

The graphics shouldn't be an issue. macOS supports Vulkan via Metal, using MoltenVK. Plenty of other emulators already support Vulkan on macOS that way.

> probably the dynamic recompilation step that turns ARM code to x86 could be skipped

I don't know if Switch could be emulated with Wine-like approach, if not, it would be tricky to intercept syscalls without an ARM-to-ARM DBT. Performance impact should be minimal though.

I'm not an expert on the ARM64 architecture, or the Switch OS, but from what I can tell, the interface between the OS and the app consists of function calls to the OS api, and syscall-s, that are triggered by the svc instruction. I'd guess the app is statically linked against the OS API, so for the OS calls, the addresses can be patched (or alternatively the emulated OS libs can be mmap-ed to the correct address), and the svc calls can be replaced with a jump to a thunk that emulates it's behavior.

Both seem to be possible, since arm64 uses fixed instruction length. I don't think svc calls can be trapped in-process with user privileges, and it's even less likely it can be done in a portable way.

So probably some level of source-patching needs to take place, but it requires just a high-level understanding of the code, not a full decompilation-recompilation.

Seems like a fragile approach when you can't even be sure about which bits are code and which are data... You might end up patching a svc syscall only to find out that it's actually some constant used in the logic of the game.

> I don't know if Switch could be emulated with Wine-like approach, if not, it would be tricky to intercept syscalls without an ARM-to-ARM DBT. Performance impact should be minimal though.

You don't need a DBT, VMs on arm64 are very cheap. You can just use Hypervisor.framework really.

I only know a small amount but from what I have seen, having the same CPU arch is not really that important, as we have seen, you can run x86 apps on the M1 at blazing speeds. The hardware in modern consoles is becoming pretty standard, so the vast majority of effort goes in to emulating the libraries and such the switch comes with.

Modern emulators are a lot like Wine these days where they are just translating the custom api calls to something that works on a desktop OS.

>> CPU arch is not really that important

It actually depends more on the memory ordering. To speed up the running of x86 apps, the M1 has a strong memory-ordering mode designed to match x86.

Yes, the emu for M1 will likely run very well, and OpenGL 3.x works very reasonable on M1, despite being marked as 'deprecated'. From the issue tracker, they want to use Molten Vulkan (on Metal) and clang lacks some C++20 features they use.

I've been running the PCSX2 PS2 emulator on M1 (rendering using either OpenGL backend or Software), it runs my favorite game SSX Tricky great, including joystick support, sound and smooth graphics.

No emulator wants the burden of maintaining something like an OpenGL 3 renderer. They already struggle to keep the D3D11/Vulkan/Software ones up to date. Anything else is pretty much getting the axe as soon as possible, and pretty much all of those that have an OpenGL renderer use opengl4 or gles2

Upvoting for SSX Tricky. When I got nostalgic for games most of them are EA titles from that era.

Thanks, I'm still hoping for an SSX sequel :)

There is an experimental PS4 emulator that ran using QEMU, taking advantage of the fact that the PS4 is x86. Something similar could be done for M1 and ARM.

https://wololo.net/2021/09/08/release-spine-ps4-emulator-v-2...

Aside: if Apple's M1 processor is ARM-based, why do we bother making the distinction? If anything I feel like this hurts more than it helps because Windows and Linux need better ARM support too.

Because, quite frankly, ARM silicon is held back by other vendors. Apple is unique in the ARM space in that they actually make an attempt at retaining compatibility across SoC iterations. Linus Torvalds has famously gone on multiple rants about how much of a mess ARM chips are - every new chip usually meaning a full reshuffle of the register map and new drivers everywhere. The work being done on Asahi Linux, on the other hand, is very likely to carry forward to M2, M2 Pro/Max, etc.

FWIW, M1 Macs are also one of the few ARM platforms that will let you[0] actually install regular GNU-and-Wayland desktop Linux. I think the current crop of Windows on ARM machines will also let you install Linux, of course. But most Android hardware ranges from mildly to very hostile to users who want regular Linux - even if there's a bootloader unlock, the hardware is going to require all sorts of extra vendor-proprietary drivers that won't work with a standard distro. This also ties in with what I said before about backwards-compatibility across multiple SoCs.

The reason why people treat the M1 as separate from all other ARM hardware is because it actually acts like a computer; providing the performance and control you expect from something bearing the name. Most other ARM vendors are not aiming to provide that.

[0] You do have to sign the kernel with your Owner key, but that's manufacturer-supported, so it counts.

I guess because M1 describes the entire platform in shorthand (CPU+GPU+performance characteristics), whereas ARM only describes the CPU instruction set.

According to marcan’s Twitter, Apple actually broke the ARM spec in ways most companies are literally not allowed to do. Part of the deal is likely that Apple was not allowed to call their chips ARM.

Do you have the links for those tweets by any chance? I’d like to learn more about this.

Unlike other ARM CPUs, M1 optionally supports x86 memory model, that said, it doesn't matter outside of x86 emulation.

From what I know, SPINE doesn't use QEMU at all to emulate a PS4, it works with the same concept of Wine, a compatibility layer that translate Orbis syscall with Linux one. Its name follows the same "SPINE is not an emulator" geek joke.

According to Google, Orbital is the one using QEMU.

How does one GPU acceleration when running on a VM (as I imagine QEMU is doing here)?

Also random thought, but can the opposite be achieved? That is, installing Orbis (PS4 OS, based on FreeBSD) on generic PC hardware?

This is probably not exactly the same, because I'm assuming the ps3 is maybe emulated very different, but rpcs3 is able to boot up into the XMB.

https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb

Same with xemu, using QEMU to emulate the original Xbox.

>I'd expect the Switch and the M1 both being ARM would be an advantage?

Most emulators interpret the machine instructions in software so there wouldn't be any advantages there. Some are now incorporating dynamic recompilation but I doubt it would have any noticeable impact on ARM vs x86.

Honestly I can see it being a higher priority for switch emulator devs pretty soon. A rpi5 would be in the right neighborhood of being able to emulate the switch when using the virtualization extensions. The CPU is already more than there on the RPi4, just the GPU is a bit anemic. If they have it working against KVM, hypervisor.framework is then an almost trivial amount of work.