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 an end user this means that the software provided here is not only capable of emulating arcade machines like the baseline versions of MAME, but in addition can emulate a large number of home computers and consoles from across the world using the very same code, developed by the very same team of developers.
What’s New
You can read the various whatsnew files on mamedev.org
From MAME, From MESS
UME binaries (Windows)
0.149u1 UME Windows binaries (32-bit and 64-bit) (Self Extracting 7-zip) (all MAME / MESS tools included, both 32-bit and 64-bit versions in tool32/tools64)
The source is identical to that found on mamedev.org (SVN revision SVN 24476/ 0.149u1)
Non-UME binaries (Windows)
In addition to providing the UME binaries I’ve also included a package with the individual legacy MAME/MESS executables as an option. Personally I prefer the everything under one exe UME solution but I’ve noticed it’s not always easy to find binaries of the regular u builds with them not being offered from the official site so this is my attempt to address that.
0.149u1 MAME/MESS Windows binaries (32-bit and 64-bit) (Self Extracting 7-zip) (UME above is more highly recommended)
Latest U release binaries for UME, as well as MAME & MESS can also always be found on the page linked in the box on the left
These binaries are coming from Mamedev (me) so are as official as you’re going to get for a u update.
Points of Interest
In addition the everything mentioned in the last 2 posts here there have been a number of other changes, I’ll cover some of the highlights here.
One thing I forgot to mention in the previous post is that hap improved collisions in Birdie King 2, another one of the long-standing games marked as working, but with such severe issues you’d probably be right for thinking it was a mistake.
(more)
Now with NES Power Glove emulation… for the truly masochistic! LOL
“-chdman: -c would only overwrite the amount of compressions defined –
part of the default compressions might still have been used
[Oliver Stöneberg]”
Do you know what the story is with this?
You can specify up to 4 different compressions for a CHD. There are also default compressions for certain types. HDDs for instance use lzma, zlib, huff and flac by default. If you specified “-c lzma” it would only overwrite the first of the default compressions and still use the three others, although it was supposed to only use the one specified.
Oh, I see. OK thank you.
(sorry for the lack of updates, actual mame work comes first, post updates when I have free time and I’ve been experimenting with a few things over the last few days ;-)
Welp. Another report. Fortunately, recent MAME Plus compiles are now basically UME Plus, and whatever the difference in compilers is, it kinda sorta fixes the rendering problem. So for i945g (and similar) users that prefer/need d3d9 mode, use MAME Plus and wined3d wrapper.
* Pokecard(u) sound is too slow on gbcolor. This is a very odd glitch as it doesn’t affect supergb or other gbcolor games.
* PCE is still massively regressed. Sound channels are missing on PCECD games (and maybe others, see avgeo) and the speed hit of the pcecd rearrangement is still epic. And not that it ever really worked, gecd is now completely broken.
* For the heck of it, another PSX bug report because I found two games that MAY have a related bug. Advanced Variable Geo (1) cannot interact with the memory card. Fighting Force 2 will not finish loading after it attempts to load from the memory card. I have no clue if it’s the same problem, but whatever.
Yeah PCE CD seems to be a complete and utter disaster at the moment, which is a shame because it used to be pretty good.
@Haze: complete and utter disaster? I tested extensively a dozen of games and they seemed to worked
it’s the first time I hear about any regression, so if it was so well known you could have reported it to Mametesters before…
I will look into it asap
Well when you drag performance down like that for no gain (video rewrite is understandable and acceptable, slot performance penalties are not) hurt usability, and introduce new bugs then yes, I’ll say it’s a disaster.
It chips away at the cases where I can recommend MESS / UME as a good emulator. Unfortunately there are quite a few significant ones where MESS really did used to be better than it is now. (X68k is of course the major one)
@etabeta: I don’t exactly have access to fantastic hardware right now, but the speed penalty making pcecd its own device is easily -50% machine speed (used to be ~140% with throttle, now ~90%). I don’t think it’s unfair to be disappointed with that.
pce still has ioport() lookups, which could be cached. A DEBUG build is also extremely hurt by the huge amount of dynamic_cast calls (lookout for FASTDEBUG soon). After disabling those most of the time is spent in the call
m_pixel_data = m_get_next_pixel_data( 0, 0xffff );
in
huc6260_device::device_timer()
Big offender in that call is devcb_stub16(). So it doesn’t really look slot-related to me.
well the video code did cause a big speed hit, yes*, but all the slot converted drivers too another one due to the memory system, and apparently for PCE it was very significant too.
* because of the way PCE mixes the video and resolutions everything has to be scaled up to a much higher resolution in software now, which isn’t fast. PCFX will be worse because you can mix layers of different resolution on the same scanline (!)
Well – it might be the impression, but the profiler says otherwise. It’s the devcb lookup what make it slow. And even without dynamic_cast dozens of millions of downcasts calls affect speed a tiny bit.
Well whatever happens it needs fixing, if it’s a design issue / flaw / whatever that still applies because a ton of CPU time is clearly being spent doing non-emulation things and it did get worse last time it was touched during the slot conversion like many of the others. (SNES took a hit during slot conversion too for example)
It’s worrying, because these are our flagship drivers.
The “problem” are the delegates, memory system and timers – so you need a different framework.
and if that’s how things have been designed then IMHO it’s bad design, so moving things towards a system where they end up being crippled by the framework is a bad thing and we’ll end up spending years undoing it all later.
if your framework / engine cripples performance, then it needs a rethink, this has only become a severe problem recently with the ‘modernizations’ etc. no point in having something perfectly clean and pretty from an architectural point of view if it fails miserably to deliver in terms of performance and usability in the final product.
we are at a point where we can’t rely on actual CPUs improving in any meaningful way, and have been for several years now (the new CPUs are better but even a brand new CPU isn’t a huge leap from my 5 year old one) therefore degrading things to borderline performance levels is going to do more harm than good. It comes down to us to write better code, have a better overall design, and see what impact changes like the ones made are going to have before we commit to them.
So yes it is a problem not a ‘problem’ although I hope you were profiling with GCC in a regular build because Aaron has clearly stated that the delegates etc. are very much optimized with special cases specifically for GCC and nothing else, so they will skew your profiling results significantly otherwise. (this is why VCC, Clang, Intel Compiler etc. builds are a good 20% slower than GCC ones anyway)
and yes, these performance drops for no gain are a problem not a ‘problem’ and saying they’re only a ‘problem’ comes across as very arrogant.