A Long-Winded Opinion: MiSTer FPGA vs RetroPie

First, A Story

My personal history with software emulation started around 1997. During an Internet search for information about Final Fantasy V, I stumbled onto the burgeoning world of video game emulation.  My chief interest was in the discovery that fans were taking it upon themselves to translate RPGs into English which Japanese publishers had declined to release in English-speaking countries - ostensibly because it was too expensive to localize them.  There was a whole world of NES and SNES JRPGs to be discovered, and you could play them on your computer, for free!  At the time I didn't have a computer powerful enough to even run NESticle.  In fact I wrecked my Windows 3.11 machine trying to get it to load because I didn't have much of practical understanding of desktop computers at the time.  Six months later I had a brand new PC running Windows 98 and sporting what were, for the time, very respectable specs.  I jumped in feet first to the world of emulation - spending a lot of time on Zophar.net and practicing my search-fu on pre-Google search engines like Yahoo, Altivista and Hotbot.

Back then pretty much all of the emulators available were incomplete.  Certain games worked better on one but not the others.  Some emulators ran at full speed, others couldn't.  Some emulators were resource hogs and would only run at full speed on extremely high-end machines.  Some lacked sound, or sprite layers, while others focused on features like Mode 7.  

ROMs (files containing the binary data copied from the original game cartridges) were somewhat easy to find if you knew where to look, but it wasn't like it is today where you can find nearly complete archives of every game ever made for a system all in one place. They were piecemeal, scattered, and almost totally un-standardized.  Headers? Headerless? Padded? Raw? Some emulators would play ROMs in one format, but not others.  Some cartridges were easier to dump (copy data from) than others, so there were a lot of games that weren't accessible at all to the emulation scene in the early days.  Sometimes a ROM relied on a feature that was not implemented in an emulator so people would hack the ROM to short-circuit it and get it to run anyway, but this almost always resulted in something not working correctly - either the game couldn't save progress properly, or it would only work in one emulator and not the others.  Many of the people dumping the data off of cartridges and fussing with hacking the ROM images would go beyond just getting the game to work and would add their name or the name of their "scene group" to the ROMs in the form of "Intros" which were little audiovisual splash screens that would come up when the game booted.  No doubt to the people who inserted these little intros they were a clever way to show off their "mad skillz" and get credit for figuring out how to dump the ROM and make it work.  But aside from looking like garish graffiti or straight up garbage, intros also caused checksum failures because the game code no longer matched the expected values, and caused compatibility issues with certain emulators.  It took many years and a lot of effort to get those ROMs out of circulation and replace them all with clean (i.e. unaltered) dumps.  As far as I know we're still finding them in circulation occasionally.

Over the years I watched as emulators crept closer and closer to being feature-complete, but I noticed that no matter how fast a computer I built to run them, every emulator I used still had issues.  There was always screen tearing - even with Vsync.  There was always input lag no matter how many knobs I turned to drive it out.  And most of them still had some problem or other running certain games - crashes, glitches, sound out of sync or missing layers.

Every computer I build prior to 2005 had at least some consideration given to emulation - I had my own ROM sets which I had painstakingly curated from a thousand sources over the years, I had all of my emulators arranged in folders and icons on my quick-launch bar that either launched emulators, or scripts to launch emulators with my custom settings.  In 2005 when I was building a new machine and about to copy all of that over and set it up on the new machine, I asked myself a question: "How many times have you actually played a game on an emulator - I mean all the way through", and I had to reluctantly admit that of the thousands and thousands of ROMs I had accumulated, I had only played one game to completion on an emulator.  The game that originally drew me in, Final Fantasy V, had received an official English language release in the Final Fantasy Anthology before any of my SNES emulators had matured to the point where they could play the game, so I had played through it on the PlayStation (and yes I realize the PS version was being emulated, but it also just worked).  The only game I had ever played to completion on an emulator was Metroid Fusion and the only reason I had done that was because the ROM leaked before the game's official release date and I was so excited to play it, I pushed past the incorrect aspect ratio and constant screen tearing to play it.

After the realization that I was spending all my time fiddling with settings and waiting for smarter people than myself to fix glitches rather than actually playing and enjoying games on them, I mostly abandoned software emulation.  Instead I focused on building out my physical game collection and playing on original hardware.  I had no inclination to look back.

A few years later in 2007, the PowerPak was released and (for me anyway) kicked off an intense interest in flash carts - all of the convenience of ROMs without mucking around with emulation.  Problem was that the PowerPak was always sold out, and very expensive.  It took quite a while before opportunity and disposable income lined up.  I bought my first flash cart in 2011 (an Everdrive 64 v1).  I was so impressed that in 2013 I placed a several-hundred-dollar order to Krikzz's store and bought flash carts for most of the rest of my systems.

