Emulation on Mac

Emulating classic video game consoles on Mac OS X

Tag Archives: OS X

NES, Game Boy, SNES, Game Boy Advance, DS, Virtual Boy, Lynx, NeoGeo Pocket, TurboGrafx, Master System, Game Gear, and Genesis Emulation on Mac

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.


Saturn Emulation on Mac OS X

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.


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/Saved Application State/org.yabause.yabause.cocoa.savedState

PlayStation 1 Emulation on Mac OS X

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.

PSP emulation using PPSSPP on Mac OS X 10.10.1 (with MacPorts instead of HomeBrew)

This fantastic open-source emulator of PSP runs on basically everything, but it’s a little harder to get working on Mac OS X. At least the main site now hosts compiled binaries for OS X, which is an improvement from not too long ago when the only binaries available were on a third party build site. We no longer have to run the Windows version under a Wine wrapper. Things have come a long way.

But you still have to download and install a dependency first: the SDL runtime (Simple DirectMedia Layer), because the developer follows the Linux philosophy of no statically linked libraries (“make it the user’s problem to try to recreate the exact dynamic library setup that the developer used through trial-and-error!”).

There are directions for installing SDL if you use Homebrew as your package manager. I don’t, though. I use MacPorts. The two are mutually exclusive, and would interfere with each other if you were to try using them together. So this post is about how to get PPSSPP working if you are a MacPorts user.

First, I assume you’ve gotten XCode from the App Store, opened it to download the XCode command line tools, and then installed MacPorts. If you run the following commands, you can correctly set up the LibSDL dependency.

sudo port install libsdl
sudo ln /opt/local/lib/libSDL-1.2.0.dylib /usr/local/lib/libSDL-1.2.0.dylib
sudo ln /opt/local/lib/libSDL.a /usr/local/lib/libSDL.a
sudo ln /opt/local/lib/libSDL.dylib /usr/local/lib/libSDL.dylib
sudo ln /opt/local/lib/libSDLmain.a /usr/local/lib/libSDLmain.a

Do you get an OS X CrashWrangler bug report dialog, saying it crashed because it couldn’t find “/usr/local/lib/libSDL-1.2.0.dylib”? You might have not created the aliases correctly in /usr/local/lib. Do you get a “Segmentation fault: 11” with a thread that crashes in the pthread library, while the main thread is trying to call SDL_SetVideoMode() from its own SDL_Main()? Then you probably aliased libSDL-1.2.0.dylib correctly, but messed up the others. I did that once. Woops.

Why is PPSSPP not statically linked to its dependencies? Why does it not save user data in the right place (it will save your games in a hidden folder, very non-Mac like: you’ll have to open up “/Users/your_name/.config/PPSSPP/” to find your save files, the ini files where you enter per-game cheats, etc.)?

Building from source:

If you would rather build PPSSPP from source yourself, try these steps (using MacPorts):

sudo port install cmake    # because the build process needs cmake
git clone https://github.com/hrydgard/ppsspp.git ppsspp_dev
cd ppsspp_dev
git submodule update –init   # their wiki instructed to do this (?)
git submodule update             # seemed to do nothing (?)
mkdir build-osx-fat
cd build-osx-fat
cmake /path/to/ppsspp_dev

If you did want to put MacPorts aside and try HomeBrew just for a minute, and only to install SDL:

sudo rm /usr/local/lib/libSDL*  # delete the hard links to the MacPort version of SDL
ruby -e “$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)”   #ugh, it chowns /usr/local to non-root! stupid!
brew doctor   # sure enough, it warns me that I will have a ton of problems because I use MacPorts
sudo mv /opt/local ~/Desktop/macports     # move all my MacPorts-installed packages somewhere safe, temporarily
export PATH=/usr/local/sbin:$PATH          # temporarily add this to the PATH because HomeBrew wanted me to.
brew install sdl

And then to get rid of HomeBrew again and go back to using MacPorts, you would do this:

brew remove sdl
cd `brew –prefix`    # puts me in /usr/local
rm -rf Cellar
brew prune
rm `git ls-files`
rm -r Library/Homebrew Library/Aliases Library/Formula Library/Contributions
rm -rf .git
sudo mv ~/Desktop/macports /opt/local   # restore MacPorts
sudo chown -R root:wheel /usr/local     # undo the security damage to the permissions that HomeBrew’s installer did.

