Emulating classic video game consoles on Mac OS X
Clearly I have not been updating this blog, but one of the reasons for that is that emulation has become much more user-friendly in the past few years. You no longer have to “get your hands dirty” to emulate a ton of game consoles on MacOS. Thanks to OpenEmu (covered here previously), emulation of about 30 consoles “just works.” We also now have RetroArch, a competing multi-system emulator that works on far more than just MacOS.
OpenEmu’s strength is its MacOS-native interface. It’s a mouse-driven UI designed to focus on your ROM collection, organized by system. When you run OpenEmu, all of the systems you see in the list are supported “out of the box.”
In the past, adding CD-based games to your “library” in OpenEmu was hit-or-miss. Now, if you have a game that is a .bin/.cue file pair, you just add them as a pair, and they show up correctly without any trouble. As many Playstation 1 era games are turning 20 years old now and Sony has abandoned any concept of backwards compatibility, it’s great to have an easy way to manage an archive of our collections. When you add a game to your library, the box art thumbnail just shows up automatically, no further action required on the user’s behalf.
OpenEmu does not apparently support emulator tweaking (no super-hi-res PS1 emulation or widescreen hacks), nor does it support netplay, or streaming. It’s a single player (and local multiplayer) multi-system emulator front-end. (Technically we have to call it a front-end, because it’s just providing a unified interface to a collection of already-existing emulators).
RetroArch is the relative newcomer on the scene. Their goal is to run basically any emulator on any machine, using an underlying middleware API they call LibRetro. RetroArch is the application for the user, and individual emulators can be adapted or abstracted away by the LibRetro interface, turning them into “cores.” This is much the same way that OpenEmu works, but RetroArch is portable: it works not only on MacOS, but on Windows and Linux and even smartphones and jailbroken game consoles. You can run RetroArch on your jailbroken PS Vita, Wii, or even a $35 Raspberry Pi. It also allows for far more configurability than OpenEmu, for better or worse. Compared to OpenEmu, RetroArch supports many more emulator cores. Close to 100, although many of those are variations (several choices of GBA emulator, several choices of PS1 emulator, etc.)
The RetroArch default interface is an homage to the Sony PS3 and PSP’s “cross-media bar” (also known as the XMB) design. If it works don’t fix it, I guess. The reason this UI makes sense for RetroArch is that it can be entirely game-controller-driven. Controller support is automatic: plug and play. I didn’t need to spend any time at all in RetroArch configuring my PS3 controller, I just plugged it in and that was it. Painless. Well, I did have to hit the PS home button.
The rest of the UI is not so painless though. I experienced multiple bugs running it on MacOS: using the window frame controls to go full-screen corrupted the picture and I had to use the in-app setting to change it to full screen, instead. I had major problems and inconsistent results launching Playstation 1 games. Loading a game before you load its corresponding core may or may not succeed. You may get stuck in a menu tree where you can’t go back without closing RetroArch. If you ask it to download something in the background, it will get to 99% and then halt all emulation for a few seconds before reaching 100%. It’s a lot of little annoying things.
If you double click anywhere on the interface, such as by accident, it just instantly quits RetroArch. If you accidentally hit the ESC key, it instantly closes RetroArch. If you run RetroArch, you basically don’t want to use it without a controller.
If you want box art thumbnails, you must direct RetroArch to download an entire set for a given system, regardless of how many of those games you actually own. Likewise, RetroArch doesn’t have any emulation cores when you first run it. You have to flip through its menus and download each individual one that you are interested in. Unlike with OpenEmu, it’s unclear if there is any kind of automatic updating for these cores or if that’s a manual step also.
All of these sharp edges aside, RetroArch is an amazing project. It promises to do for everyone, what OpenEmu did for MacOS users. It also has some unique advantages, including: netplay (including spectating), achievements (via RetroAchievements.org), recording and streaming.
Either OpenEmu will expand its feature set to compete with RetroArch, or RetroArch will improve the usability of its UI. Either way, the future of emulation is looking bright.
Over the weekend, I compared the latest Mednafen PlayStation emulation with the latest PCSXR, and Mednafen emulation is currently ahead. It may not yet have all the upscaling functionality of the Windows PCSXR, but for Mac OS X it seems to be the best available PS1 experience. Where PCSXR occasionally had missing audio, skipping during loading screens, and long loading pauses at a black screen for unexplained reasons, Mednafen delivered the genuine experience. Luckily, it can be easily found in the experimental build of OpenEmu.
Before realizing the OpenEmu “experimental build” incorporates a working copy of Mednafen, I worked through all the steps to build and run Mednafen source code at the command line. If you still want to experiment with the latest versions of Mednafen yourself and not wait for the OpenEmu team, keep reading.
Building Mednafen from source:
Using Mac OS X 10.10.4 and MacPorts, I was able to build Mednafen pretty easily using the following steps:
sudo port install libsndfile
[after having extracted the Mednafen source archive and changed into the extracted directory]
./configure
make
Providing PS1 BIOS images to Mednafen:
Copy the appropriate PS1 BIOS file(s) to ~/.mednafen/firmware/ . For more on my difficulty with finding the correct files for this, see my previous post.
PS1 ROMs, Cuesheet, and Copy Protection Files required by Mednafen:
Unlike other PS1 emulators, Mednafen requires the cuesheet format for its ROMs. See my previous post on the cuesheet format and how to re-rip a game in that format or add a CUE file to an existing raw disc image.
Apparently, Mednafen also wants an .SBI file, even for games that should not need one. If a game does need an SBI file (because it was published as a LibCrypted disc), the SBI file can be downloaded from PSXDB Redump (link “SBI subchannels” on protected disc page). http://redump.org/disc/28260/ With the game I was testing, an SBI file should not have been required, so I tried renaming an SBI file for some other game just to shut it up, and this seems to have worked.
Running PS1 ROMs with Mednafen:
./mednafen/src/mednafen image.cue
In my last post about OpenEmu I mentioned the “experimental” build that adds support for many more systems than the official release of the program. Over the weekend I tried out the experimental version’s Playstation 1 emulation. Wow, it’s actually better than PCSX-Reloaded!
The official release version of OpenEmu supports:
The experimental build version adds support for:
I tested out PlayStation support, and ran into a few obstacles before getting things to work.
This post is part of a series:
Preserving CD and DVD-based Console Games
Preserving CD and DVD-based Console Games (Pt. 2)
In a previous post, I mentioned that two command-line utilities for making optical disc images on Mac OS X were dd and cdrdao, but I recommended dd because it was simpler to use. Well there’s actually a case where cdrdao is needed, and that is when your emulator wants game images in the “cuesheet” format (a pair of files with the file extensions .bin and .cue, rather than a single .iso or image file).
Why do we need the cuesheet format?
I mentioned in my first post in this series that many old games use “mixed-mode discs” (audio and data as separate tracks). You can rip all of their data, but without metadata to indicate the track boundaries, it seems that multi-track disc images can’t be properly handled (?). Most 16-bit era CD games were this kind of disc, and sometimes it was used in the early games of the PS1/Saturn generation.
I realized the need for cuesheet format when I tried to use the Mednafen emulator to play a Playstation 1 game I backed up in ISO format. It would fail with weird errors unless I provided the game in cuesheet format.
Almost any cuesheet file can be found at Redump.org. In fact, you can just download every cuesheet for a given system all at once, which is nice. Maybe it will preclude you from having to create your own, if you ripped your games as ISO. Note that your binary image file has to be named consistently with what is in each CUE file.
Installing cdrdao
First, you need to install the “cdrdao” package from either MacPorts (recommended), Fink, or from source. If you have MacPorts, the command is as follows:
$ sudo port install cdrdao
Backing up a PS1 disc in cuesheet format, using cdrdao
Find and unmount the disc filesystem. Observe which drive is the disc drive with the first command, and use that path in the second command:
$ diskutil list $ diskutil unmountDisk /dev/disk3
Then rip the disc and convert its TOC to a CUE with these two commands:
$ cdrdao read-cd --datafile image.bin --driver generic-mmc:0x20000 --read-raw image.toc $ toc2cue image.toc image.cue
Most games from the Windows-era of PC gaming (as in, pre-modern/pre-Steam-era, or roughly 1995-2005) can be run on Intel Macs (Macs made after ~2006) thanks to a compatibility layer called Wine. Years ago it was called “Windows Emulator,” but later it became Wine Is Not An Emulator. And it’s not – it doesn’t translate instructions, it just translates functions (“system calls”) from Windows to POSIX, which they call a “wrapper” (wraps the Windows software to intercept its Windows API calls). Even though it’s technically not an emulator, it fits the theme of this blog. Here’s a walkthrough.
Wine itself is a command-line program, installable via MacPorts. But you wouldn’t want to run it that way. So there are a couple of different choices for GUI front-ends.
Here we’ll go through an example with Wineskin Winery.
Starting up our game, we see a title screen and a couple notes of music! Then, it crashes. A Windows dialog pop up for “encountered a serious error” appears, and we are forced out of the program. All we can tell from this is that the failure happened when the program tried to read an address that it couldn’t.
If this happens, one possible solution is to go to the Wine HQ application compatibility database and search for the game, or for the publisher, or the original Japanese title, or even the original developer. In my case, nothing returned any results.
It turned out that in my case, it was a bug in the game itself – an incompatibility with Windows XP. It supposedly worked in Windows 95, but not in later versions of Windows. While you can configure Wine to report the OS version as Windows 95, that was no help in this case. Neither was switching to a much older Wine engine. Luckily, there was a patched version of the EXE for the game with XP support, so I changed the wrapper to point to the fixed EXE, and I was good to go. Because Wine “emulates” Windows XP, in rare cases like this you’ll have to first find a way to make the game XP-compatible.
Fceux is a cross-platform, open-source NES emulator. There are other options for NES emulation on Mac OS X, but FCEUX offers tools for debugging, rom-hacking, map making, Tool-assisted movies, and Lua scripting. Basically it’s the “hacker’s choice” of NES emulator. Unfortunately, some of those hacking features are exclusive to the Windows version currently (boooo), so maybe the project needs some help from Mac users. Or, you might just want to have a version of Fceux that is not 18 months out of date, because the project hasn’t released a binary since 2013 despite the fact that bugs continue to get fixed. Let’s show how to build their source code on Mac OS X.
First, we need to install all of the dependencies. I assume you already have XCode installed with the command-line tools, and that you’re using MacPorts to install open-source packages. Note the versions of things here. At the time of this writing, you don’t want the latest Lua; Fceux will fail to build. April 2016 edit: I added pkg-config to this list of dependencies.
$ sudo port install scons $ sudo port install libsdl2 $ sudo port install gtk2 $ sudo port install lua51 $ sudo port install pkg-config
Next, get the latest code from their repository:
$ svn checkout svn://svn.code.sf.net/p/fceultra/code/fceu/trunk fceultra-code $ cd fceultra-code
Now, a small change to their Sconstruct file is necessary, to fix an issue with how they’re setting up the build environment. On the line immediately after the “env” variable is set, add the following:
env.Append(ENV = {'PATH' : os.environ['PATH']})
Finally, we can build and run the emulator, but we have to add some more paths to the command line in order for the build process to find all the stuff we installed with MacPorts. If you prefer Brew as your package manager, your paths here will be different (CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib scons)
$ CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib scons $ ./src/fceux
Optionally, we can build and run the server component, for network play.
$ cd fceux-server/ $ make all $ ./fceux-net-server
Network play allows two (or more?) instances of Fceux to share game-state by continuously syncing, over the network.
The lower-powered game consoles have all been well emulated by this point. Basically any living room console older than the year 2000, and all handhelds before the current generation (before 2011 or so). Thanks to the authors of those emulators, much of their work is open-source at this point too. That’s what enabled OpenEmu to come along and put a front-end on the emulation cores of a dozen or so different emulators.
OpenEmu is a ROM library management and emulator front-end application. It does for ROMs what iTunes does for other media: basically it makes your game collection the focus, and tries to make the actual emulation seamless and transparent to the user. You can even keep your ROMs in zip format; OpenEmu will handle decompression. It will also supply cover art from the original game boxes, and correctly identify the game titles and metadata. Like iTunes, though, when you import a game into your “library” it will create a copy in its own directory: ~/Library/Application Support/OpenEmu/Game Library. This is configurable, but it’s worth noting, because you might inadvertently double the storage space used by your ROM collection by adding it to the OpenEmu library.
Graphics and sound are perfect, for all of the cores I tried.
GamePad support just works. It’s very impressively done, actually. NES four-player support is possible, SNES 8-player support. Even 4-player GBA and DS support is listed, although I wonder how it is implemented.
The software is not perfect, though. There’s a crash bug that happens often when opening a ROM for the first time. Net play is not implemented, so multiplayer is strictly local for now. And it looks like the project is hesitant to add emulation cores for consoles like Wii, Gamecube, PS2, PS1, N64, and Saturn, despite the quality open-source emulation cores that exist for each of those systems. There is currently an “experimental” build that incorporates Nintendo 64, PlayStation, and arcade systems.
OpenEmu is the future of emulation and of classic game preservation.
The SEGA Saturn was long said to be impossible to emulate, because of its unusual (ridiculous) architecture that incorporated eight processors (two Hitachi SuperH SH-2 processors, one Hitachi SH-1 processor just for streaming and decompressing from the disc in realtime, two “video display processors” from SEGA, a Motorola 68EC000 for sound, another custom SEGA DSP chip for sound built by Yamaha, and finally something called the System Control Unit). Before the days of multi-core processors, parallelism meant having multiple chips. It was expensive, hard to program for, and its graphical abilities were best suited to 2D.
There were a string of Windows-only closed-source emulators, including SSF, Giri Giri, Satourne, etc. They have all been abandoned (or in the case of Giri Giri, sold to SEGA).
The Yabause emulator carries the torch now. It’s open-source. It builds on Mac OS X and even ships an OS X binary, in an app bundle too! You won’t need much help getting it to work. With a game ISO (original disc in your system, or disc image – see my earlier post on imaging your original discs), and a Sega Saturn BIOS file, you are good to go.
Almost.
The first thing to do is to open Preferences, and point it to the location of your Sega Saturn BIOS file. Also uncheck the box for “Enable BIOS emulation” unless you were unable to find a copy of this BIOS file anywhere.
Next, go to the Audio/Video tab. Audio just works, and there’s nothing to change. Graphics are another story. With the current version (0.9.13) the OpenGL graphics renderer shows no graphics at all (just a black screen with audio). Then if you go to fullscreen, it crashes the emulator. The software graphics renderer is not fast enough to be playable; with frameskip turned on, the game is playable, but you wouldn’t want to. The third option is the “Grand Central Dispatch” graphics driver, and this actually works well. Not 100% speed but close. But the real fix is downloading Yabause version 0.9.12, which had a working OpenGL mode on OS X. They appear to be aware of this bug and it might get fixed in the next version. Also, if your system is fast enough, it will actually cause issues with emulation speed unless you check the option in the menu bar: Emulation -> Enable Frameskip. The emulation speed is not perfect all the time, but this keeps it on target as much as possible.
There is no support for controllers at the moment, so you have to play with the keyboard. That may be okay for some games, but I hope that controller support comes quickly in a future version. The work-around for now is to run a tool that maps keyboard keys to a controller’s inputs. On Mac OS X, your choices are ControllerMate ($25) or Enjoy2 (free, open source). Download and run Enjoy2.app, and then get your PS3 controller to Bluetooth pair with your Mac. Now it should automatically show up in Enjoy2. If you press a button on the controller, it will jump to a place in the list with an auto-generated button name (up on the d-pad will be “Button 5 (null)” but don’t worry about that). For each key you want to assign to a controller input, just set it to “Press a key” and then in the field next to it, hit a key on the keyboard. When done configuring, hit the “Start” in Enjoy2. You can test your mapping using a text editor; you should be able to type with the PS3 controller. Now, over in Yabause, configure the emulator with keyboard keys matching the ones you set in Enjoy2. This should work great unless you need analog, which few Saturn games supported anyway (and none required, to my knowledge). Also, at some future point it would be great if mouse input could emulate the light gun, or two sticks could be used for Virtual On. But now I’m just dreaming.
In order to save games (Yabause doesn’t support the emulator concept of “save states”) you have to go to Preferences, Memory, and then under “Internal Memory”, enter a pathname to somewhere on your system where you want the Saturn’s internal battery-backed RAM to be stored. It can be anywhere and named whatever, as long as you have write permissions to that location. You can do the same thing to create a file-backed emulation of a Saturn expansion cartridge. Yabause will write the files when it quits.
Getting in and out of full screen is janky; you can get into full screen mode using the menu bar, but to get out, the usual keys like ESC don’t work. You have to hit Cmd-F to toggle out of full screen. Or Cmd-Q to quit, that also works.
Lastly, if you are looking for where Yabause stores its program preferences:
~/Library/Preferences/org.yabause.yabause.cocoa
~/Library/Saved Application State/org.yabause.yabause.cocoa.savedState
A site called Redump.org provides MD5 hashes for correct images of games from all kinds of consoles and PCs. From their site:
Redump.org is a disc preservation database and internet community dedicated to collecting precise and accurate information about every video game ever released on optical media of any system. The goal is to make blueprints of the data on console and PC game discs.
The original PlayStation can be emulated excellently on Mac OS X using the open-source emulator, PCSX-Reloaded (formerly PCSX).
The Mac OS X build is available in binary form, and mercifully it’s an app bundle too. You just double-click and go. File, load ISO, point it to a disc image, and play.
PlayStation emulation generally requires you to provide a BIOS image extracted from the console, and that’s the one thing you’ll probably have to pirate, even if you have your own physical discs. The emulator is apparently able to emulate/simulate BIOS functions, but in testing it seems like that feature is hit and miss at best. PCSXR runs best with an actual BIOS image. You have to place it in /Users/your_name/Library/Application Support/Pcsxr/Bios. Their wiki recommends SCPH7502.bin.
Also note: for what it’s worth, I had to rename my collection of disc images to .iso file extension, because PCSXR requires it.
Save states, memory card files, plugins and other supporting data get stored at /Users/your_name/Library/Application Support/Pcsxr, like a good Mac application. Maybe a little hard to find, but this is at least the standard location for application data. Not some directory that begins with a dot, in your home directory, that Finder can’t even see. And not /Library/Application Support, which is semi-hidden by Finder and access-controlled with root permissions.
You’ll want to connect a real gamepad. The PS3 controller works well, because it’s Bluetooth. Bring over a Dual Shock 3, but not one that is already turned on and paired with a PS3 in the room, because that’ll cause trouble. Turn on Bluetooth in the menu bar. The Bluetooth discovery process is janky, and you might need the mini-USB cable, but it will work, and eventually you will be able to use it 100% wirelessly. In PCSXR: open Preferences. Go to the Plugins tab. Where it says controller, select “Gamepad/Keyboard/Mouse” and click “Configure”. If the Playstation controller is connected, you should see it in the drop-down box labeled “Device”. Select it. Now in my case, none of the preset buttons were mapped to the right controller buttons, so I had to remap all of them, but it only takes a second.
Input: I expected to be able to play games originally for use with a light gun, like Point Blank, Elemental Gearbolt, Time Crisis, or PoliceNauts. They do work, but only with a controller, and not with a mouse like I hoped. Eventually, I’ll look into alternative input plugins, maybe here or here. Out of the box, it looks like PCSXR can support 2 players. There were games for PS1 that supported 4 players with the PlayStation MultiTap accessory, and there might be a plugin for this, but I haven’t searched for it.
Net play: didn’t test this yet.
Audio: there’s some skipping in the audio on my system. Increasing the cache slider for the CD reader plugin didn’t help, and there’s really nothing that looks like it would help under Audio. Turning frame skip on under graphics also didn’t help. Switching to the SDL sound driver might have helped a tiny bit, but there’s still skipping. Lammy’s audio in Um Jammer Lammy is inaudible, then it de-synchs from the gameplay and everything slows down.
Graphics: The emulated graphics enable a level of quality that an actual PlayStation could never produce. Some of the hardware limitations of the original machine meant that polygons would sometimes jiggle, and the textures would have perspective issues. It looks like PCSXR has included Mac OS X native builds of “Pete’s” OpenGL plugin, and made it the default. I’ve seen video of other graphics plugins that can be used to improve the resolution (like GDSX, although that is DirectX so would be Windows-specific), but the resolution already looks like it’s rendering at 800×600, much higher than the original console was capable of (640i at best). There’s also Pete’s “OpenGL2” plugin, which I want to look into. The image looks a little off in some way that I can’t put my finger on, like too high resolution or something. Scanlines are a nice touch but they kind of darken the image; I don’t think that’s it.
Emulation on Mac 
Recent Comments