Since then I have acquired flash carts for every system I own for which one is made - everything from the Atari 2600 to the Nintendo 3DS, and installed optical drive emulators (ODEs) in every platform I own for which one exists.  Needless to say I'm a huge fan of using modern data delivery on original hardware - as I said earlier, all of the convenience, none of the problems.

Enter MiSTer FPGA

The MiSTer FPGA was on my radar for several years before I gave serious thought to getting involved in it.  The platform drew me in with the promise of playing accurately reproduced arcade games.  While I'm a big proponent of original hardware, I don't have the personal wealth, storage space, or patience to handle even a modest collection of real arcade hardware.  A handful of things held me back from initially dipping my toe in MiSTer.  Firstly the documentation was not neophyte-friendly.  It's not bragging to describe myself as a very technical person. I have decades of experience with very complex hardware and software architectures and have professionally done everything in the business from racking servers and switches to creating an automation platform from scratch to writing thousands of lines of code in dozens of languages for several operating systems, to architecting multi-cloud gitops platforms.  While I had no doubt I would be able to wade through the needlessly complex and yet incomplete documentation and figure it out, I just didn't want to.  Video games shouldn't be that much work IMO.  Coming in cold and trying to figure out what hardware I needed for MiSTer was a chore.  No one wanted to commit to an opinionated recommendation and say "Go buy these three things and snap them together like so."  

MiSTer is a hobby project for most of the people involved and volunteer organizations can't be expected to provide professional-level documentation and guidance.  While it was no one's fault, the lack of paint-by-numbers level documentation reminded me of the tedium of setting up and trying to get software emulators running in the early days.

When it comes to arcade games, MiSTer has considerably less compatibility than software emulation platforms like MAME.  By comparison, it only supports a handful of games.  More are being added all the time, though so I was content to keep checking back until the community supported a must-have arcade game.

I told myself and anyone who would listen that as soon as MiSTer supported the Teenage Mutant Ninja Turtles or Simpsons arcade games I would get one regardless of the other impediments.  What actually broke me was Street Fighter II. (As of this writing TMNT and Simpsons are still not available for MiSTer).

To shortcut most of the ambiguity in the documentation and from the community, I went to misteraddons.com and just ordered a complete kit.  It was more expensive than building the silly thing myself, but it was more than worth it not to have to fuss with anything.  I figured if I had problems, I could ask the guy who runs misteraddons for help.  Turned out I didn't really need to ask him anything.

Thanks to the work of a thriving community of enthusiasts, managing the MiSTer has been streamlined to the point that you don't even really have to think about it.  Setup really involves two things - imaging an SD card with a sort of bootstrap image, then copying in the "update_all.sh" script. 

The interface is standardized so that every "core" works similarly to every other core - there's a menu with both specific and common settings.  It's easy to configure inputs, and screen overlays (like scanlines etc...), and for the most part things just work.  Not only do they just work, but the result is superb.  Gameplay matches the original hardware so well, it's easy to forget the hardware altogether and just play the game.

Once you get past the spartan design aesthetic, the menus are very well thought out, simple and functional.  As it turns out the menu system is light-years ahead of older, flashier, more mature platforms like Emulationstation and RetroPie. 

FPGA vs Software Emulation

