Emulation on Mac

Emulating classic video game consoles on Mac OS X

Monthly Archives: January 2015

Windows-era PC games on Mac OS X using Winery 1.7

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.

  1. WineBottler, which is the easier option to use and has a nicer looking UI, but doesn’t support using different versions of Wine per application, which you might find helpful for older games that can run on Windows 95 but crash on XP.
  2. Wineskin Winery. Sometimes referred to as just “Wineskin” or just “Winery.” The UI is very unfriendly, but does offer a little more configurability than WineBottler, and doesn’t have any donation-begging, nor do you have to suffer through ads in order to download it like you do with WineBottler.

Here we’ll go through an example with Wineskin Winery.

  1. When you launch Winery, you pretty much just have an empty window with the option to download and install an “engine,” which is the underlying version of Wine that will be used to create a compatibility “wrapper” for a particular game. Clicking the ‘+’ button, the choices (as of the time of this writing) include one called WS9Wine1.7.30. But what you want to do is ‘Download and Install’ one of these engines, probably the newest one.
  2. This should return you to the main menu, whereupon you have to click ‘Update’ under ‘Wrapper Version’ if it still says ‘No Wrapper Installed.’ Winery confuses the user by referring to the wrapper-generator component as the “Wrapper” – no, the wrapper is what you as the user are expected to create. Anyway, hit that update button.
  3. Now, finally, the ‘Create New Blank Wrapper’ button should be activated.
  4. Obtain a copy of a Windows game. I’ll use a silly imported Japanese game (for Windows 95; released 1996) as our example here. I have a folder of files for the game that includes an EXE and some other stuff.
  5. In Winery, click “Create New Blank Wrapper” and give it a name, which will create a Mac OS X app bundle by the same name (e.g., “MyCoolSoftware.app”) at the end. During creation of the wrapper/app bundle, you might be asked to install Mono for .NET games or Gecko for games with browser components. For some games these might be unnecessary, but the fastest way to know is trial & error. Even without the additional components, the resulting empty wrapper is a whopping 166MB.
  6. If you double-click on ~/Applications/Wineskin/MyCoolSoftware.app, you might expect the application to launch. Nope! Mac OS X complains that it cannot be run. And yet if you attempt to run it a second time, it works and you will now be presented with wrapper options. This seems like a bug, but that’s how it goes.
  7. In the panel that appears, you must click ‘Install Software,’ even if the game is self-contained and doesn’t need an installer step. In our case, because we suspect the EXE we have is the game itself rather than the installer, we choose ‘Copy Folder Inside’ to make a copy of the game within MyCoolSoftware.app. Taking a guess, we select GAMENAME.EXE in its top folder, as the executable that will start our program.
  8. Now you can double-click the MyCoolSoftware.app in Finder, to launch your game.

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.


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.