fMSX/MAC 3.0.1

There are indeed some differences between both emulators :
- fMSX/Mac is not freeware but openMSX is freeware
- fMSX/Mac is based on ... fMSX (easy !), so it means lack of accuracy, lack of good quality sound for MSX-MUSIC, lack of different features (Turbo-R support, MSX-AUDIO, MoonSound and more ...) ; openMSX is accurate, has a good quality sound and many 'extra' features .... just like blueMSX, but there's not yet a Mac port of blueMSX ... and Richard Bannister is not interested by such a port

Mac users : you should annoy Richard with a blueMSX port !!!

Mars: Thanks for your praise for openMSX. However, I have to disagree with your conclusion: if someone doesn't like fMSX/Mac, he should just not register it, instead of annoying its developer. I don't think it's ever a good idea to annoy a developer because he didn't make what you want, unless you paid him to make it.

By the way, although we don't have a universal binary yet, the CVS version of openMSX can be compiled and run on Intel Macs.

Note that openMSX is not only freeware (a.k.a.: gratis) it is also free software (a.k.a. libre). Most people won't care, but I do BlueMSX is also free software, btw, so that's cool

the MRC staff are very well at taking care of consuming all donated alcoholic drinks ourselves, thank you! -hips-

It can still be used/developed and there are so many contributions to the fMSX code by the MSX community that it has evolved from the beginning to a certain point ... but as Marat is not interested to get over this point by adding for example Turbo-R support, it can explain a slow disinterest for this emulator and almost all his clones ... only paraMSX, the most evolved fMSX clone can still be interesting for some users.

As I don't have a Mac, I don't know if fMSX/Mac can be compared to paraMSX

openMSX did not at any point contain fMSX code. However, the Z80 engine started with Marcel de Kogel's code, which is also used in fMSX; I think this code has been fully rewritten by now. The V9938 command engine started with Alex Wulm's code, just as fMSX, and although we made several improvements, the basic design is still the same as the original code from Alex.

Although we're not using fMSX code, we were influenced by fMSX a lot. I think most openMSX developers have played with the fMSX code. I even submitted several fixes for fMSX. fMSX got me interested in MSX emulation and it taught me how an emulator works.

However, there are certain limitations in the design of fMSX that are impossible to overcome without major changes. The most important one is that the interleaving of different devices is done with static time slots (of 1/256th frame) instead of dynamically (like openMSX's EmuTime concept). David started with some designs to improve fMSX, but with Marat being the only person working on the fMSX code base, it seemed unlikely those would ever be implemented in fMSX. So David started openMSX...

Whether fMSX or openMSX is easier to port depends on your point of view. For porting fMSX you have to write platform specific video, audio and input code and then only compile fMSX itself, while for porting openMSX you don't have to write any code, but you have to compile several libraries before you can compile openMSX itself. Those libraries are ported to a lot of systems already: there aren't many systems on which SDL doesn't run (it runs on PDAs, game consoles etc), GCC is the most portable (cross) compiler out there and the required libraries TCL, libpng and libxml2 are widely ported as well.

I wasn't offended. I just think it's important to stress that we use a lot of code from other people, but only if the authors gave permission.

The MegaROM mapper auto-detection algorithm is indeed the same as fMSX: look for "LD (nnnn),A" instructions and increase a counter for each mapper which is typically written at address nnnn. This works very well in practice, so we didn't want to reinvent the wheel. But it's not the same code.

When every platform was shipping its own C++ compiler, each of which was broken in a different way, ANSI-C was indeed more portable than C++. But now that GCC is available everywhere, this is less of an issue.

For the libraries, I don't think the portability itself is an issue there. It seems that people who port emulators don't like messing around with build systems and rather write new code instead, even if that is more effort. I want to create a Makefile that (cross) compiles all libraries needed for openMSX, so porting becomes almost automatic. It will be based on the Makefile that creates the static libraries for the OS X binary.

Other factors can discourage to port openMSX on a 'exotic' system. Just an example : if the developer prefers a direct support of CAS files, what requires BIOS patching, something that is not in harmony with the openMSX conception, then this developer will try to port another emulator or even to create his own emulator.

Direct support of CAS files was only one example. But an accumulation of different things not supported and/or implemented in the way that the developer conceives his emulator could be enough to discourage him to make the port of an existing emulator.

For developers that wants a good MSX core but want to develop their own gui, I can also recommend blueMSX. The emulator core is written in plain C/C++ with a nice and clean interface and only depends on standard libraries. That would be similar to port fMSX though so all gui, audio and input needs to be rewritten. I plan to do a linux version with only the core some day but I'm out of spare time atm.

I guess one thing that is not really mentioned in the discussion is the fact that some users may want to extend the functionallity and/or user interface in their ports and if thats the case I think its easier to start with just an emulator core such as fMSX. Not because its harder to use the sdl libraries, but because to extend or modify the interface requires quite a lot of knowledge about how its working. So if the goal is to write a 'new' emulator based on some earlier one, the time it takes to learn the existing code could easily be as time consuming as writing it from scratch.

But if the goal is to get an emulator running on a new system, porting openMSX sounds a lot easier than rewriting everything. But some of the fun developing an emulator is to have the freedom to do what you want and to get the knowledge about the system that is hard to get unless you've actually developed it yourself.

So porting vs rewriting is I guess a matter of taste and what the goal with the project is.

You don't have a good quality of sound in fMSX/DOS, but maybe it does not matter for you