UME is the complete/combined version of the MAME / MESS project.
Official whatsnew texts for (MAME, MESS) provide full details of what has changed since 0.155.
This is the 2nd official release since the official source repository was moved to GitHub, it is based on the official ‘mame0156’ tagged version (or in GIT hash version nonsense, ebeaa953a3a6ae98842b4a169bc95e5f3c673d8c )
UME 0.156 Windows binaries – 32-bit, 64-bit and all tools
(source matches official mamedev.org source distribution, here for completeness)
Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.156 Windows binaries – 32-bit, 64-bit and all tools
Points of Interest
-will write it later
Like!
I have a doubt. I don’t know if that was been asked before or not, but…
Why UME binaries aren’t distributed in MAME official website (http://mamedev.org/) the same way that MAME and MESS have been released?
I know and like that UME is distributed in your website, but certainly UME binaries would gain yet more visibility, at least with people that aren’t familiar with compiling by themselves.
That said, I’m seriously thinking of stop compiling by myself and only download the binaries, so long for now on there will be a new official compilation every month \o/
(unless this rule doen’t apply for UME. I can’t use MAME alone anymore since UME comes to surface and GUIs such QMC2 brought support for it :p )
@Shideravan
If i remember correctly, there was lots of debate whether UME should even exist. I believe that having UME as a build target only was one of the only things they could all agree on.
If anyone from the MESS/UME team could chime in on this.
So far, I like the current status of MESS. I think everything up to the SNES era has very strong emulation that is capable enough for your average retro gaming fan. With that said however, I can never understand why they don’t include native ISO support for systems like SegaCD and Turbo Grafx CD. MESS can play native rom dump images but it seems that MESS is still stuck with MAME’s proprietary CHD format. Why is that? It’s more of a morbid curiosity of mine.
should have a .sta converter between ume versions
@CPZ: you can already perform your tests with bin+cue images… just launch “mess segacd -cdrm C:\path\to\SCD\games\XXXX.cue”
for real documentation we prefer to stick to chd, though. it’s a format which requires some extension to cover weird disks like PCECD and NEOGEOCD, but it’s in principle a better choice than current variety of solutions
Check again, we do support ISO files.
I’m not one from the MAME/MESS/UME team, but I can tell you that MESS does in fact have support for BIN/CUE/ISO
Here are a few examples.
mess64.exe -rompath “J:\MESS\roms” -hashpath “J:\MESS\hash” -samplepath “J:\MESS\samples” fmtmarty -cdrom “J:\Raiden Trad [Raiden Densetsu].cue”
mess64 pce -cart scdsys -cdrm “D:\PCE torrent\Akumajou Dracula X – Chi no Rondo (SCD)(JPN)\Akumajou Dracula X – Chi no Rondo (SCD)(JPN).cue”
mess64.exe -rompath “J:\MESS\roms” -hashpath “J:\MESS\hash” -samplepath “J:\MESS\samples” saturn -cdrom “J:\Virtua Fighter (USA) (DW0657).cue”
mess64.exe -rompath “J:\MESS\roms” -hashpath “J:\MESS\hash” psu -mc1 “J:\MESS\software\psu\card1.mc” -cdrom “J:\Castlevania – Symphony of the Night (USA).cue”
Converting Save States between versions simply isn’t going to work well, I do think we should change the format a bit, and make a ‘best effort’ to load things (sometimes things are added to a class / state that really aren’t going to matter for one game and a warning, rather than failure would suffice) however if the format does change it will invalidate everything again.
Thanks everyone. And here i was all this time converting them to CHD just to do test runs.
yeah, as others have said, you can use .cue / .bin directly in most cases, it will use the same parsing code as when it converts to CHD (so you’ll get the same limitations of CHD format eg. no multisession etc.) but without compressing it.
the Software Lists list are CHDs because CHDs are a more ‘secure’ format in the sense that they contain their own checksum and so can be verified (with CHDMAN) to ensure they haven’t become corrupted, also if they do become corrupted you’ll get a decompression error and the emulator will fail rather than silently reading the wrong data.
CD ripping and bin/cue parsing are a messy business tho, our CD support is definitely an area of MAME/MESS that needs review, different ripping software etc. interprets the .cue/.bin specs in different ways, often ending up producing files with wrong gaps etc. which then translates to hacks in the emulation. I’m almost certain a lot of our CHDs are badly converted as a result of things like this, especially in cases where the original system copy protections mess with the gap sizes. Worse still some PC cd drives attempt to correct them, further adding to the problem, and it seems like some dumping groups probably settled on bad settings that had already been ‘corrected’ in the past*. (that’s one reason while even if we do allow image files other than CHD supporting reading direct from the CD drive is out of the question, you’re simply not going to get the same results between machines)
* the PCE list is very suspicious for this reason, also NeoCD still needs some ugly hacks. The Saturn list contains discs from multiple sources, some of which work / don’t work depending on how we tweak things, clearly one copy of each image is the bad one. It’ll all be sorted out and considered ‘mature’ eventually, but when I don’t know.