I would love to see a Switch emulator for the M1, although I certainly understand why it'd be a last-priority for emulator developers.
I know /nothing/ about emulator development, but I wonder what the performance of a Switch emulator written for the M1 using Metal for graphics would look like. I'd expect the Switch and the M1 both being ARM would be an advantage? Would be curious to learn more if anyone in this space wants to weigh in.
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):
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.
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
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.
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.
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.
>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.
If you are interested in Yuzu, you're probably also interested in Ryujinx. In a departure from most advanced emulators (Yuzu, RPCS3, etc), Ryujinx is written in C#.
what a horrible language choice for an emulator, no wonder it under performs compared to Yuzu, ton of micro stutters, i bet it's due to the GC and the JIT compiler; on top of using more memory
just for clarity, cpu/audio emulation needs predictive performance, you can't have that with C# due to the managed nature of it
I don't know, the name implies they target the RyuJIT, which is a state of the art JIT compiler. I feel in general games should perform really well on a JIT since they are predominantly performance sensitive in a tight loop. Dolphin also has a JIT if I'm not mistaken. The alternative is to interpret which in theory should have worse performance (though in practice there's definitely exceptions to that rule).
I think it should be possible to achieve predictable performance, though it depends on the qualities of the JIT, it won't work if it's constantly recompiling or allocating stuff that needs to be garbage collected of course.
Glad this was flagged. A lot of people have a misconception of managed languages being slow compared to your regular ol' binary program, these days that couldn't be further from the truth. In traditional high performance C/C++ development you have to manually split your code into hot and cold paths, static analysis optimization can only go so far.
Do you want to inline this function in your loop? Yes and no, i.e. you might be taking up some valuable registers in your loop, increasing register pressure. Time to pull out the profiler and experiment, wasting your precious time.
Managed languages have the advantage of knowing the landscape of your program exactly, as __that__ additional level of managed overhead can help the VM automatically split your code into hot and cold paths, having access to the runtime heuristics of your program allows it to re-JIT your hot paths, inline certain functions on the fly, etc.
It's pretty common for game engines to disable background GC and explicitly call the GC only at certain times (e.g., between processing the current frame and before starting the next frame). Sometimes that can be done using the default GC and sometimes it requires a custom incremental GC.
Same idea applies to a JIT. Getting the best performance may require tuning the JIT to only run at certain times (e.g., before starting a level).
Unity uses C# for a certain layer but the engine itself isn't C#. They also do some work for ammortized multi frame GC.
That said, there's tons of games written in less than optimal languages for major portions of the game, like Naughty Dog games in the PS1/PS2 era used a lisp based language for a lot of things
Apart from what others have pointed out about Unity's engine code being C++ it also comes with support for IL2CPP which compiles the code to cpp which can be optimised.
We've used this on all Unity projects I've been part of and it really makes a difference in performance.
Can anyone comment on how you can emulate a modern console like Gamecube/Wii/Switch and run games at full speed? Last I checked, the (CPU cycle accurate?) SNES emulator Higan/BSNES still experiences framedrops/slowdown on modern hardware, and that's for a 30-year-old console. What's the shortcut/secret sauce that allows emulating modern consoles on modern PCs at full speed?
Modern computing architectures tend to be very similar. They use a process called high level emulation(HLE) where API calls to the emulated kernel, subsystems, graphics driver are basically "translated" to the host system, which allows for the high speeds and relative accuracy that lets games run beautifully. In the end, the only "traditional" emulation you'd be seeing is the CPU for the switch, which is a 64bit ARM CPU, and translated into x86 via a JIT.
If you think about wine and dxvk, it's pretty much the same concept, without the need to emulate a CPU.
On the contrary, Higan uses low level emulation(LLE), wherein the actual hardware of the system is emulated as faithfully as possible, which is very CPU intensive.
An interesting result of this is some emulators like PPSSPP or Dolphin can run several heavy games near flawlessly at this point yet they still can't emulate the system's UI or home screen because they use low level OS syscalls that games don't need. RPCS3, a PS3 emulator recently managed to boot into the cross media bar after a lot of work (https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb)
The Dolphin can run the Wii menu fine now [1]. Indeed, every game in the Dolphin compatibility database is rated as playable with only minor glitches ... except one: an N64 title that uses a custom emulator. The title itself works fine when the binary is extracted and run on an N64, it's some low level weirdness that does not.
But yeah, the progress reports are now mostly fixes for very low level stuff like emulating a specific hardware cache just right or matching the /exact/ semantics of AMR64 floating point for certain titles.
You can take advantage of high-level emulation since the graphical primitives map more directly onto what the GPU is already poised to provide. Plus modern games are also coded more in line with modern practices (e.g. to do their own frame-limiting and wait for hardware input to be fed from the OS), rather than driving the bare metal hardware.
This means that less accurate emulation can still result in a playable game, whereas missing the timing of how the SNES CPU moved data to the PPU could render scanline-specific register twiddling used on actual hardware into gobbledygook.
But even still, higan/bsnes were notoriously CPU heavy because it took a different approach to emulation (perfect low-level emulation of the actual hardware system). Even with SNES, if you were willing to relax perfection you could get very playable games with much less CPU usage, as shown by emulators of the 90s.
In fact that was my own intro to emulation, zSNES playing SNES FF6 on Pentium-class hardware. The Switch has evolved a lot since the SNES, but so too have desktop computers.
Maybe Higan/BSNES are like this, but if you've ever used SNES9x/zSNES or similar, you can see that we've been able to run playable games since the 90s.
Those also have some significant tradeoffs between emulation accuracy and speed, though because they were focused on playable games at speed, not necessarily perfect accuracy.
The later emulators have tried to do low level emulation to get accurate cycle counts and whatnot to make it as close as possible to a real SNES.
I understand it caused some issues for other emulators because fan made patches and such were sometimes coded to work with the quirks thereof, but I agree that I never noticed such when playing games.
As far as I understand it, besides the fact of stellar people working on emus like Dolphin, the hardware on the GC/SW/Wii are much simpler and closer to that of the hardware it's being emulated on. That provides for an easier translation experience when emulating each bit of hardware. This is in contrast to not as closely matching hardware on much older systems, even if they're comparatively slower. A really good example is PS2 emulation which runs pretty well today but is crazy complicated with the Emotion Engine which does not map well to our current PC architectures.
Might be wrong about this but I believe SNES emulators are now approaching "perfect" emulation which is to exactly emulate the hardware down to every defect. This is what can slow things down but will give you perfect reproduction of games. A lot of modern emulators use hacks (sometimes game specific) to achieve the performance you see but can result in experiences not like the game on a native console.
All that being said though, the teams working on these emulators really matters in terms of the performance they're gonna eek out of modern day computers.
I don't think it's the emotion engine itself that's difficult, it's that the PS2 has a whole bunch of chips (EE, IOP and two VPUs) which need to be emulated in tandem and kept in sync.
The slowest bit of emulating old machines is executing everything in lockstep -- people would count CPU cycles, to know exactly how far through drawing the screen the console was. It was common to do things like "after drawing line 51 of the frame, quickly reconfigure the graphics hardware to change sprites/colours/etc.
In some cases games would even rely on facts what happened after each cycle of a 3 cycle CPU instruction.
Fortunately for emulator writers, that's not possible on modern hardware. They operate much more like a series of independent boxes, and you can't do such exact cycle counting. That means you can do things like rewrite ARM into x86 and just run the CPU, and only need an approximate count of how many cycles it has done.
Well, I think the major difference is that the modern-ish 3D consoles are no longer "cycle accurate" even at the hardware level... it's inherently a variable frame rate environment so it's not like an SNES where you have to emulate multiple chips running in exact lockstep.
It's much more like an interrupt driven PC architecture where things just...happen, instead of hard polling, ta, say, every vblank or the end of every scanline.
This is also why they can run at different resolutions, even different aspect ratios. (For instance, most N64 games will quite happily run at 16:9 1080p/60 fps. There might, depending on the instructions used, be some distortion on things like menus, but overall it works surprisingly well.
This is a simplified answer, but more or less since the Nintendo 64 a common method has been to JIT the source binary to the target one. Dolphin had an interesting progress report on debugging JIT instructions with net play a while ago! [1]
Interfacing with the graphics hardware is often “translated” to more conventional DirectX/OpenGL APIs.
CPU cycle accurate is why bsnes experiences framedrop, you basically emulate hardware at the software level. Dropping the scope to “just run the software”, and the level of abstraction you need to emulate is higher and would require less power to do so.
Additionally, modern console might use the same hardware as PCs themselves (I don’t know how close they are), so let’s say if a console is using x86 already on a linux-based machine, then your job to write emulator would be to only implement whatever missing on the os, passing through everything else to be ran natively
Purpose built hardware can do many operations in a single or fewer clocks. For example reading an input, doing some math to it, and outputting it. A modern microcontroller can do some of that pretty fast, but change over to something like a PC and you're actually fighting a lot of delays in processing. For example you cant just thread out the various hardware components and emulate them efficiently. The OS is going to schedule when those threads execute. Therefore you get locked into one core and are dependent on single clock speed. Even then you're fighting inefficiencies in emulating real hardware.
I wonder if there is a difference in accuracy of emulation. Even back in 2000 ZSNES ran smooth for the vast majority of games. The exception were games with special chips on the cartridge like SuperFX.
Ran smoothly, but not very accurately. There are a LOT of games that do not play correctly (or in some cases, at all) on ZSNES.
It's relatively easy to get the first 90%, but each 1% after that doubles the difficulty. This is especially true on older machines where the code tended to be hand-written assembly. When working with modernish machines where there's a SDK for C/C++, high level emulation tends to be much easier to accomplish-- and this is why there wasn't anything even remotely resembling accurate for N64 until the last few years. It was only feasible recently.
Gamecube, Wii, Switch, X360, PS3, PS4 -- these are machines that will remain HLE for a long time. Cycle accuracy will be arduous and require CPU resources we likely won't have for a long while.
Higan is slow precisely because it's cycle-accurate Low Level Emulation. This requires emulating the machine at every cycle tick and replicating every portion of the machine from each step up.
Modern machine emulators (outside of hypervisor based virtualization) don't use cycle-accurate emulation. Instead they use high level techniques such as intercepting 3d draw routines and translating them into OpenGL/DirectX/Vulkan API calls. In addition, they take heavy advantage of JIT to compile the code to more close to baremetal instructions for the target architecture, which isn't viable for cycle accuracy.
One of the main reasons older machines require LLE is that they're cycle intolerant and rely on specific timing for many effects (although, you can still get 90% there with most, just being "close enough"). Newer machines (from the PSX on, for the most part) use pipelined architectures and are strongly interrupt based, so timing is generally less important.
Tl;Dr - No matter the case, cycle-accurate is the ideal case. But newer machines are just more tolerant to bad timing than older machines.
I've always thought that a project like this, enabling piracy while being financed via Patreon, would eventually meet its doom once some bee's nest is struck. I'd like to hear thoughts on the matter.
Bleem successfully defended their commercial PlayStation emulator against a lawsuit from Sony, setting a solid precedent in US law even though the legal costs ended the company.
Emulators absolutely do not enable piracy. One could argue that their existence implicitly encourages it, but they certainly don't "enable" it by any means.
There are many different ways to legally obtain games to run on emulators, Switch included.
Emulators do enable piracy. But so do computers, and it's not a valid argument against them by any means. It's perfectly legal and moral/ethical to use an emulator to play games in many circumstances.
I’m absolutely a fan of engineering feats like these being made more accessible for educational purposes. Even in college, I built a NES emulator on an FPGA.
But to argue that it’s primary motive is not to facilitate (and potentially profit from) piracy is not grounded in reality.
No, emulator primary motive is enabling longevity for the target system, since hardware get damaged over the years, CD/DVD/Cart get corrupt over the years, without it, there will be literally no way to preserve a console games and ecosystem, for example I own 805 switch physical games, but because I know Yuzu exist I don’t have to worry about if one day the cart get damaged or something
played maybe around 5% of it, I am mostly collecting them as modern gaming is rapidly becoming too unbearable for me(MTX, Lootboxes, the recent NFTs, etc), and I am most likely plan to just play the collection(which I collect with criteria of at least 1% of interest of playing ,so no baby games like Racing with Ryan etc) when I stop buying modern games
No. My primary motive, especially with these more modern emulators, is to have a better experience playing games I own. To play 3D games at higher resolution and more stable framerates. Also, so I don't have to breakout old consoles anytime I want to play those games.
The court has already decided in history that you're wrong with your assertion and I don't know why do you so heartly want to overturn that by defending corporations against the users who legitimately want to play their games on other systems.
Absolutely not. MAME's primary purpose is to document the hardware and ROM revisions, and to preserve as much accurate data about the machines as possible. You can use MAME sets to actually replace damaged ROMs, and the tools that come with MAME (romcmp) can help you identify an unknown board if you pull chip data off of it.
Much on the contrary, I'd say piracy is a console emulators most common use. But it's still fine. All that matters is there's a possibility they're being used for good things.
If someone does something bad he's responsible for it, not the creator of the tools he used. Even if you don't like what most people use something for, just the possibility of one person doing it right is much more than enough reason for it to built. We call this individual freedom, and it's much more important than (game publisher's financial) security.
Honestly that's my take on it: piracy is a matter of accessibility.
As a marketer, I can even see the benefits of "free distribution of content" to people that wouldn't buy it anyway, and you're still building your brand on those people - they will, eventually down the line, buy your IP if they had good experiences with it.
I became a GTA fan thanks to it, and to modding, when started to be able to afford games I bought into the series.
If I haven't developed the emotional relationship with the game, nowadays I wouldn't care less about it.
This is why I like using emulators with full debug tools. At that point it's quite obviously about research and development. Emulators that just have a game window and hacks on hacks to get your game "backups" to run aren't as fun.
These projects tend to intentionally make using them harder than other methods of piracy. Last I checked, to get this running, you had to dump the keys out of a hacked switch before the emulator will work.
But to dump the keys from a hacked switch, you had to already have a hacked switch which you could have just loaded the games on to which would run better than emulating it. So right now, there is little reason to use this project other than curiosity but in 10 years it will be the easiest way to play switch games when hacked consoles become too rare and nintendo doesn't care anymore.
It's not strictly intentional; it's a consequence of the strict DRM on modern consoles. Decryption keys are needed for content to be loadable and in some cases you need the actual OS the console is running, too.
It all feels like such a small obstacle compared to the effort of building an emulator. So they are able to emulate all these complicated apis and hardware, but couldn't create a little tool to dump the rom decrypted so it can be loaded without keys.
I can only assume they intentionally leave this last hurdle up so the general public are locked out until the development is done and the console is commercially obsolete.
There's nothing that stops the roms from being dumped decrypted, but then they're not a copy of the original rom are they? Tools are available to decrypt the rom afterwards, and plenty of emulators will run those programs (easy way to test homebrew). It also ensures that the roms haven't been modified, as private keys are still private.
That's where the group that validates rom dumps gets their name from: No-Intro. Because old rom dumps used to modify the rom to add an intro advertising whoever cracked or dumped the rom. https://en.wikipedia.org/wiki/Crack_intro
IANAL, but in the act of distributing the emulator not including any decryption keys and/or otherwise copyrighted content by the console vendor gives a valid defense against copyright infringement
I know /nothing/ about emulator development, but I wonder what the performance of a Switch emulator written for the M1 using Metal for graphics would look like. I'd expect the Switch and the M1 both being ARM would be an advantage? Would be curious to learn more if anyone in this space wants to weigh in.