MSX support added to QEMU

jr, the author of the original Symbian based S60 and S80 ports of the fMSX emulator, has added support for MSX1 system emulation in QEMU, an open source processor emulation. The goal is to introduce the fastest MSX emulator around and QEMU provides a good platform being a dynamic recompilation engine that recompiles the emulated target machine code to host machine code before executing it. The QEMU MSX system emulation is further based on work done by Stuart Brady that brings the Z80 target processor and ZX Spectrum system support to QEMU. QEMU itself has been ported to and supports several platforms including Linux, OS X and Windows.

The capabilities of the QEMU MSX emulation are currently rather limited but what is included is: Z80 with 64kB RAM, TMS9918A VDP (screen level rendering accuracy only), i8255 PPI with memory slot mapper and keyboard support, AY-3-8910 (simple port I/O is emulated but no audio is generated), loading of ROM cartridges.

Relevant link: jr's qemu page

Comments (21)

By muffie

Paladin (933)

31-07-2009, 22:15

the goal is to introduce the fastest MSX emulator

Really? why we would need something like that?
I mean, probably a core 2 duo running any msx emulator could emulate a 1000000000000000000000000000mhz z80!

By lionelritchie

Champion (439)

31-07-2009, 22:30

it runs in a 386?

By wouter_

Hero (535)

31-07-2009, 23:41

Very interesting project. This certainly has the potential to become a very fast MSX emulator. Though I believe that ATM openMSX is still faster, this is how I tested:

I turned up the openMSX Z80 clock frequency till emulation just doesn't take 100% host CPU (i verified that emulation still runs at 50 fps, without frameskip). Next I ran this very simple BASIC program side-by-side in both openMSX and QEMU-MSX

10 PRINTA:A=A+1:GOTO10

In this test openMSX was faster for me. Though I'd still like to verify with jr that this is a fair test and that I configured QEMU-MSX correctly. (I won't give numbers before I verified this.)

@jr: I couldn't find your email address on your QEMU-MSX page nor in the QEMU-MSX package. Can you send me an email: wouter DOT vermaelen AT scarlet DOT be. Or else join us on irc: #openmsx on irc.freenode.net. Maybe we can work together to improve the speed of both openMSX and QEMU-MSX?

By wolf_

Ambassador_ (10135)

01-08-2009, 00:06

with a bit of luck, everyone enters his email address in his MRC account ..

.. like jr did :P

By andete

Expert (97)

01-08-2009, 08:08

Very cool!

By dvik

Prophet (2200)

01-08-2009, 10:02

Cool indeed, but whats the point of having a fast emulation that can't play games?

By jr

Champion (379)

01-08-2009, 11:48

Well, I think there are already excellent emulators for playing MSX games so there's room for an emulator that aims for something else than 1:1 game play And anyway, Konami games work great since they run the game main loop in the interrupt handler (VDP interrupts are emulated at approximately correct speed)... But hey, who wouldn't like to program in MSX BASIC and have the programs run faster than machine code in the original computer? I guess I'll have to add support for a disk interface so running MSX-DOS and CP/M would be possible as well.

QEMU runs on various different host platforms, Intel x86 is one of those. I have only tested qemu-msx on OS X 10.5 and on a virtual Windows XP inside VMWare on OS X. The 64bit qemu-msx on my core2duo machine running OS X 10.5 executes the MSX-BASIC statement

for a=0 to 1000000:next

roughly five times as fast as openmsx when openmsx cpu frequency is unlocked and rendering mode is set to screen accuracy with no frameskip. But I guess this can vary a lot from host machine and OS to another. Anyhow, most of the time is spent in the QEMU code generator and Z80 core emulation rather than the MSX specific emulation, which is relatively small and simple piece of code.

And indeed as pointed out, you can send your hatemail to the address you find from my MRC account if you feel like I need to be punished for doing this.

By dvik

Prophet (2200)

01-08-2009, 17:28

QEMU is a great emulator so its cool to see MSX support. Its more that I don't see a real use for it if its not failry timing accurate.

By jr

Champion (379)

03-08-2009, 07:15

I understand. Isn't this similar to replacing the Z80A of an MSX with Z80B or Z80H? I think QEMU does not provide any good means for limiting the speed of the emulated main CPU -- I may be wrong of course.

By dvik

Prophet (2200)

03-08-2009, 07:43

I don't know if qemu can be timing accurate. I've only used the arm emulation and then I didn't care about the speed so much because I was writing c++ programs that weren't timing sensitive. I guess the problem with msx emulation is that so many games rely on timing, but as you said, games that are synched to vblank shouldn't have any problem to run ok.

By wouter_

Hero (535)

03-08-2009, 21:37

Ok, I've confirmed it with jr: Z80 emulation in openMSX is about 10%-15% faster than the current version of QEMU-MSX. Though the dynamic recompilation in QEMU can still be optimized a lot, while it will be hard to still get significant speedups by tuning the Z80 interpreter in openMSX. So QEMU-MSX definitely has a lot of potential!

