Running The SNES Classic Mini Emulator On The Raspberry Pi

Unless you’ve been living under a rock, you’d be familiar with Nintendo’s hugely popular Classic Mini consoles. Starting with the NES, and now followed with the SNES, the consoles ship in a cute, miniature enclosure and emulate Nintendo classics using the horsepower of modern ARM chips. These consoles use an emulator that has been created especially for the purpose by Nintendo, in house – and [Morris] [krom] wanted to see if he could take the emulator on the SNES Classic Mini and run it on the Raspberry Pi.

Yes, there are already SNES emulators on the Raspberry Pi. But anyone interested in the nuts and bolts of emulation can see the clear interest in the tricks and techniques Nintendo are using to achieve the feat. In particular, Nintendo engineers have the benefit of access to internal documentation that can make the job a lot easier, particularly when dealing with edge cases.

[krom] has been kind enough to share the full instructions necessary to recreate this feat. One stumbling block was the difference in hardware between the Raspberry Pi and the SNES Classic Mini – the Pi using a Broadcom GPU instead of the SNES’s Mali hardware. However, a workaround was simple enough – swapping out some libraries was all that was required. It also gives some interesting insight – it looks like the SNES Classic Mini relies on the SDL libraries to run.

While emulation of the SNES has been a largely solved problem for quite some time, it’s great to see more work going on in the field. In particular, the official Nintendo emulation is reported to be particularly adept at running games that rely on the SuperFX chip.

For another take on SNES emulation, try out your old Mario games on the HoloLens.

Thanks [Morris] for the tip!

30 thoughts on “Running The SNES Classic Mini Emulator On The Raspberry Pi

  1. I’ve been wondering if this would work- it’s pretty awesome! Next will be to see if the front end works (I assume this is just the emulator portion), then compile the clovercon source to support the I2C gamepads. Add a shutdown switch and s reset button tied to a GPIO pin, and you’ve got the SNES mini pretty much fully replicated.

  2. Broad emulation of the SNES has been a mostly cobbled together and solved “enough” problem for some time but people rarely seem to appreciate that it’s very broad and very high level emulation. Nobody that I know of is actually emulating the SNES (or even the NES) at the bare metal level. Quite frankly, we don’t have powerful enough hardware to do so and nobody has written the software either.

      1. Bsnes (now Higan) definitely counts. Byuu has done a fantastic job of documenting and replicating every detail of operation. You need a recent i7 to really run everything at full speed, which is insane.

    1. There are emulators that even lower level than that. There is a NES HDL emulator, that is using a FPGA to replicate the circuit of the NES. I’m pretty sure that there is somewhere a baremetal emulator for ARM processors.

      1. I don’t know of any that emulate the physics of the actual circuits to generate the output though. is one approach that tries to accomplish that down to a pretty low level. They literally photographed the die and the roughly 20,000 components and have been working on emulating them gate by gate.

        Even then, that approach has it’s limitations and doesn’t go deeper than that. It’s not like we are modeling electrons at that level.

        1. It is actively anti-useful to emulate sub-gate behavior for a digital system such as the NES.

          Honestly, it’s actively anti-useful to even emulate gate-level behavior instead of the logic that it represents.

          It is anti-useful because it’s orders of magnitude more computational load for no greater accuracy.

  3. Fun article. I learned a bit or three :) SNES was my favorite of them all.
    Anyone have any suggestions for a good N64 emulator? All of the ones I have tried (again after 15 or so years lol) still have rendering issues in one place or another. Mario Golf seemed to really send them crazy. I figure you folks would have some good insight.

    1. All N64 emulators that I’ve seen have a list of “hacks per game”, I think they never really nailed good emulation.
      My guess is that it’s an exotic platform with very few games, giving little incentive to do proper emulation, and just winging it per game was easier.

      With rendering you need to emulate the rendering of the N64 with modern 3D rendering. Most likely the artifacts that you are seeing are a result of that, or a result of the N64 having very specific behavior in edge cases that current generation 3D rendering hardware doesn’t handle the same.

      1. Hi daid303 and thank you for the sensible response. I am glad to know I was not the only one that thought the setup for N64 emulation was obtuse. Yeah there were really only a few games I wanted to play so maybe it is best to do as you say and go with the hacks per game scenario.

      2. N64 will probably never be fully emulated, thanks to the re-programmable hardware that could be made to do all kinds of cool things real fast if loaded with the proper custom microcode. Kinda hard to emulate that.

        1. Since there are no new games being produced for the N64 is it possible that someone could reverse engineer all the hardware configurations that were actually used? or is that exceedingly hard, even for people that know what they are doing?

  4. In particular, Nintendo engineers have the benefit of access to internal documentation that can make the job a lot easier, particularly when dealing with edge cases.

    All of Nintendo’s internal documentation related to the SNES had been leaked during its commercial lifetime. Higan’s source is a much more comprehensive documentation than any of it … and also wholly inappropriate for use on a ≈1GHz ARM.

    Whatever cleverness is in their emulator—and I’m not certain whether there’s any—has to do with only needing to get a limited set of games working perfectly.

    1. Are you referring to the programmer’s manual? That’s not “all of Nintendo’s internal documentation”, just the amount of documentation relevant to programming the SNES. And hell, it’s not even the whole programmer’s manual that was leaked, there’s a whole section about the 65816 itself that’s missing. (Granted, info about the 65816 is hardly specific to the SNES, which is probably why they didn’t take the time to scan it.)

      Nintendo would have information regarding each chip and its internals, how exactly the PPU1 and PPU2 are implemented, etc., given they were the ones to design the chips in the first place. Probably even the HDL source or masks for them (keep in mind none of the chips have been decapped yet). None of that appears in the programmer’s manual, and SNES emulation is still not perfect. Just a few months ago a subtle bug with scrolling was found in just about every SNES emulator, including higan.

      Of course, Nintendo’s emulator isn’t perfect either, there’s a fairly visible bug in Yoshi’s Island that’s been noted already. I do think it’s premature to assume there’s nothing they’ve caught that others have overlooked, though.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.