The MiSTer, and other FPGA platforms (by which I'm mostly talking about Analogue) work so well, in fact, that new playground-style battle lines have formed over which is better - FPGA or software emulation.  It manifests itself in amusing ways such as the endless semantics tug-of-war over whether FPGA is technically "emulation", or whether you have to have a perfect re-creation in order to have fun with a video game.  The answers are as irrelevant as the questions - whether FPGA cores are "emulaton" or not, whether they're "cycle accurate" or not, the results are clear for anyone who has experienced both. The FPGA method is superior if your goal is to re-create the original experience.  While there are some novel capabilities that you can only get with software emulation right now - such as widescreen hacks for NES/SNES, or "HD Mode7", the main, and only real advantage of software emulation is that it's cheap.  You probably already own some piece of hardware that can do some of it reasonably well.

If you've ever witnessed one of these debates over FPGA vs. software emulation you might have come away thinking that a level-headed person without an agenda acknowledges software emulation and FPGA cores are reasonably equivalent.  Almost all of that sentiment is coming from a motivation to make sure no one feels badly about what they have or use.  If I can be indulged a car analogy: everyone knows a Corvette is faster and more fun than a Malibu, but not everyone can afford a Corvette and not everyone who can afford a Corvette wants to invest that much money into a car.  The FPGA is a Corvette and software emulation is a grocery-getter.  I don't want anyone to feel bad, but I'm not going to pretend that isn't true to save their feelings either.  If you set aside theory and potential, FPGA offers the superior experience right now, today, and for the foreseeable future.  It's dishonest to pretend like the two things are evenly matched.  

Let me rewind a little to explain why I brought this up. I've been using MiSTer for a couple years now and I'm impressed.  I still prefer and use my original hardware for consoles, but for arcade games it's fantastic.  The problem is that the process of getting new games on MiSTer is a tedious and time-consuming one and there are only a handful of people in the world with the skill and motivation to get it done.  To wit, some of the games I most wanted MiSTer for are still not available to play on it yet.  By contrast all of them are playable in some form with software emulation.  The endless debates about FPGA vs software emulation painted the latter as a mature and robust format where the problems of display lag and incomplete implementation were things of the past.  Software emulation is "just as good", they claimed.  I was so taken in by this that I decided that I would break down and try out one of the more popular options for software emulation nowadays - RetroPie - in order to get access to the arcade games that aren't yet available for MiSTer.

RetroPie

In case it's not clear, RetroPie is the name of a software stack that aims to turn a Raspberry Pi computer into an easy-to-use emulation machine.  Thanks to the supply chain damage that occurred over the last two years due to the world's governments attempting to assert dominance over a virus, Raspberry Pi computers have become hard to buy from legitimate sellers.  Thankfully many of the companies selling them have taken measures to stymie the bots and scalpers (who seek to snatch up available inventory before legitimate customers can get to it and sell it at inflated prices).  After a month or two of poking around and using tools like rpilocator.com I was able to snag a 4GB Raspberry Pi 4.  According the the sages of the Internet, that's way more than necessary for RetroPie.

So, as I mentioned, RetroPie is a software stack.  It's little more than a manager for EmulationStation, which is, itself, a software stack that functions as a manager for RetroArch, which is itself a software stack that functions as a manger for several different emulators.  Simple, right?  The idea behind RetroPie is to present a slick interface that hides all (or most) of the technical bits and presents a uniform, single-pane-of-glass kind of interface so that the player doesn't really have to know what emulator is being used or how to configure it.

The most common way to use RetroPie is to load a pre-installed image onto an SD card so that all you should need to do is fire it up, drop in some ROMs and you're off to the races.

The actual experience is less than seamless.

Going with a pre-installed RetroPie image takes a lot of the guesswork out of the process but it's not without its problems.  First and foremost, your Raspberry Pi becomes a one-trick-pony. It won't really be able to run much aside from the pre-supplied software.  I'll explain later why you might want it to do more despite this being just a games machine.  

For now, I want to discuss the biggest problem with the pre-installed image - it uses the Linux EXT4 format for the storage space where games are kept.  This doesn't bother me much directly because I use Fedora as my day-to-day operating system so I can just pop the SD card into my laptop and copy games to it.  If you use Windows, you have to resort to other methods, like setting up an SSH service and using something like FileZilla, using a separate USB drive as a go-between to copy games to the Pi, or downloading directly from a web server, or file share exported from another computer on your network.  They could have saved a ton of trouble if they had just used a FAT32 partition to house the games (the way it's done on MiSTer).  It's not too difficult to do it yourself if you know your way around Linux, but that sort of defeats the purpose of the pre-baked image.

There are a couple of alternatives to using the pre-baked RetroPie image.  You can either install TwisterOS which is another pre-baked image which includes but is not limited to RetroPie, or you can attempt to install RetroPie yourself as an "App".

Despite the fact that the Raspberry Pi 4 has a pretty prolific architecture, RetroPie cannot be installed as binaries and needs to be built from source.  I can't really fathom why - if it's available as a pre-baked image one would think there wouldn't be any issues with redistribution of those binaries individually, but that's just not the way this community wants it.  

When you pull down the RetroPie repro from Github and run the installer script, it fetches sources for EmulationStation, which fetches sources for RetroArch and then begins building all of them.  This all sounds good until you discover that the sources have not been updated to work with the newest release of Debian, and have not been updated to compile on 64-bit operating systems.  "Bullseye" was released late last year and despite being over 6 months old, RetroPie still cannot be cleanly built for it.  

After fighting with source code and deprecated dependencies off and on for about two weeks, I finally convinced RetroPie to compile on 64-bit Bullseye.  Why did I want to do this?  My main reason was to be able to play Killer Instinct.  The various arcade emulators supplied with RetroArch/Emulationstation/RetroPie cannot run Killer Instinct correctly.  In fact the only way I was able to find to run Killer Instinct reasonably well on a Raspberry Pie is to use a special fork of MAME designed specifically to run Killer Instinct - however the emulator was written for Windows, so in order to run it on a Raspberry Pie it's necessary to run the KI emulator (u64emu.exe) on a Windows emulator (wine).  It works surprisingly well for the number of layers of abstraction which are required, however it will not run at full speed on 32-bit PiOS (Debian).  It WILL run at full speed on 64-bit PiOS. 

