This emulator is capable to copy the Sega Master System and its other version, the Sega Game Gear. It is able to emulate other Sega versions like the Sega-CD, Sega Game Gear, Sega 32x adds-ons, SG-1000, SC-3000, and the Sega Pico. It emulates the Sega Mega Drive, which is otherwise referred to as the Sega Genesis, under Intel Macs. It is licensed through GPL and its source code is already included in the download. It runs in Mac OS X with great portability and accuracy. So porting vs rewriting is I guess a matter of taste and what the goal with the project is.This emulator is capable to emulate SG-1000 and Game Gear. 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 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.īut if the goal is to get an emulator running on a new system, porting openMSX sounds a lot easier than rewriting everything. 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. 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. I plan to do a linux version with only the core some day but I'm out of spare time atm. That would be similar to port fMSX though so all gui, audio and input needs to be rewritten. The emulator core is written in plain C/C++ with a nice and clean interface and only depends on standard libraries. It will be based on the Makefile that creates the static libraries for the OS X binary.įor developers that wants a good MSX core but want to develop their own gui, I can also recommend blueMSX. I want to create a Makefile that (cross) compiles all libraries needed for openMSX, so porting becomes almost automatic. 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. But now that GCC is available everywhere, this is less of an issue.įor the libraries, I don't think the portability itself is an issue there. 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++. This works very well in practice, so we didn't want to reinvent the wheel. 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. 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. 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. 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. Whether fMSX or openMSX is easier to port depends on your point of view. 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. 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). However, there are certain limitations in the design of fMSX that are impossible to overcome without major changes. fMSX got me interested in MSX emulation and it taught me how an emulator works. I think most openMSX developers have played with the fMSX code. 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.Īlthough we're not using fMSX code, we were influenced by fMSX a lot. 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. OpenMSX did not at any point contain fMSX code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |