SpritesMind.Net

At least i tried to compile it for windows (32 bit) here but i still obtains many unresolved link stuff... I will try to dig into that later but it would be pretty nice to have a mingw makefile for instance

My general thinking is that the theme of v0.3.0 will be "BlastEm Everywhere". A big part of that is getting the emulator to work on ARM and 32-bit x86 CPUs. Porting to Windows is also part of that plan. I was going to do that after the CPU porting stuff was done, but I've taken a break on that to work on other projects. I suppose I could take a stab at getting this working on Windows tonight.

Great news you continue improving BlastEm!

Are you planning to, at some point, add capabilities to display VRAM tiles, backgrounds and sprites?

Well Stef ... I have good news and I have bad news. The good news is that I was able to produce a Windows build of blastem. The bad news is that neither the builtin debugger or the GDB remote debugging support will work due to the hard separation between command line and GUI apps on Windows. These are solvable problems, but I don't have any more time to work on it tonight. Also note that this is a 32-bit build and I haven't finished the 32-bit x86 support in the Z80 core yet so the Z80 is completely disabled.

doragasu wrote:Are you planning to, at some point, add capabilities to display VRAM tiles, backgrounds and sprites?

I used to have VRAM tile viewing support and I plan to put it back in when I get the chance (possibly in 0.3.0, but no promises). When you say backgrounds and sprites do you mean a way to tell the source of a particular pixel (which is present currently), a way to disable certain layers or a separate debugger window that would render each layer individually? I'm generally open to adding any debugging feature that people want as long as I can do it without having a major performance impact when the debugging feature is not enabled. All of those options seem doable, but some are more work than others.

It would be nice having a separate window that lets you watch an entire background (or several backgrounds with enable/disable buttons). But if this is too much trouble to implement, just adding some shortcuts to enable/disable backgrounds (A, B, Window) and also the sprite layer would do the trick.

Other nice additions to help debugging could be adding a window showing the sprite list, and another window showing VDP registers (the same way GensKMod does).

Mask of Destiny wrote:Well Stef ... I have good news and I have bad news. The good news is that I was able to produce a Windows build of blastem. The bad news is that neither the builtin debugger or the GDB remote debugging support will work due to the hard separation between command line and GUI apps on Windows. These are solvable problems, but I don't have any more time to work on it tonight. Also note that this is a 32-bit build and I haven't finished the 32-bit x86 support in the Z80 core yet so the Z80 is completely disabled.

Thanks for taking sometime in that
I saw your Z80 core is not yet ready for x86-32 support (you use x64 registers for emulation i believe). Do you plan to eventually add support for that in future ? Also the point which interest me the most is the GDB remote debugging feature so i really hope that is something that will be supported later ! In the meantime i will play a bit with the current win32 build to finally see this emulator in action

I am using RHEL 6.4. By default it uses older (stable) libraries which causes issues to try to use most prepackaged binaries.

Stef wrote:I saw your Z80 core is not yet ready for x86-32 support (you use x64 registers for emulation i believe). Do you plan to eventually add support for that in future ?

Both cores actually use the extra registers in x64 mode. I started with the 68K core both because it's more important and because there was less hand-written assembly that needed to be generated instead so it could respect the register map configuration. I'll finish the work on the Z80 core before I release 0.3.0.

Stef wrote:Also the point which interest me the most is the GDB remote debugging feature so i really hope that is something that will be supported later !

It shouldn't be too hard to adapt the remote debugging support to use a socket when on Windows. I might even take a stab at that tonight. It might be a while before the builtin debugger makes it to Windows, but that's not terribly relevant if you're using SGDK anyway.

Here's a new preview build for Windows. It's a bit less half-assed than the old one. The biggest changes are that it supports OpenGL rendering and GDB remote debugging happens over a socket on port 1234. So to start remote debugging, you first start the emulator with the -D flag and then you run 'target remote :1234' inside gdb. I haven't tested this build on an actual Windows machine (only Wine), but the last one worked on the real deal so I'm not too worried about this one.

Thanks a tons you modified it so quickly. Will try to play a bit with it GDB support asap ! At least it seems to work (when Z80 is not required)

Comix Zone (U) [!] is not working: just freezing at start.
Sonic The Hedgehog 2 (W) (REV01) [!] crushing in demo. And there is no sound.
Streets of Rage (W) (REV01) [!] crushing before demo. There is sound, but sound is glitchy a bit.
It seems like any ROM with GEMS Sound driver does not working. You can test GEMS on my Jukebox.

The Z80 is completely disabled in the Windows build right now as getting a 64-bit MinGW setup is a pain (and Windows uses a different 64-bit calling convention anyway...) and I haven't finished adding 32-bit x86 support to the Z80 core. Anything that needs the Z80 will not work correctly. I'm pretty sure that's why Comix Zone and other GEMS games don't work.

The "crash" in Sonic 2 is the emulator exiting as the 68K core has walked off the end of the cartridge and I don't currently have any support for running the CPU in unmapped or I/O memory areas. The fact that it walks off the end of the cartridge appears to be a bug in the 32-bit version of the CPU core as it happens under 32-bit Linux as well. I'm guessing the crash in SoR is the same issue. I haven't had a chance to thoroughly test the 32-bit version of the 68K core yet, so it's not surprising that it's a bit buggy.

Glitchy sound may be due to VSync, but I'd have to run it on a proper Windows box to be sure.

Thanks for the report!

Mask of Destiny wrote:getting a 64-bit MinGW setup is a pain

Get the one the RetroArch team prepackaged if that's the case: http://themaister.net/retroarch-dl/MinG ... pthread.7z

Run the included Git Bash.vbs to open a shell.

If it wasn't for the calling convention differences I might be tempted to make a quick 64-bit build with that, but as it stands I don't think it's worth it. This was just a quick preview based on what I could throw together in an evening or two. The 32-bit issues will be worked out before I make an "official" Windows release anyway as I consider that a prerequisite. There are a lot of machines running 32-bit editions of Windows out there and the ones with 64-bit editions can run Exodus (at least if their computer is fast enough anyway).

So when I start up blastem using -d, I entered in my z breakpoints. They never got triggered as expected. But if I waited to enter in the breakpoints after the 68k loaded and reset the z80 the breakpoints work as expected. I assume the breakpoints are removed either when the code is loaded or when the z80 is reset.

If this is intentional or hard to fix, can you at least print to the console that the breakpoints are removed when it happens?