text: fMSX/MAC 3.0.1 | MSX Resource Center
  Home » News » Emulation » fMSX/MAC 3.0.1
  Relevant link: fMSX/MAC 3.0.1
  Alternatively, if you don't like this emulator, have a go at openMSX for PPC Mac OS X and tell us what you think about it!
  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 !!!
  Yeah, its better to spend those $20 on a couple of beers for the openMSX dev team. But its always nice to see some progress on other emus though.
  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.
  mth : you have fundamentally right, but maybe you don't have noticed my smiley ...
  Of course, as blueMSX co-developer, I perfectly understand that the developers of an emulator are the masters of their work, they will implement some required features only if they think that their implementation is useful and is in harmony with the general conception of the emulator. A fortiori, if we speak about a port of an emulator for a different OS.
  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
  So double free ... and a double beer for you and me !
  Oops, I'm not on MSX Café .... where are the beers on MRC ????
  19-04-2006, 00:27
  the MRC staff are very well at taking care of consuming all donated alcoholic drinks ourselves, thank you! -hips-
  - 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 ...) Uhm, so just because an emulator is not the best it should not be used/developed at all?
  19-04-2006, 20:04
  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
  fMSX has been a source to most good MSX emulators. blueMSX started out as a clone of fMSX although it doesn't have any fMSX code anymore. NLMSX still uses some code from fMSX, openMSX has been using fMSX as reference and contained small amount of fMSX code until quite recently (think it was some rom detection code or something). Wouldn't be suprised if RuMSX is an fMSX clone too since part of the source is never released. MSX-PLAYer is also an fMSX clone and there are tons of others. So I think Marat deserves more credit than he gets.
  I agree though that MSX emulators has taken a gigant step the last 5 years and fMSX is not that interesting anymore. But the code is portable and easy to compile and port to other platforms which gives it a niche in the emulator scene. Although openMSX is somewhat portable, fMSX is far easier to port to non posix/sdl systems.
  So I think we can give a beer to Marat too (but maybe deduct it on the license fee )
  19-04-2006, 22:27
  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.
  19-04-2006, 22:53
  I didn't mean to offend you mth by comparing fMSX and openMSX
  I know that openMSX don't use any code from fMSX directly but I've seen some code in the past that seem to been influenced by fMSX with the same algorithms and logic but I doubt that any of that code is still there.
  One big limitation with fMSX is indeed the lack of emulation time. That was one of the first things I added to blueMSX when it still was an fMSX clone. Another quite big limitation is that the code is very static and unstructured which makes it hard to support new hardware, especially if its optional.
  What I like with the fMSX portability is that the core is just plain ansi-c and only depend on standard c libraries.
  And don't forget fMSX'es fully fledged debugger Is that one available in fMSX/MAC as well?
  20-04-2006, 01:16
  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.
  it's not the same, but for the record: I'm quite proud that openMSX runs on practically any system nowadays. OS's like: Linux, Windows, FreeBSD, OpenBSD, NetBSD, Mac OS X, but also architectures like: x86, MIPS and MIPSEL, PPC (incl PPC64), AMD64, alpha, ARM, HPPA, IA64, S390, SPARC. This gives the idea that it should work on about any system one can imagine. The funniest one was the HP Jornada handheld PC (running Debian Linux on ARM), which karloch reported a few weeks ago.
  Especially with mth's enhanced 3rd party build stuff, it should be a breeze to port openMSX to any system. So, emulator developers: please do not reinvent the wheel, but use openMSX as a base (or better: directly) for your new emulator on some obscure platform!
  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.
  Why wouldn't he simply adjust the openMSX code to work with patched BIOS'es to support CAS files directly? That would be far less work than writing your own emulator or working on something much less advanced as fMSX... After all, the source is fully and freely available. And this person can benefit from all new developments on openMSX!
  Really, if this would be a reason, I wouldn't understand it.
  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.
  Well, if there's any such developer, please tell us what the problems are, the chances are greater that we can fix them together in openMSX than that you will be able to reach the state of openMSX in a short time. We'd appreciate the feedback at least!
  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.
  Small sidenote, concerning fMSX: in my Pentium 166 era I used fMSX/DOS a lot. I thought of it as it being quite a good emulator. Several games, like Realms of Adventure, the Lost World, etc, ran fine on it!
  You don't have a good quality of sound in fMSX/DOS, but maybe it does not matter for you
  24-04-2006, 01:07
  Yeah, the sound in the original fMSX is not that good. Seems like most ports are improving the sound emulation as one of the first things. All clones I've tried has made quite a few improvments on the sound, like paramsx, redmsx and fmsx-sdl