[Image]UME v0.146 is released. UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

As of 0.146 the UME target is officially provided in the MESS development tree, however the teams have opted at this time to not supply binaries of the build on the official site(s) so instead I’m supplying them here and dealing with support for them.

The builds here are produced using unmodified code from the MESS SVN repository which contains the latest code for both the MAME and MESS projects. As part of the unification the teams will be moving to a single shared SVN in the near future, although the projects will still maintain their separate identities and distributions, including this one, the UME build.

For the end-user UME allows a user to unleash the full potential of both the MAME and MESS projects from within a single convenient environment, using common configurations. It is designed to demonstrate how close the projects already are while providing an introduction to MESS and how some more advanced features of the project which MAME doesn’t utilize directly are used.

Why Should I Use UME instead of a regular MAME/MESS build?

No functionality from regular builds has been removed, so even if you don’t make use of any of the additional functionality you’re not losing out by using UME instead of a single project. Beyond that you have access to a whole new sub-set of platforms. For example you can quickly launch either the standard NES version of Super Mario Bros. the Playchoice 10 version, or the VS. System version using the same application which you’ve already set up and configured. The main added factor is convenience.

From a development perspective you have instant access to the components which exist in both projects without having to move code around if you’re simply interested in doing some quick tests. You also have access to a more flexible range of software and test cases for common components within a single project as well as a greater level of awareness over component reuse between the projects. This should allow for greater testing of code and hopefully reduce the chances of accidental duplication.

Why Should I Use UME instead of MESSUNI (another recent combined build)?

MESSUNI is what I like to call a discriminatory build. It is billed as a combined binary, but actually strips a large amount of both projects out merely based on flags and personal preference of the developer. Any seasoned MAME or MESS user will tell you that there are many things flagged which are actually usable to a good degree because flags are often used as a precautionary measure, especially in MESS where you have systems where several hundred games may function correctly on a system, but likewise many may not, so the flags remain.

Furthermore MESSUNI is built on the MESSUI code, which in turn is based on the legacy MAMEUI code. I’m aware that this is preferential to people over the commandline but the code has been rotting for years and introduces numerous stability and usability issues which will degrade the overall experience of using either MAME, MESS, or a combined build. The current recommended way to use the emulators is with the QMC2 frontend, which should support the UME build shortly.

What’s New in UME?

UME 0.146 contains *everything* from MAME 0.146 and *everything* from MESS 0.146 please refer to the relevant what’s new lists for each project.

To be more specific it’s based on MESS SVN 15264, which is slightly newer but adds a fix which allows the tools to compile without error.

Everything?

Ideally everything, yes, although due to an oversight the megatech.xml and stv.xml software lists from MAME are not in the MESS SVN tree despite being in shared folders so are currently absent. That isn’t an issue however because the primary method of launching these is with the internal setlists anyway. This will most likely be resolved once the official development teams are sharing an SVN.

When Shouldn’t I Use UME?

UME shouldn’t be used for reporting things to Mametesters, doing so will result in lots of angry developers chasing you with cattle prods. If you encounter a bug in UME you should verify that it occurs in a regular build too. There is no reason why a bug should be specific to UME, but it makes sense to check first.

Future Plans for UME?

I’ll make an effort to put out a build for each ‘u’ release (as long as I feel the overall ‘u’ release is stable enough) as well as each final release (which should be stable..) People are welcome to compile and post their own builds, especially for non-Windows platforms as I’m unable to supply those myself.

Anything Else?

I’m currently undecided over setting up a new sub-page for UME builds, or just posting them as part of the regular news stream here.

Download: UME v0.146
Source: Here