The problem in benchmarking openMSX was that by default the max Z80 freq is limited to 100MHz (we choose an arbitrary upper limit .. seemed high enough at the time). But to utilize the host CPU for 100%, the Z80 freq had to go as high as 680MHz (this is on my 2 year old core2 6600 cpu). That's 190x real-time speed!

By dvik

Prophet (2200)

04-08-2009, 05:24

So just curious, what exactly are you measuring? Running regular MSX with a super overclocked z80 or is the vdp and everything else also running enormously fast?

By wouter_

Hero (535)

04-08-2009, 07:53

@dvik: exactly, a normal MSX with highly overclocked Z80. I wanted to configure openMSX as close as possible to qemu-msx. So that means also using SDL renderer at 320x240, without frameskip. I didn't bother switch pixel accurate rendering to screen accurate nor did i turn off sound emulation (takes hardly any emulation time when there is no sound playing).

By dvik

Prophet (2200)

04-08-2009, 20:56

In that case I think the fMSX z80 emulation is even faster because it doesn't emulate some of the flags and is only doing timer updates once per instruction. Not sure what impact the rest of fMSX has, but at least its Z80 emulation is pretty efficiently written.

By wouter_

Hero (535)

04-08-2009, 23:15

I'm not so sure the fMSX Z80 emulation is faster. I compared the fMSX/openMSX generated x86 asm code for the Z80 emulation main loop and for some instructions: Most are very comparable. Some are simpler in fMSX because (like you said) some functionality is not emulated. (Non-opcode) memory reads and memory writes are faster in openMSX (and these happen fairly often). So overal I believe the speed will be similar. But I admit I didn't actually measure it (I couldn't find an easy way to make (only) the fMSX Z80 core run at a higher freq).

But then, it's hardly fair to compare the fMSX Z80 core with several limitations (most important for emulation speed: inaccurate R register emulation, unable to fetch opcodes from 'special memory regions', some flags not emulated, ..) with the fully correct openMSX Z80 core (at least no bugs or limitations are known ATM).

By dvik

Prophet (2200)

05-08-2009, 22:22

If you want to have a simple platform for testing z80 emulation, you can port my latest emulator bluemsxnano to linux and then add the openMSX z80 emulation. I integrated the fMSX z80 emulation as a test and it took less than 20 minutes. Porting to Linux involves implementing three methods, so its not a big effort.

** EDIT: Fixed url to emulator **

Info about bluemsxnano:
==================

Its a brand new MSX1 emulator that executes in a dos shell. The emulator has text output so only screen 0 and 1 are supported. The emulator uses 100% CPU and dynamically adjusts the Z80 frequency to maintain 50 FPS. Its a very scaled down emulator but runs basic programs, either programmed in the emulator or by executing basic roms. Regular roms up to 32kB are also supported.

By umaiboux

Resident (43)

14-08-2009, 15:53

for Windows,
int fd = open(filename, O_RDONLY);
should be changed to
int fd = open(filename, O_RDONLY | O_BINARY);
(hw/msx_mmu.c), shouldn't it?

Windows users cannot use an external cartridge image now.

By jr

Champion (379)

16-08-2009, 07:16

Ah, I forgot that Windows opens all files in "text mode" by default. I'll fix it, thanks for the heads-up.

By umaiboux

Resident (43)

21-08-2009, 15:14

I use Japanese Windows and the Japanese keyboard.
I ran QEMU MSX with SDL.dll of "qemu-msx-2.winxp.zip", and I cannot use cursor control keys.
I ran QEMU MSX with SDL.dll of "QEMU on Windows", and I can use cursor control keys.
How about the non-Japanese Windows users?

old "QEMU on Windows" site is hereï¼š http://www.h7.dion.ne.jp/~qemu-win/
new "QEMU on Windows" site is hereï¼š http://homepage3.nifty.com/takeda-toshiya/qemu/

By jr

Champion (379)

21-08-2009, 20:26

Hmmm... ok, good to know. SDL is not built with QEMU, but since QEMU compilation on windows requires mingw32 I thought it'd be easier for many windows users if I provided a precompiled binary of QEMU and so I built the SDL.dll as well. For SDL, I simply downloaded version 1.2.13 sources from libsdl.org and compiled it with mingw32. Perhaps the SDL.dll that works for you is a different version or compiled with different setup than what I used.

By umaiboux

Resident (43)

22-08-2009, 15:38

Additional information

SDL.dll of "zodiac-win-0.8.1.lzh" : I can use cursor control keys.
SDL.dll of "SDL-1.2.13-win32.zip" from www.libsdl.org : I cannot use cursor control keys.
SDL.dll of "fmsx-sdl-2.6.0.40.zip" : I can use cursor control keys.

Share

Related content

Comments (21)