I just released the new version of JEmu2 some interesting additions/fixes/enhancements to the MSX driver:
* Added online high score support for 6 games (Nemesis, Nemesis 2, Nemesis 3, Salamander, Parodius and Penguin Adventure). If you go to the high score page of JEmu2, scroll to the bottom to see the high scores. I have to split this page eventually...
* Fixed the AY-3-8910 emulator, which fixed the sound of all MSX games (and many arcade games too, btw). The noise channel didn't work...
* Solved a problem in the VDP emulator which caused wrong colours in the konami boot sequences.

I also started working on support for MSX2, but that has still a long way to go...

Check it out at www.gagaplay.com.
You need java 1.4 or higher, and a video card capable of hw accellerated OpenGL (most are). It should run on Windows, Linux and Mac.

It's not particulary popular, is it? :-S
Those MSX high score lists are very lonely ...

I got an email about z80 trace in bluemsx probably from you but I accidently erased it. The question was about z80 trace and blueMSX did support it in earlier versions (think 2.1 had it) but I removed it because I changed the way the z80 and other parts are synchronized. The z80 core hasn't changed much since 2.1 so you can use that one to get z80 traces. I'm thinking of adding it back but in the current model its harder to do it non-intrusive when trace is not wanted.

But if it can help you with the jemu I can do a build for you that re-enables it. Let me know if you want it.

The email was not from me, but thanks anyway!
I've been playing around with the blueMSX debugger, but ATM I use RuMSX for tracing so having a trace function in blueMSX is not really priority for me at this time.
The blueMSX debugger is useful for finding the highscore locations and such, but I'm having some stability problems with it (it seems the debugger crashes blueMSX a lot on my PC).
While useful, it is still a bit limited though. It would've been nice to set breakpoints not just on an address in the PC register, but also values in other registers, memory locations, ports etc, and it would've been nice if you could change memory and registers and such on the fly.

I'm not complaining, though :-) I think BlueMSX is an excellent emulator, and the debugger has been very useful for me already.

At this point I'm not really working on the Z80 core (it seems to run almost all games just fine now), but on getting the MSX2 emulation to boot.
I have some V9938 functionality in place, but I think some missing hw features prevent the MSX2 from booting. Maybe it's the RTC or line interrupts which are not emulated yet...
I hope to have some progress to show this weekend...

I found and fixed some minor but quite severe bugs in the debugger and I'm planning to release just an updated version of the debugger this week (I had the fixes for a long time but been a bit lazy...)

More breakpoints is on the todo list and it would indeed be very useful to be able to set them on memory change/access io ports, VDP registers,... Just need some time and figure out how to do it as non intrusive as possible (so it won't slow down the emulation)

To boot MSX2 you don't need Line interrupts but you do need the RTC (just tried removing them in bluemsx and without line interrupts it booted fine but not without the RTC)

during the boot process the RTC is read to fetch the color scheme and (in case of the title or password) fetch the data. Of course it's possible to hack the routine(s) to change that

Regarding the debugger in blueMSX without slowing down emulation, have you thought making a separate debug build? That way the debugger won't slow down emulation at all for 'normal' users. While debugging, it's not really a problem if emulation is a bit slower and recent cpu's will probably be able to keep up anyway.

The blueMSX debugger is a plugin under the form of a dll file in the Tools subdirectory.

If you don't want to load the debugger, you can simply delete the SimpleDebugger.dll and TraceWindow.dll files.

But of course, we could release blueMSX with only the trainer (and all the cheats) in the Tools subdirectory. In this case, the debugger and the tracer could be available as apart files, what's actually the plugin philosophy

Ah I see :-)

As mars said, the debugger is just a plugin and if its not there or if you don't open it it will not add any extra CPU cycles to the emulation. The hooks to the plugin is only executed when the emulation is paused, stopped, or resumed or when a breakpoint is hit. Memory breakpoints would be a bit more CPU intensive and so would contitional breakpoints but as long as none are enabled, it would not slow down anything.

Yay, I got MSX2 booting!
The VDP emulation still needs a lot of work though (sprite colours are wrong, some missing VDP commands, only SCREEN 5 is emulated, etc), but games like Vampire Killer and Metal Gear are now already playable (with wrong sprite colours though).

He I get this error message:
Problem initializing GL
Cause: Could not find a valid pixel format
Should have a simple solution, right?

The cause is that it can't set the display mode using hardware accellerated OpenGL. Most of the time it's a driver issue or lack of proper OpenGL support by the video card.
Try upgrading your drivers. Also try to disable any of the more 'fancy' features of your video card in the OpenGL driver, like FSAA, Anisotrophic filtering etc. Did you try both windowed and fullscreen?

Quote:

Did you try both windowed and fullscreen?

yes, but still no desired result.