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. Except for games which cannot be logged or logged properly in BlastEm, logs made in Kega Fusion or Gens will be rejected.
Whereas the current Release of BlastEm, 0.6.2, cannot log VGMs, beta version 0.6.3 can log VGMs. Its "nightly builds" tend to be very stable and can be trusted to be safe to use.
Download
From the list of nightly builds, choose the most recent filename that matches your Operating System.
Logging Advice
BlastEm's hotkeys are listed at the beginning of default.cfg.
Before you start logging VGMs, there are some things you should check:
- Use the most recent 0.6.3 nightly
- Logs made in nightly
ab3d8759da08(a years-old version) and newer sound better than logs from older nightlies. - You can copy your default.cfg file to the new nightly's directory to keep all your settings from before.
- Change the the places BlastEm will save your logs and screencaps ("save paths")
- Read #Making Paths for Your VGMs and Screenshots for details.
- Confirm which framerate (NTSC/60 fps or PAL/50 fps) the game should be logged in
- 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 instead 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.
- If the game continues to run at 60hz, force PAL mode:
- Launch BlastEm from the command line, using
blastem -r E. You can also put this line 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 despite the methods above, you'll have to hack it or ask for help in VGMRips' IRC.
- Go into "System" in the settings, then change Default Region to "E - Europe". If needed, you can hard reset by pressing F5.
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.
| m | Begin or stop VGM logging |
|---|---|
| p | Take a screenshot |
| u | Open the debugger |
MegaDrive models?
You can keep the Model setting at the default in most cases.
There are some games (e.g. Dinosaurs for Hire and EarthWorm Jim) with a sound engine bug that can cause music slowdowns on Model 1. In those cases, try a different model or search for bugfix patches on Romhacking.net.
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]
| -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:
|
| -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
First (before logging), open BlastEm and go to Settings -> System.
- You should see an option named "Save config with EXE".
- Check this option
- Close BlastEm and delete the blastem.cfg file that appeared in its folder.
Now BlastEm will take options from default.cfg, which is also in blastem.exe's folder.
Open default.cfg in a text editor like Notepad, and find these lines:
initial_path $HOME screenshot_path $HOME vgm_path $HOME
Change $HOME to say $EXEDIR instead.
Next, find the lines that say screenshot_template and vgm_template, and change them to look like this:
screenshot_template $ROMNAME/%Y%m%d_%H%M%S.png vgm_template $ROMNAME/%Y%m%d_%H%M%S.vgm
Now BlastEm will store .vgms and .pngs in subfolders inside blastem.exe's folder, which are named to match the currently-loaded ROM.
If it's still not working
While it's convenient in most cases, the problem with $ROMNAME is:
- If the ROM's filename is too long, it won't be able to create .vgms or screenshots.
- There could be problems caused by non-ASCII folder/filenames on some Operating Systems.
To test for these, you can do either of the following:
- Try making a screenshot with the ROM loaded; BlastEm will tell you if this failed.
- Open the debugger, then enter
corcontinueinto it to make emulation proceed. When you try to log, an error will appear in the debugger window if logging failed.
What should you do in that case?
- Try renaming the ROM to something short/only containing ASCII characters.
- Or, shorten the filenames in the
_templatesettings by removing some of the%wildcards, like%Yfor year. - Or, if you prefer, change out
$ROMNAME/%Y%m%d_%H%M%S.pngfor different wildcards. For instance, you could just change it to%Y%m%d/%H%M%S.pngand vgms will now go in folders based on the current year-month-day.
More Info (incomplete)
More complex forms are possible of the above settings. default.cfg lists further wildcards that can be used.
You can also control where saved games and states go:
save_path $EXEDIR/$ROMNAME
Where $EXEDIR is used it's possible to use .. However, they aren't the same. . means the folder that BlastEm was launched from! This will not match $EXEDIR if you do a complex thing like reuse a cmd window inside your VGM working folder to open BlastEm with cmd options. If that confused you, just stick with $EXEDIR to be safe.
Regarding the blastem.cfg file: you could choose to change settings inside it instead if you wish.
Feel free to experiment with all the 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
uwhile a game is loaded. - Use the
dcommand line switch; the debugger will automatically open when a game is loaded.
When the debugger opens and can take input, the main BlastEm window will pause game execution and stop responding. When you enter c or continue in the debugger, it will stop responding to input and BlastEm resumes. Press u again to re-enter the debugger.
Both windows "queue" any keystrokes performed inside them while they're inactive. Otherwise, it's not possible to work with both windows at once.
Use ? or help in the debugger for a list of commands.
Basic Info
To print the value inside a register, you would enter a line like this:
print/x [$ff05ec ].b
/x is a format code that makes the printed output (lowercase) hex. [brackets] are needed to access memory. (The space is currently needed due to a parser bug.) .b says the address is byte-length.
set [$FFF009 ].b 130
Odd-numbered 68k memory addresses can't be accessed as Wwords. This means means you must say the length is a byte, as shown above.
To use a hex number, you must use the prefix 0x:
set [$FFF009 ].b 0xE1 z80 set [$1B88 ] 0x81
You can hit return/enter without typing any commands to reuse the last command entered. For fun, use
frames 60 and hit return a bunch of times before focus returns to the debugger.
For a concrete (but currently unpolished) example of using the debugger to log 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 68000 (68k) mode. This is the default mode when you open the debugger.
For genesis_snd_z80
Use set in z80 mode. You can do this in either of two ways:
- Use the
z80command as shown above. - Use
z80by itself, which changes to z80 debugging mode. You can then usesetdirectly with z80 numbers.
Many SMPS games use the trigger address 1c09.
Using Game Genie codes with BlastEm (for now)
Though 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 use 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, 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.)
Once you have your savestate:
- Rename the state to
slot_#.gstwhere#is any number between 0-9. - Put the state where BlastEm is configured to look for savestates. (With the
save_pathsetting above, that should be in a folder named for the ROM filename.) - (Optional) Change the default state type setting to GST. Otherwise, blastem's own .state files will be chosen over .gsts in the same slot.
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 vgm logs were garbled for some reason! In this special case, I managed to use the PAR code in BlastEm by:
- Resetting
- Immediately opening the debugger
- Actually, it must be slightly after resetting but before the Sega Logo, so
blastem -dwon't work; takes a bit of lucky timing but is very repeatable.
- Actually, it must be slightly after resetting but before the Sega Logo, so
- Using
setto apply the PAR code:set [$FFEE20 ] 59set/X [$FFEE20 ] 0x3B(note the omitted leading zeroes)
- 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.