9 ms·

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

• meibo 5y ago
  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.
  • udbhavs 5y ago
    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 https://www.pcgamesn.com/emulation/ps3-emulator-rpcs3-xmb)
    • indolering 5y ago
      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. [1]:https://wiki.dolphin-emu.org/index.php?title=Wii_Menu#Keyboard_Is_Not_Completely_Displayed https://wiki.dolphin-emu.org/index.php?title=Wii_Menu#Keyboa...
• NhanH 5y ago
  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
• danbolt 5y ago
  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. [1] https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-report-august-2021/ https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-rep...
• mpyne 5y ago
  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.
• erdaniels 5y ago
  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.
  • Grazester 5y ago
    You mean PS3 not PS2. The latter didn't use the cell.
    • erdaniels 5y ago
      Ah, correct! I meant the emotion engine. Updated comment. Thanks.
      • Grazester 5y ago
        I still think your comment would be better suited to the cell process with its programmable SPE's
  • LinAGKar 5y ago
    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.
• Natsu 5y ago
  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.
  • emodendroket 5y ago
    The SNES9x inaccuracies are pretty hard to notice these days. It still sees wide use on devices other than full fledged desktops and laptops.
    • Natsu 5y ago
      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.
• ajmurmann 5y ago
  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.
  • Firehawke 5y ago
    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.
• devwastaken 5y ago
  https://youtu.be/QS4fzElm8zk https://youtu.be/QS4fzElm8zk 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.
• TylerE 5y ago
  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.
• CJefferson 5y ago
  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.
• deaddodo 5y ago
  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.