BlastEm Gen/MD emulator 0.4.0 released: Now with GUI, better accuracy and more

Printable View

05-04-2016, 05:43 PM
Mask of Destiny

BlastEm Gen/MD emulator 0.4.0 released: Now with GUI, better accuracy and more

Hello folks,

I've released a new version of my Genesis/Megadrive emulator: BlastEm. This new version is the first to include a GUI and it's actually a fairly unconventional one. The UI is actually a Genesis ROM running inside the emulator with a little extra "hardware" to get access to directory listings and to have hooks into the necessary emulator functionality. There will probably be a "real" GUI at some point, but this was a fun experiment.

Other new features include Mega/Sega mouse support, 68K overclocking (or underclocking if that's your thing), a configurable low-pass filter and basic lock-on support (currently only accessible on the command line and needs work to handle both Sonic 2 and the save RAM added by Sonic 3).

There are also a whole host of accuracy improvements and bugfixes. The demo, "MDEM's First" now runs correctly. "YOUR EMULATOR SUX" is fully gone from Titan's Overdrive (though some smaller problems remain) and a bunch of commercial games that had issues in previous versions now work correctly.

You can see a more complete list of changes in the changelog. I've also updated the main BlastEm page a bit (though the screenshots are still old). You can find download links on both pages.
05-04-2016, 06:59 PM
ComradeOj

I'm glad to see BlastEm making more progress!

BlastEm is the only emulator that can run my DMA David game correctly, and at full speed. It runs on exodus, but it's jittery and runs really slow.

I just tried out the windows and linux versions, and both played everything I tried well. The only problem was, I couldn't access all my drives or folders through the built-in GUI. On windows, I only got as far as the root of C:\. On linux, I was limited to my home directory.

Having the GUI as a genesis rom is kind of cool. I wonder if the AtGames emulator consoles do something similar?
05-04-2016, 09:45 PM
Mask of Destiny

Quote:

Originally Posted by ComradeOj

On windows, I only got as far as the root of C:\.

Whoops. I didn't even think of that. I've been on Linux too long.

Quote:

Originally Posted by ComradeOj

On linux, I was limited to my home directory.

There was no ".." entry to allow you to go up another level? Weird. I'll have to look into that.

There is a config file option to change the starting directory, but I think I forgot to document it (whoops again). The config parameter is called "initial_path" and goes inside the "ui" section.

Quote:

Originally Posted by ComradeOj

I wonder if the AtGames emulator consoles do something similar?

I wouldn't think so, but I suppose it's possible. I've been meaning to try and dump the internal flash of mine to try and learn more about the hardware and potentially hack it.
05-04-2016, 10:19 PM
ComradeOj

Quote:

Originally Posted by Mask of Destiny

There was no ".." entry to allow you to go up another level? Weird. I'll have to look into that.

There was, but it only went up as far as /home. Once you're there, clicking on ".." doesn't do anything. I tried making a link to "/" within my home folder and opening that through the BlastEm GUI. It said "Error reading from /".

Adding "initial_path /" under "ui" like you said worked though. Thanks for the info! A minor problem, but trying to open a folder you don't have permissions to will give you a permission denied error, and make the program just show an empty green screen with no ".." to get you back.
05-05-2016, 02:15 AM
Mask of Destiny

Thanks for the reports. I've figured out why you couldn't navigate to the root directory and I've pushed a fix to the repo. The other problems (not being able to select drives on Windows and not properly dealing with errors on directory read) will take a litlte longer. I'm going to try to do a point release a few days from now with a few small fixes including these.
05-05-2016, 11:06 AM
Darguel

Awesome!
05-05-2016, 12:16 PM
cleeg

This is very interesting, particularly in terms of Android. Do you plant to have the emulator run 32X, MCD and 32XCD game ROMs at any stage? This would be perfect for my WikiPad.
05-05-2016, 01:55 PM
Mask of Destiny

Quote:

Originally Posted by cleeg

Do you plant to have the emulator run 32X, MCD and 32XCD game ROMs at any stage?

I did a tiny bit of work on Sega/Mega CD emulation in a private branch, but I think 32X support is what I'm going to work on next. I want to do an overhaul on my CPU emulation code and the SH-2s bring some interesting challenges that I want to make sure the new approach can handle. I also get the impression that the current state of 32X emulation is worse.

Quote:

Originally Posted by cleeg

This would be perfect for my WikiPad.

Sadly, the current version of BlastEm requires an x86 processor as the CPU emulation code generates machine code at runtime. The WikiPad, like most Android devices, uses an ARM CPU. I did a little bit of work on ARM support a while back, but it's far from complete. Part of my hope with the CPU emulation rework is to make supporting other architectures easier though. So hopefully ARM support will arrive not too long after 32X support does.
04-23-2018, 02:56 AM
ComradeOj

I decided to try a nightly build today, and have a few bugs to report. These are affecting the newest nightly version d14490dee01f (and possibly others) but not the main 0.5.1 version. I've downloaded the pre-compiled version, but also compiled it from the source too. I know that nightly builds aren't meant for stability, but wanted to report these bugs in case they aren't noticed in the future or known about.

1. The program segfaults when dragging and dropping a ROM file into the window.
2. The program lags and prints errors when lowpass cutoff frequency exceeds 10000
3. The program lags and prints the same errors when running on my secondary monitor.
4. Same error issue, but when opening the debugger

Everything is fine at 10000hz and below, but lags and prints errors to the terminal above this. The same happens when I move the window over to my secondary monitor. I run dual monitors, and the program runs fine on my main (left) monitor. It acts as described when I drag it over to the right monitor. Oddly enough the fusion emulator will stop showing graphics when I run it on my secondary monitor, so there could be some issue on my end.

The cash report says at the top:

Code:

reason blastem killed by SIGSEGV crash_function on_drag_drop.2417

I can post more crash info if needed

A sample of the error messages shown:

Code:

Underflow of 228 samples, read_start: 25152, read_end: 26744, mask: 7FFF Underflow of 228 samples, read_start: 12576, read_end: 13372, mask: 3FFF Underflow of 208 samples, read_start: 6264, read_end: 7896, mask: 7FFF Underflow of 208 samples, read_start: 3132, read_end: 3948, mask: 3FFF Underflow of 188 samples, read_start: 20184, read_end: 21856, mask: 7FFF

System specs:

OS: Fedora 27 64 bit
Kernel: 4.15.17-300.fc27.x86_64
DE: XFCE (xorg)
GPU: Radeon RX480
CPU: Ryzen 1800X
04-23-2018, 03:36 AM
Mask of Destiny

Thanks for the detailed report! Looks like the last 3 of those are all related to the new "sync to video" code. Could you send me the output of the command xrandr? It might help me figure out why #3 is happening.
04-23-2018, 03:44 AM
ComradeOj

Quote:

Originally Posted by Mask of Destiny

Thanks for the detailed report! Looks like the last 3 of those are all related to the new "sync to video" code. Could you send me the output of the command xrandr? It might help me figure out why #3 is happening.

Left main monitor is 1920x1080 144hz through dispalyport. Right secondary monitor is 1920x1080 60hz through DVI-D. As an experiment, I just set my 144hz monitor down to 60, and the problem was much less severe, but still sort of occurred off and on, especially when moving the window across the two screens. Blastem also sped up when I set my monitor back to 144hz.

xrandr output:

Code:

Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 16384 x 16384 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm 1920x1080 119.98 + 143.85* 120.00 100.00 119.88 99.90 60.00 50.00 59.94 30.00 25.00 24.00 29.97 23.98 1600x1200 60.00 1680x1050 59.95 1400x1050 59.98 1280x1024 75.02 60.02 1440x900 59.89 1280x960 60.00 1280x800 119.98 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 75.00 72.81 66.67 60.00 59.94 720x400 70.08 HDMI-A-0 disconnected (normal left inverted right x axis y axis) HDMI-A-1 disconnected (normal left inverted right x axis y axis) DVI-D-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 509mm x 286mm 1920x1080 60.00*+ 60.00 59.94 1680x1050 60.00 1280x1024 60.00 1440x900 60.00 1280x800 60.00 1280x720 60.00 59.94 1024x768 75.03 70.07 60.00 800x600 72.19 75.00 60.32 720x480 60.00 59.94 640x480 75.00 60.00 59.94
04-23-2018, 12:31 PM
TmEE

Versions starting with Paprium update (maybe earlier too but I haven't tried them) seems not to respect the paths in Default.cfg anymore. Screenshots, saves and other things seem to go into the root of the user profile on my machine (place where nothing should go IMO). I also had to set user input and other settings when I tried it, suggesting config is read from elsewhere than root of the program folder, but I didn't find another Default.cfg anywhere on the machine. When I renamed the existing file all my previously set settings are intact still, so I suppose conf comes elsewhere now...?
WinXP SP3 machine, C2D with intel integrated GFX.
04-23-2018, 02:33 PM
Mask of Destiny

Quote:

Originally Posted by ComradeOj

Left main monitor is 1920x1080 144hz through dispalyport. Right secondary monitor is 1920x1080 60hz through DVI-D. As an experiment, I just set my 144hz monitor down to 60, and the problem was much less severe, but still sort of occurred off and on, especially when moving the window across the two screens. Blastem also sped up when I set my monitor back to 144hz.

Ah yes, the current sync to video code will probably not cope too well with setups with two very different refresh rates. I'll have to see if I can come up with a solution for that. I've been thinking about adding an "auto" sync option that will use "sync to video" when monitor and emulated system have similar refresh rates, but "sync to audio" when they're different. Perhaps I should also switch to "sync to audio" for the multiple monitors with different refresh rates too.

It's disappointing, though not entirely unexpected that there are some issues even when they have the same refresh rate. Guess my dynamic rate control algorithm still needs some work.

Quote:

Originally Posted by TmEE

Versions starting with Paprium update (maybe earlier too but I haven't tried them) seems not to respect the paths in Default.cfg anymore. Screenshots, saves and other things seem to go into the root of the user profile on my machine (place where nothing should go IMO). I also had to set user input and other settings when I tried it, suggesting config is read from elsewhere than root of the program folder, but I didn't find another Default.cfg anywhere on the machine. When I renamed the existing file all my previously set settings are intact still, so I suppose conf comes elsewhere now...?
WinXP SP3 machine, C2D with intel integrated GFX.

There have always been two config file locations that BlastEm looks for. What's changed is that there is now some code to automatically save the config to the "preferred" location (which on Windows will be somewhere in the %appdata% folder, README should have the relative path from there) to support changing the config from the UI. I think this is currently done every time the emulator exits, but I plan to change it so it's' only written when the config is actually changed. I also plan to add an option to prefer the config file in the same folder as BlastEm. Paths will also be configurable in the editor before the stable release. Apologies for the mess in the meantime.

I'll also double check the default paths on Windows. Saves should default to being somewhere in %appdata% so if that's not happening I messed something up somewhere. Default screenshot path is the user's home folder on all platforms right now, which I should fix.
04-24-2018, 02:40 AM
TmEE

Ok, I found things in userprofile\local settings\application data\blastem. Anyway now I can change the paths etc. to more useful locations meanwhile so no worries.

I personally would much prefer "portable" behaviour, all data stays in the location of the program so I can move things from machine to machine without having to set up everything again or dig in system locations to move over the data or just run the program from LAN and all settings and data stays in that one computer that hosts the program to other machine in my network.
04-26-2018, 07:46 PM
Eep386

1 Attachment(s)

For the convenience of those of us still on Windows, here's the documentation for the Win32 version of BlastEm 0.5.1 converted from Unix encoding, so that it reads correctly under Windows Notepad:
Attachment 14105