BlastEm - Yet another Genesis emulator

Stef · Post by **Stef** » Fri Sep 13, 2013 9:46 am

So i do ! GDB features sound awesome !

Oerg866 · Post by **Oerg866** » Wed Nov 06, 2013 11:16 am

Awesome work.

Judging by this:

Homebrew Compatibility

Day Trip - 3D cube section is skipped
MDEM 2011 - Video freezes in the 10-channel mode section
Overdrive - Sounds is rather messed up, freezes shortly after the Titan logo
Elite - Game freezes as soon as it starts and flashes weird colors

it needs some work

We'd be delighted to help emulator devs with information or source code to get the bugs out.

Mask of Destiny · Post by **Mask of Destiny** » Wed Nov 06, 2013 7:41 pm

Oerg866 wrote:it needs some work

It does indeed.

Oerg866 wrote:We'd be delighted to help emulator devs with information or source code to get the bugs out.

That would definitely be appreciated. I had spent a little time trying to diagnose the problems with Overdrive a while back, but got a bit bogged down figuring out how some of the code was supposed to work. I'll take another look tonight and see if I can come up with any specific questions.

Mask of Destiny · Post by **Mask of Destiny** » Thu Nov 07, 2013 7:56 am

Well I figured out the main problem with Overdrive. ld (hl), h was busted due to an error in the way I'm compensating for the limitations on use of the high 8-bit regs (AH, BH, CH and DH) in x86-64. My code generator inserts a rotate on the appropriate word-sized reg when I need to access the upper byte in an instruction that needs the REX prefix. However, in an instruction like ld (hl), h I also need access to the full word-sized register so some care is needed to make sure I don't get a rotated version.

After that fix, the whole demo runs. Samples are still messed up (probably more Z80 problems) and there are some timing problems (screen gets disabled at the wrong time in some places, so part of the screen gets blanked out and I get the "Your Emulator Sux" text). At the moment, I don't think I need any particular assistance in tracking down the remaining problems there, but I'll keep your offer in mind in case I get stuck on this or one of your other demos.

Stef · Post by **Stef** » Thu Nov 07, 2013 9:29 am

Did you code BlastEm in assembly (or at least used assembly generator for the CPU cores) O_o ??

Oerg866 · Post by **Oerg866** » Thu Nov 07, 2013 4:02 pm

Mask of Destiny wrote:Well I figured out the main problem with Overdrive. ld (hl), h was busted due to an error in the way I'm compensating for the limitations on use of the high 8-bit regs (AH, BH, CH and DH) in x86-64. My code generator inserts a rotate on the appropriate word-sized reg when I need to access the upper byte in an instruction that needs the REX prefix. However, in an instruction like ld (hl), h I also need access to the full word-sized register so some care is needed to make sure I don't get a rotated version.

After that fix, the whole demo runs. Samples are still messed up (probably more Z80 problems) and there are some timing problems (screen gets disabled at the wrong time in some places, so part of the screen gets blanked out and I get the "Your Emulator Sux" text). At the moment, I don't think I need any particular assistance in tracking down the remaining problems there, but I'll keep your offer in mind in case I get stuck on this or one of your other demos.

Yes, Z80 emulation must be working perfectly for the demo to run correctly, as the whole demo is synced to the music which is done by checking a flag set by the song's data stream as it is played back. Glad you figured out the issue

Mask of Destiny · Post by **Mask of Destiny** » Thu Nov 07, 2013 5:39 pm

Stef wrote:Did you code BlastEm in assembly (or at least used assembly generator for the CPU cores) O_o ??

BlastEm is written almost entirely in C; however, the CPU cores are dynarecs so they generate machine code at runtime. They're fairly simple as dynarecs go though. I'm not doing any fancy optimizations at the moment and I have a fixed register allocation.

Going the dynarec route was probably overkill for the Genesis, but I wanted to free up as many cycles as possible for accuracy elsewhere and I had been wanting to get my feet wet with dynarecs anyway.