At the end of the two week rabbit-hole of trying to get this to work the way I wanted it to, I had RetroPie compiled on 64-bit Bullseye and I jumped through a ton of scripting hoops to get Emulation Station to launch and run the KI emulator and set up input mapping.  This was much easier said than done because Emulation Station wanted to start using it's own X display (I assume to avoid fighting for resources or resolution conflicts?)  I made it do what I wanted it to do.  But Killer Instinct was still very unstable.  It would start normally about half the time.  It would sometimes run for hours without issues.  Other times it would crash after 5 minutes.  As for RetroPie, though it had compiled and installed not even the most basic of games would seem to run normally or at full speed.  It was a mess.

Eventually I gave up trying to have things my way and fell back onto the pre-baked SD card image with the 32-bit version of the previous Debian release and ran RetroPie from that. That had to be my best chance of a "curated" experience like I was used to with the MiSTer.  At least all of that had been tested an designed to "just work".

The pre-baked RetroPie image worked better than my self-compiled version - many more games would load and work somewhat normally, however the experience was far from what I was led to believe it would be.

At the bottom of all of those layers of abstraction (RetroPie->Emulationstation->Retro Arch) are numerous emulators - which are directly analogous to MiSTer's cores.  Unlike MiSTer, however for many platforms there are numerous emulators one needs to choose between.  For example, RetroPie ships with something like six different versions of MAME - each expecting a different type of ROM set.  There's no succinct, coherent guide to understanding why you would want to use one vs. another beyond saying that if a game doesn't work right in one, try it on another.  

In the 25 years since I started using software emulators how are we still here?

But at least instead of having to piecemeal my own frontend together with scripts, most of that work would be done for me, right?   The promise of platforms like RetroPie/Emulationstation is that you get a slick interface with artwork and a synopsis of each game before you play it, and that a lot of the "under the hood" stuff would just be taken care of for you.

The reality of my experience didn't really deliver on that promise.  I researched the ROM sets I would need for MAME, NES, Genesis, SNES, and PC Engine and loaded them up, then tried to use Emulationstation's "download cover art" feature.  After spending hours downloading thousands of images and renaming the ROMs so that I couldn't tell the difference between "The Simpsons" and "The Simpsons 2-player", it just stopped with some cryptic error message.  Same thing happened with NES.  After a while I decided to table that and just play some games.

The in-game menus to configure button mapping to my gamepad would work on things like Play Choice 10 or Nintendo Vs. System ROMs but I couldn't get them to open at all for NES.  Where the menus did open you needed a secret decoder ring to understand what any of the mappings meant or how to set them.

With some games, hitting Esc or F4 would allow me to exit, for others I had to resort to power-cycling the Raspberry Pi because there was no apparent way to break out of the emulation once it started.  

When I did find that sweet spot of getting a game to actually run AND being able to map the buttons to something that made sense on my control pad or joystick, there was no evident way to adjust the video settings to adjust aspect ratios or apply filters.  There were settings that appeared to be for this but most of them either had no effect or resulted in the game refusing to boot at all.

Every layer of abstraction had its own set of configurations so I spent a lot of time digging into the Emulationstation and Retro Arch configs trying to figure out how to do some of this stuff but largely came up empty.

The experience was so bad I started to suspect I might have some kind of hardware problem so I tried multiple SD cards, and even swapped out the RPI4 itself just to rule out some hardware fault.  

There's clearly a lot of passion that went into RetroPie, and it's so much easier than it could have been.  When I went the route of trying to set up Emulationstation and RetroArch on Windows it was immediately apparent that the RetroPie community has infused their particular flavor with a ton of value.  Emulationstation comes with basically zero configuration and expects you to create that configuration basically from scratch by creating XML text files that define the menus, file locations etc...  All of that is pre-configured on RetroPie, as are many basic hardware settings.

Conclusion

At the end of the day, for all of the pontification that software emulation was a perfectly respectable alternative to real hardware or FPGA-based gaming,  RetroPie was not providing anywhere near the quality that I was getting from the MiSTer.  And that goes for playability, presentation, and ease of use.  From the instability, to the lag, to the lack of standard or intuitive configurations for basic things like input mapping or scaling, software emulation just provides an inferior experience.

It's not my goal to make anyone feel bad here, but it's also not my goal to make anyone feel good at the expense of the truth. If RetroPie is working just fine for you, that's great and I sincerely wish you the best. It is definitely not living up to the hype for me.  The MiSTer is a clear winner here in every way.  MiSTer's only weak points are a high cost of entry and low game compatibility.  Personally I would rather not play a game at all than play it in a manner so diminished that it ruins my experience and impression of the game itself.