Emulation on Mac

Emulating classic video game consoles on Mac OS X

Tag Archives: emulation

PS1 Emulation: Mednafen vs. PCSX-Reloaded 1.9.93

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]

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


Revisiting multi-console emulation with OpenEmu, getting PS1 emulation to work

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:

  • Game Boy Advance
  • Game Boy Color
  • NeoGeo Pocket Color
  • Nintendo (NES)/Famicom
  • Nintendo DS
  • Sega 32X
  • Sega Game Gear
  • Sega Genesis/Mega Drive
  • Sega Master System
  • Super Nintendo (SNES)
  • TurboGrafx-16/PC Engine
  • Virtual Boy

The experimental build version adds support for:

  • Atari 2600
  • Atari 5200
  • Atari 7800
  • Atari Lynx
  • ColecoVision
  • Commodore 64
  • Famicom Disk System
  • MAME
  • Nintendo 64
  • PC-FX
  • PlayStation
  • PSP
  • Sega CD
  • Sega Saturn
  • SG-1000
  • TurboGrafx-CD/PC Engine CD
  • Vectrex
  • WonderSwan

I tested out PlayStation support, and ran into a few obstacles before getting things to work.

  1. The UI does nothing to explain how to provide the PlayStation BIOS file. Searching around, I learned that you add the BIOS file(s) by dragging and dropping the *.bin files (BIOS ROM images) like you would a game ROM. But, after I found a set of BIOS ROM images online, adding them this way still didn’t work. It turns out the filenames were also important, and that I had to rename the files I had to be the expected filenames:
    scph5500.bin (JP) (sha1 sum: b05def971d8ec59f346f2d9ac21fb742e3eb6917) …matched what I had in the download pack I found.
    scph5501.bin (NA) (sha1 sum: 0555c6fae8906f3f09baf5988f00e55f88e9f30b) … for me, this file was SCPH7003.BIN, and had to be renamed.
    scph5502.bin (EU) (sha1 sum: f6bc2d1f5eb6593de7d089c425ac681d6fffd3f0) … for me, this file was SCPH5552.bin, and had to be renamed.
    After renaming these BIOS images, it was possible to drag them into OpenEmu and have them be recognized as PS1 BIOS ROM image files. The UI doesn’t make it clear that it has done anything with the files, but the lack of warning is your indicator that they have been accepted.
  2. OpenEmu’s “emulator core” for PS1 emulation is Mednafen, and this emulator requires all games be provided in cuesheet format. I had only ISO images, so I had to re-rip a game in cuesheet format in order to successfully add it to my OpenEmu game library.

Building Fceux from Source on Mac OS X Yosemite (10.10)

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.

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.