Preserving CD and DVD-based Console Games (Pt. 2)

In the last post, I mentioned the use of a disk imaging command called dd. One of the shortcomings of dd is that it doesn’t provide any kind of progress information while it is working, and doesn’t integrity check the resulting output. Sometimes it has an error during the imaging process and just stops prematurely without an explanation. After going through 100 or so Playstation 1 games and trying to backup all of them using dd, I started looking for a better way.

One alternative I found was an improved version of dd called dcfldd, a tool by Nick Harbour when he worked at the Department of Defense’s Computer Forensic Laboratory (DCFL). To use it, you need to download the source and compile (no binary love for Mac OS X users). The steps are the same standard ones for GNU open source projects: extract the source code archive (should be just a double click in Finder after it downloads); open Terminal; cd to the directory of the source code; ./configure; make; sudo make install. Then you should be able to run dcfldd using the same parameters as with dd, except now you will get to see the progress. It also may have just been a coincidence, but dcfldd ripped my copy of MDK whereas dd was not getting the job done (it kept erroring out).

Preserving CD and DVD-based Console Games

In order to preserve a copy of a game that you own, you must make an “image” of the full CD. Many Playstation game discs (especially earlier games) have a data track and one or more audio tracks such as the kind that play in a standard CD player. This makes them a little trickier than straight data discs which are fairly simple to image using the GUI application Disk Utility.

You may be familiar with the term “ISO”, a kind of disk image that is often used for software distribution. However, you cannot make an ISO out of a multi-session disc or a disc with audio tracks; the format doesn’t allow for it. At best, you will lose the audio tracks; at worst, you have an image that doesn’t contain all of the game code. We need a byte-for-byte copy of the original disc with all of its tracks. There is no one file extension associated with a disc image like this, as far as I can tell. I just call it an image file and the file extension is arbitrary, but some emulators want the “.iso” extension, and you might have to rename it to that. Various commercial ripping tools have their own file extensions, and maybe even their own image formats. I don’t see a point in using any of these proprietary formats or tools.

Most directions on how to image Playstation game discs start with “download this shitty Windows software…” or “launch your $70 copy of some professional-grade Mac OS X disc authoring software.” I wanted to accomplish this task without using any shady crapware or expensive commercial software. That left me with the command line tools for direct CD/DVD access.

The command-line tools I am aware of for doing direct-access imaging of storage devices on a Mac are hdiutil, dd, and cdrdao. The latter is not part of the default OS X tool set, but you can install it with Mac Ports (or build it yourself from source, but it’s easier to use Mac Ports). I was able to create a playable disc image using hdiutil, but only when the disc had only data. When it had both data and audio tracks, hdiutil would fail during the copy with an unhelpful “input/output error” message. The dd utility, however, seems to work just fine. So does cdrdao, but since dd comes with OS X, we’ll just use that.

Step 1: insert the game disc. It will show up on your desktop as one volume if it’s just a data track, or two volumes if it also has data. Annoyingly, iTunes will jump up and ask to import the audio tracks. I don’t know if there’s anything you can do about that, except say “don’t ask me again.” It will still pop to the front every time the disc is inserted, though.

Step 2: because we need exclusive access to the CD/DVD drive, we have to take access away from Finder by unmounting the volume(s) on the CD/DVD device. To do so, first we need to know the UNIX filename of the CD/DVD drive device. The command “drutil status” will show us a name in the form of “/dev/disk2” (yours may be different). We take that name and use it in the command “diskutil unmountdisk disk2”, which unmounts all volumes associated with this device.

Step 3: ripping the game disc. The command we want to use is “dd if=/dev/disk2 of=~/Desktop/Title\ Of\ Game.iso bs=2048”. I don’t know if the last parameter, which is specifying a block size of 2KB, is necessary or not. But one source I read claimed that it is necessary to prevent Mac OS X from changing the block size of the data on a CD from 2KB to 4KB, which is the default behavior.

To recap:

drutil status
diskutil unmount disk4
dd if=/dev/disk4 of=~/Desktop/Title\ Of\ Game.iso bs=2048

That’s it. It takes dd about six minutes or so to rip the game, and then you should have a single file containing all of the tracks of the original disc. PS1 emulators can load this file to play the game directly from your hard disk.

I’ve tested, and everything I’ve said above also applies to PlayStation 2 and Sega Saturn discs.