Ultimate MAME v0.144

Ultimate MAME v0.144 is released. Ultimate MAME is a compilation of MAME and MESS.

MESS is MAME, I’ve made this point before. The functionality found in MESS, the ability to run console / computer based software can easily be added to MAME. There has been talk of doing this officially for a while now, but every attempt is met by too many opinions, too many people trying to overcomplicate the process, and too much focus on offering LESS functionality to the end user and requiring MORE code to get there. As a result nothing ever actually happens. There are some devs saying they’ll quit the scene if it ever happens, contribute nothing more, there are people who really don’t seem to want to allow this functionality in MAME, even if there is no cost at all to having it, and a huge number of benefits in terms of testing, unified development and a cleaner source tree. The most elegant solution to this problem is also the simplest one, and that is to wipe from your mind any concept that a system having a coin slot is a valid criteria for division, and simply treat the source trees as if that were the case. The current MAME source structure has 2 main emulation sub-folders emu – all common off-the-shelf, non system specific components go here mame – all custom chips and system emulations go here Inside each of these is currently a tree structure of drivers, video implementations, machine implementations, audio system implementations etc. By default the mess project adds a further folder, ‘mess’ for non-arcade systems. On the surface that might seem like sound logic, but in reality it just creates uncertainty over where to look for files. By logic you’d probably expect to see video/n64.c in the /mess folder. N64 was a home console, but in reality it exists in the /mame folder, because it’s a custom component emulation which is also used by arcade games. Proposals have been put forward to maybe create a 4th folder when merging the projects ‘shared’ but all that would achieve is bumping having 2 places to look for files right up to 4, and you’d still need prior knowledge that a system was shared between arcade / home use to even think about looking there. Essentially the existing structure MAME already has is still the best, 2 places, making it obvious where to look. The most logical way to merge things would be to just move the MESS files into those folders, which, if you’re saying the coin / no-coin criteria doesn’t matter also makes the most sense. The other argument people keep putting forward is that whatever system is created it should still allow the creation of MAME and MESS executables with ‘combined’ simply being another build target. This just seems to be avoiding the benefits of merging altogether. One of the big benefits of combining the projects is that in a default build every file gets built. When you’re dealing with a large number of cross-project shared files this makes the most sense, right now it’s very easy to break the MAME compile with changes in MESS (or vice versa) simply by not knowing that code was used in both. If all the dependencies are being built by default that simply can’t happen, in addition, you’re more likely to know where things are used for better testing of the actual emulation effects of any changes you do make. Creating an additional build target is again just more work, and ultimately offers less benefits, tiny builds of mame/mess specific stuff will always be possible with tiny.mak, but beyond that are unnecessary. Unsurprisingly, the easiest way to merge is to just keep the existing MAME target and integrate the MESS stuff into it, which again gives you the most benefits for the least amount of work. So what’s the problem? Others have claimed that the work will take a significant amount of time, needs to be carefully planned, but again this just seems like stalling. Due to the size of the change and rapid daily changes which occur in both projects, it’s not really something you can take a significant amount of time over, it’s something which needs to be done in one swift action, and worked further on from there in order to keep everybody in sync. In reality, it’s not a change which takes long to implement, at least not if you keep it simple. It takes about 2 hours if doing it from scratch, working out the modifications you need to make, working out where the conflicts between the project are and other such bits and pieces. The other issues put forward against doing it the simple way are things like breakage of Save States due to MESS using a different signature, but that’s to be expected, and the signature issue could be resolved easily anyway. Given how often states break anyway I doubt many people keep them around. More action, less talk is apparently the message coming from MAMEdev these days, and despite writing a lot that’s something I believe in, the whole concept of ‘if you want something doing, do it yourself’ is what has kept a lot of MAME development going over the years. With that in mind I’ve created a guide to creating an Ultimate MAME Build, one with MAME and MESS combined. With this setup you can run anything from MESS in MAME, it ‘just works’, it’s wonderful. I can launch Megatech, or, if I don’t want the timer crippling the software, I can launch the standard Genesis versions. SNES, NES, PCE, Neogeo AES, NeoGeoPocket, you name it, it’s there, in MAME, working with the support from MESS. Want to see what state the PSX and Saturn are in? You can do that too, it sheds plenty of light on the work needed on those MAME drivers which you otherwise don’t see. I know not everybody is going to want to follow that guide.. so.. introducing —- ULTIMATE MAME 0.144 —- The only real difference with the MESS stuff compared to what you’re used to with MAME is the launch syntax, as the majority of MESS systems use Software Lists instead of the internal Database, but as discussed in the previous post here, such support is needed for MAME and Multislot support anyway, so those on the ball won’t find it to be anything new. “MAME genesis sonic” (or “MAME genesis -cart sonic”) will launch Sonic for the Genesis / Megadrive some systems are a bit more complex, for example PCECD “MAME pce -cart scdsys -cdrom draculax” would launch Dracula X for the PCE-CD. The syntax is more complex because that’s just how the system works. for regular MAME stuff everything works just as it did before “MAME pacman” will still launch pacman There is absolutely no loss in functionality. All in all it’s very easy to use, and having that functionality and code within the same project as MAME is invaluable for developemnt and testing alike. I just hope something like this is integrated officially sooner rather than later, because it will make working on heavily shared systems a lot easier and no doubt lead to many more bugs in MAME being quashed as the MESS drivers expose them. I will give on word of warning. The ClrMAME support for the Software Lists is a bit flaky at the moment for users of that, they can still be imported however, and there is talk of integrating the lists into the -listXML output too. Some MAME frontends may struggle, but QMC should work because it’s been developed to the higher MESS standards already. Anyway, in conclusion, I’ve always tried to push for progress, always put my money where my mouth is when it comes to such things, that’s exactly what this is here. I just hope that people do eventually start to see that this solution, which is by far the easiest solution, is also in many ways the most logical solution with the least complications and most benefits. This isn’t something that needs months and months of debate which ultimately end up nowhere, it’s just something which initially needs doing in one single operation, as soon as possible, with a level of commitment which means people will accept it and move forwards and work on any issues which arise from there otherwise it simply won’t get done as the last few years have shown.

Download: Ultimate MAME 0.144 x86
Download: Ultimate MAME 0.144 x64
Download: Ultimate MAME 0.144 Source
Source:Here