BlastEm

BlastEm is an accurate emulator for the Sega Mega Drive, with early Sega Master System support. It is currently the emulator of choice for Genesis VGM logging.

The current Release version of BlastEm, as linked on the page above, is 0.6.2. This version lacks VGM logging and many quality-of-life features in the Nightly builds. These builds tend to be very stable, so there's no need to wait until the final release of 0.6.3.

If you've never used BlastEm before, grab the most recent nightly build. At the time of this writing, that's c76c81c21ae5, built on October 7, '23. (The BlastEm Discord has a channel which lists recent builds.)

If you've already used BlastEm, please note: nightly ab3d8759da08, released on April, 3rd '23, seems to be a cutoff for needing to update. Why? I've found some logs of EarthWorm Jim 2 made in this build sound way better than the ones I made in a prior BlastEm version. I'm not sure why, and not all games are affected, but I strongly recommend updating before making new SMD logs. If you have incomplete sets or just want to check, compare a new log in a new build to your previous ones and see if you hear a difference.

BlastEm's hotkeys are listed at the beginning of default.cfg. To begin or stop a VGM log (with default/initial key settings), press m. To take a screenshot, press p. To open the debugger, press u.

Logging Advice

Before you start recording VGMs, there are some things you should check:

• Have you already changed the save paths (that is, the places BlastEm will put your logs and screencaps)? If not, see the section about it below.
• Do you know what framerate (NTSC/60 fps or PAL/50 fps) the game should be recorded at? Check 50Hz Mega Drive Games to find out, then make sure the game plays at the right speed when loaded. If the 50hz game is running at 60 fps, then:
  • Go into "System" in the settings, then change Default Region to "E - Europe". If needed, you can hard reset by pressing F5. This works with multi-region ROMs that offically include Europe, but if they don't the game will run at 60hz. To force PAL mode:
  • Launch from the command line, using the incantation blastem -r E. You can also place this in a .bat file, or use the program Kaijuu to make it a menu-click option.
  • If the game will not play in PAL mode, you'll have to hack it or ask for help in VGMRips' IRC.
• Are you using the most recent 0.6.3 nightly? As mentioned above, logs made in nightly ab3d8759da08 and above sound better than logs from those before. You can copy your default.cfg file to the new nighly's directory to keep all your settings from before.

Avoid closing BlastEm before you stop a VGM log. The EOF Offset won't be set correctly, and for some reason vgm_ptch won't work to fix it. Nor apparently can you hand-fix this, even if you look at the VGM Specification.

Note: Some older nightlies used the master clock at the time of recording for cycle counting; this is fine at normal speed, but it fixed the log to using whatever speed the emulator's set to when logging begins. If you insist on using ancient builds, be aware of this problem... but I think you'll like the quality-of-life improvements in newer ones, including not having to worry about that.

You might be wondering about the Model (MegaDrive model) setting. The default Model settings of BlastEm shouldn't need changing except in rare, special circumstances. This would be when tracks are affected by the Model 1 slowdown bug, like in Dinosaurs for Hire and EarthWorm Jim.

The preferred model to use instead is not known yet. On Romhacking.net, you may be able to find a patch that fixes it. I have yet to see if the same fixes work cross-game.

Command Line Usage

Accurate as of 0.6.3-pre-8990c2f431b1 (date September 3; options may change in later builds):

blastem [OPTIONS] ROMFILE [WIDTH] [HEIGHT]

Options

-h	Print this help text
-r (J, U, or E)	Force region to Japan, US or Europe respectively
-m MACHINE	Force emulated machine type to MACHINE. Valid values are: sms - Sega Master System/Mark III gen - Sega Genesis/Megadrive media - Media Player
-f	Toggles fullscreen mode
-g	Disable OpenGL rendering
-s FILE	Load a GST format savestate from FILE
-o FILE	Load FILE as a lock-on cartridge
-d	Enter debugger on startup
-n	Disable Z80
-v	Display version number and exit
-l	Log 68K code addresses (useful for assemblers)
-y	Log individual YM-2612 channels to WAVE files

Making Paths for Your VGMs and Screenshots

Before recording, you will probably want to change the following path settings in default.cfg:

initial_path $HOME
screenshot_path $HOME
vgm_path $HOME

These paths use the special variable $HOME, which places your screenshots and VGMs in your User folder. This is probably not what you want.

BlastEm allows for some fairly complex custom folder structures, but you probably want something basic and easy to start. I'll show you how my paths are set up.

To store things in BlastEm's folder, change $HOME to $EXEDIR. I've made this change to all three lines above in my default.cfg. The problem is, you'll quickly end up with a mess with no further changes. We also need these two settings:

screenshot_template $ROMNAME/%Y%m%d_%H%M%S.png
vgm_template $ROMNAME/%Y%m%d_%H%M%S.vgm

These lines work off screenshot_path and vgm_path above. They've been modified from what you'll see in default.cfg. With $ROMNAME in place like so, BlastEm will put each screenshot and VGM into a subfolder matching the loaded ROM's name.

Now, the one issue with these niceties is: for now, if the full path (all folder nesting + filename) for a VGM is too long for your computer's file system, it will silently fail to record the log.

If, as above, the path settings are similar for both, you can test if this may happen by taking a screenshot: BlastEm will tell you if this failed. Another way to tell is by opening the debugger (as described below), then entering c or continue in it to make emulation proceed. When you try to record, an error will appear in the debugger window if recording failed. To fix it, you can shorten the filenames in the template settings by removing some of the % wildcards, or shorten the ROM's filename itself.

Note: If your new path settings don't seem to take, it's probably because you've opened BlastEm already and it's created a separate blastem.cfg file somewhere else. To remove it, first open BlastEm and go to Settings -> System. You should see an option named "Save config with EXE". Check this option, then close BlastEm and destroy the blastem.cfg file thar appeared in its folder. (Or, you can edit the options named in this section in blastem.cfg as well.)

You can also control where saved games and states go:

save_path $EXEDIR/$ROMNAME

Where $EXEDIR is used it's possible to use .. I realized recently, though, they aren't the same (which is why they're different); . means the folder that BlastEm was launched from! This will not match $EXEDIR if you, say, reuse a cmd window inside your VGM working folder to open BlastEm with cmd options.

Feel free to experiment with these settings and learn if you're of a mind. But if you just want quick and dirty workable settings, this should suit you, I hope.

Using the Debugger [work in-progress]

There are two ways to open BlastEm's debugger:

• Press u while a game is loaded.
• Use the d command line switch; the debugger will automatically open when a game is loaded.

When the debugger opens, control goes to its window; the main BlastEm window will pause game execution and stop responding to input until you enter c or continue in the debugger. At that point, the debugger stops responding to input. You'll have to press u again to return to it.

Although both windows "queue" any keystrokes that you perform in them while they're inactive, it's not possible to work with both windows at once. BlastEm is always either in "game mode" or "debugger mode."

Recent nightlies have streamlined debugger usage. For instance, to print the value inside a register, enter something like this:

print/x [$ff05ec ].b

/x makes the output printed come in (lowercase) hex; it's a format code. [brackets] are needed to access memory. (The space is currently needed due to a parser bug.) .b indicates the address is byte-length.

set [$FFF009 ].b 130

Odd-numbered 68k memory addresses can't be accessed as Wwords. If you don't know what that means, it means you have to specify the length as a byte, as shown above.

To set a value using a hex number, you must prefix that number with 0x:

set [$FFF009 ].b 0xE1
z80 set [$1B88 ] 0x81

Use ? or help in the debugger for a list of commands.

You can hit return/enter without typing any commands to reuse the last command you entered. For fun, use frames 60 and hit return a bunch of times before focus returns to the debugger.

And for a concrete example of using the debugger to record songs, see Using BlastEm's Debugger to Play SMPS Songs.

For those coming from the Sound Hacking/Sega Consoles page

For triggers that say maincpu

Use set in 68k mode. (This is the default mode when you open the debugger; you needn't do anything special to use it unless you've changed the debugger to z80 mode.)

For genesis_snd_z80

Use set in z80 mode. That's done by using the z80 command as shown above.

You can also use z80 by itself to change to Z80 debugging mode; then you can use set directly with z80 numbers. Note that many SMPS games use the trigger address 1c09.

Using Game Genie codes with BlastEm (for now)

Although BlastEm currently lacks Game Genie support, the utility Game Genie Guy can apply codes for you (and unlike other more dated utilities, it does work). For some games, you must include the "Master Code(s)" to override the checksum, or combine GGG with the UCon utility to correct the checksum when you patch (the GGG readme explains how). If GGG doesn't work for your code, try reading the Troubleshooting section of its readme. (Big thanks to Elfor from the BlastEm Discord for this tip.)

The reason some codes may not work with BlastEm is that they change RAM values to a fixed value; that's impossible to do by patching the ROM, and currently impossible in BlastEm because the values you set with set may just change to something else like nothing happened.

So, if your code is not working, another possibility is to create a GSX savestate with the code you want active in a different emulator, like the Gens/GS r7/+ version listed in our Emulators category. (Some codes only work with that emulator's GG, not Kega or Regen. That's because it's more accurate.)

You want to name the state slot_#.gst where # is any number between 0-9. Then, put it where you've configured BlastEm to look for savestates. (With the settings above, that should be in a folder named for the ROM filename.) You can use both .state and GSTs right by each other, but the former is always what BlastEm looks for first - unless you set the default state type to GST.

And if that doesn't work???

As I discovered to my dismay when trying to access the sound test in Garfield: Caught in the Act (as mentioned on TCRF), the above can fail. The states opened fine, but the recordings were garbled for some reason! In this special case, though, I managed to use the PAR code in BlastEm by:

1. Resetting
2. Immediately opening the debugger (actually, it has to be slightly after resetting but before the Sega Logo, so blastem -d won't really help; takes a bit of lucky timing but is very repeatable)
3. Using set to apply the PAR code:
   • set [$FFEE20 ] 59
   • set/X [$FFEE20 ] 0x3B (note the omitted leading zeroes)
4. Continuing.

Because the Sega Logo is a "scene"/"level" within the game, and so is the debug menu, I made the game load the latter instead of the former. Trying to set the value after other stuff had already been initialized didn't work. This may not work for you either, but with some ingenuity you might be able to achieve results.

Before you file a bug report concerning a specific game...

It's possible an apparent bug may occur on real Genesis/SCD hardware (which makes the bug "correct behavior"); also, a difference from another emulator could be due to that emulator being inaccurate, not BlastEm. Because of these possibilities, it's most helpful to confirm that the game's bug/inaccuracy does not occur on real hardware, and record proof as such, before bringing a report if you can.

That said, if you're unable to do this, BlastEm's developer prefers you risk being wrong than not report a real bug.

The BlastEm homepage links to the project's issue tracker and lists ways to contact the developer about bugs.