[grishka]

> if it's running on an ARM processor does it just run the instructions directly?

You can't just run random instructions like that. That code is compiled with the assumption that there's the Switch's OS and hardware underneath, which means it will do all kinds of things, like calling directly into the kernel and assuming a particular address space layout, that would crash it under a different OS.

ARM has hardware virtualization. If the host OS supports it, you should be able to make use of it.

[jyrkesh]

I think it does beg the question though, of whether it might be possible to dump the Switch OS and firmware and run it on some alternative ARM hardware (with some modifications for redirecting weird custom chips). IIRC the Switch is running an overclocked Tegra (X1?)

IANAL, but in the US at least, I think every person would need to buy their own Switch and dump the software themselves for it to be even remotely legal.

[roblabla]

I attempted this a while ago, running the Switch OS (Horizon/NX) on a Jetson TX1. It's definitely possible, *but* it requires modifications to the OS services, otherwise you'll just fry the Jetson (that was a lesson learned the hard way...). The pinmuxing between the two devices is different, so you'd need to modify that at least. And then you'd probably need some more modifications to get joycons to work (how do you sync them without a rail), etc...

The kernel however runs absolutely fine with zero modifications required. HorizonOS is a microkernel, and all the components are fairly well separated. To make it work on a jetson, you'd only have to replace a handful of services to make it work.

> IANAL, but in the US at least, I think every person would need to buy their own Switch and dump the software themselves for it to be even remotely legal.

Honestly, I'm pretty sure it'd violate the DMCA DRM protections in the US (you'd have to dump some crypto keys and provide them to an EL3 reimplementation, like Exosphere, to run anything below the kernel).

[tibbon]

I might be making a bad analogy, but I don't think this would work any better than dumping the CMOS firmware for a C64 (6502 processor) and hoping you could just run it on an Apple II or NES, even though they had the same architecture processor (also a 6502).

Maybe things are more standard now these days, but the support hardware around it, memory layout, etc... at least for the 6502, made this prohibitive.

[grishka]

As I understand it, there are two ways to approach emulating a console that has a firmware, whether it's a BIOS or a full-fledged OS:

- You could emulate the hardware only, on its lowest level, and make the user provide the firmware dump. This makes the emulation more faithful, but sourcing the firmware isn't always easy.

- You could instead go up a layer emulate the firmware interface that games see. This might get you performance benefits, because you now have the freedom to optimize the low-level implementation details for your particular host platform, but that would mean the emulation itself would not be 100% accurate.

[astrange]

There is a Switch emulator using virtualization on M1 Macs.

[Wowfunhappy]

Wow, that’s neat. Link?

[saagarjha]

https://twitter.com/daeken/status/1340777743244509196

[whoisthemachine]

Interesting, Dolpin emulates the Wii and Gamecube OS's to some degree, I would assume that would be necessary for the Switch as well. What would that have to do with ARM assembly however?