doragasu · Post by **doragasu** » Sat Feb 08, 2014 10:53 pm

Any news about a new version with GDB support?

Mask of Destiny · Post by **Mask of Destiny** » Sat Feb 08, 2014 11:40 pm

I got bogged down on that and then got distracted with other things (some BlastEm related, some not). However, GDB support has my attention again and my wife is away on a retreat so I can devote my entire attention to side projects this weekend. With any luck I'll be ready to cut a new release that includes GDB remote debugging support (amongst other things) sometime tomorrow.

Stef · Post by **Stef** » Sun Feb 09, 2014 11:24 am

That would be awesome

doragasu · Post by **doragasu** » Sun Feb 09, 2014 3:16 pm

That's wonderful news!!!

Thanks for the update!

Mask of Destiny · Post by **Mask of Destiny** » Mon Feb 10, 2014 6:27 am

I've got GDB remote debugging working, but I need to do a little more work to get single stepping working. Between that, a few smaller bits of GDB support and a couple of things on the audio side I want to fix, I'm not quite ready for a release. However, if you want to try it out now the code is in the Mercurial repo. In addition to SDL, you now need the development headers/libs for OpenGL and GLEW unless you disable OpenGL support with NO_GL=1. Once you've built it you can initiate a GDB debugging session with:

Code: Select all

target remote | SOMEPATH/blastem YOURROM.bin -D

Currently, you can set breakpoints, inspect memory and registers and continue. In the actual release (which might be as soon as tomorrow evening, but we'll see) you will also be able to single step the program and modify registers and memory. Watchpoints and tracepoints will have to wait until a future release.

djcouchycouch · Post by **djcouchycouch** » Mon Feb 10, 2014 6:20 pm

Same noob questions I asked kaneda about his gdb implementation:

SGDK projects work with this?
Variables and function names are shown and not just addresses?
Do the kdebug messages appear in gdb output?

Thanks!

Mask of Destiny · Post by **Mask of Destiny** » Mon Feb 10, 2014 7:07 pm

djcouchycouch wrote:SGDK projects work with this?

I tested it with an SGDK project using a toolchain setup using the Makefile from the "Linux Genesis Dev Setup" thread. The Makefile for my actual test game needed some minor tweaks. I added -ggdb to CCFLAGS and made out.elf an actual target rather than a temporary that gets deleted. I also configured and built gdb for a m68k-elf target.

djcouchycouch wrote:Variables and function names are shown and not just addresses?

Yep, as long as you start gdb with a .elf file that contains debug symbols, you'll have full source-level debugging (apart from the missing features mentioned above).

djcouchycouch wrote:Do the kdebug messages appear in gdb output?

BlastEm does not currently support kdebug messages; however, there are two ways they could be printed into the terminal being used for GDB. The simplest is to just print them on stderr. Since BlastEm is currently using the pipe method (rather than sockets) for the remote connection messages sent to stderr will show up in the terminal. If you want this to work across a socket connection (what Gens KMod appears to be using), they would need to be sent using the File I/O Remote Protocol Extension

Mask of Destiny · Post by **Mask of Destiny** » Thu Feb 13, 2014 10:22 am

Version 0.2.0 is out! You can download it from the main BlastEm page. New features include the promised GDB remote debugging, turbo/slow modes and an OpenGL backend that allow filters to be written as GLSL shaders. There have also been some small improvements to the built-in debugger.

On the accuracy front, I've fixed the most egregious bugs in my YM-2612 implementation, though it's still not feature complete and there are surely other bugs lurking. One accuracy fix that might be of interest to homebrew developers is that I know have some basic emulation of wait states when the Z80 accesses the 68K's bus. A normal read will be delayed 3 cycles and the second read of a 2-byte read (from a POP instruction for instance) will be delayed 4 cycles. Additionally, if the access occurs during DMA, the Z80 will be suspended until DMA completes (though this hasn't been thoroughy tested).

That's the highlights. A more complete changelog is available here.