As of MESS SVN revision 15179 the UME (Universal Machine Emulator, aka combined binary) target is present in the MESS SVN tree
(mirrored on the GIT too)
This target can be built using the command
make TARGET=ume
(or make -j6 TARGET=ume if you want to use more cores when compiling)
Hopefully people will remain open minded about this target, and it doesn’t become some sort of taboo subject.
There might still be some issues with building the tools which need cleaning up (windows specific hacks which things like wimgtool depend on, but exist only in MESS) but as far as a working combined binary goes you should be good to go with that.
As I’ve stated I will provide these binaries for the next major release synced to the point of whichever release comes last (MAME/MESS) (the projects are usually synced at each others release points anyway)
For day-to-day use the MESS tree isn’t 100% synced with the latest MAME developments, but usually gets synced up within a day or two, so it isn’t usually an issue. There will be an eventual move to a new server where development of both projects will take place, and I’d assume the target will be carried over when that happens.
As I’ve stated elsewhere the main advantage of this solution is convenience, if you’re running MAME anyway you may as well be using UME instead. That way if you ever get curious about how something else runs on one of the consoles, or just use the project to it’s full potential then you have that option already at your fingertips. The quality of the MAME emulation is the same as always, and the integrated MESS emulation provides a ‘good enough’ solution for many computers / consoles which could save countless hours in setting up and learning a completely different emulator if all you want to do is quickly test something in a familiar environment. I’m not going to lie and say MESS / UME is currently better than the standalone emulators, but it can be a heck of a lot more convenient if you’re already familiar with MAME and don’t need all the bells & whistles offered elsewhere.
I hope this does eventually increase exposure to the MESS codebase for people who might have been weary to try MESS otherwise, I fully understand that not many people are going to want to actively search out MESS on it’s own, but if you already have the code in the binary you’re using anyway there is nothing to lose by trying it as a first option and in many cases it will be just fine. Obviously having it as an alternative build doesn’t quite have the same impact as having it as the main build, but hopefully people will see that they have nothing to lose by building this target, even if you just ignore the MESS side of it completely!
I’m assured by various people that proper support in the QMC2 frontend will be available with the next major release too, so again that’s one reason I’m not supplying binaries yet, although I imagine the QMC author can take the addition to the MESS tree as a sign that the UME name / configuration is final now and put something out :-)
Personally I find it pretty cool to know that I can run the Genesis version of Sonic using the exact same codepaths in the emulator as the Megatech version (just sans the annoying menu), and in addition to that use the very same code to run the majority of the Genesis library rather well. Likewise I can compare ports easily, and really have a whole new world to explore without leaving the confines of the emulator. It’s also good for seeing how solid the emulation code used for a number of MAME systems is when exposed to a larger software library, and thus building (or destroying!) confidence in the accuracy levels of MAME for those systems or understanding how well the Arcade games on the platform actually utilized the hardware compared to the more general software library. It’s an adventure of knowledge and new discovery.
As I said, I’m not posting binaries yet, although I won’t stop people posting them! (I’d love to see others taking the idea and running with it) but this is just a heads up to the ongoing progress really.
I’d like to thank Micko (current head co-ordinator of both MAME and MESS) for checking in the target (and in fact being responsible for the code which has allowed this 100% clean solution in the first place) I hope people enjoy it and make use of it.
For another example of where the MAME/MESS crossover looks like it’s potentially going to be interesting (from the perspective of somebody studying the hardware) I think it’s also worth mentioning this.
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=286469
Parduz here asked for help understanding the Ensoniq SQ-1 synth, a target for MESS.
As it turns out, if you read R.Belmonts post this is clearly the system and codebase Taito took and used as the basis for all their Ensoniq sound systems (F3 system and up)
So (once the work is done) you’ll be able to see both sides of the same coin in a combined binary, which personally I think is rather neat.
I hope I’ll eventually make it to some “thanks”, only because of the push I generate in all directions. :P (QMC2 included, the feature request is mine, the author didn’t plan to check UME any time soon after some compile failures with older builds, until I… pushed)
Anyway. Hope it makes it to MAME SVN too? (and actually both SVN become one)
Keep up the good work man.
It can’t make it to MAME SVN because the MESS code isn’t in there to begin with.
The MESS SVN has always had both because it depends on parts of MAME.
The roadmap is for a new SVN anyway which will need both projects in there if the developers are to work together. Once that’s done you’ll have the latest version of both projects when you compile the combined build. I’m kinda surprised they didn’t just migrate everybody to the current MESS one, but as long as development retains the openness of the MESS system it should be fine :-)
As predicted…
Congrats to you Haze, and many thanks of course to Micko!
Very soon you won’t have to compile UME any more Haze…it will be done by others as a natural course.
@NLS: “Yeah, I’m aware of UltimateMAME and Haze of course :). I’ve been asked by another person before and looked into it…”
Guess who the other person was (that beat you by a month)?
Excellent progress, another step in ultimate machine emulation — wonderful news! Open source, open development, open minds, progress AND posterity. Onward.
I only used MESS once years ago for the Kaypro II emulation before MAME’s license was added/changed. Does MESS have the same license?
Congratulations!, I have no doubts this is the way forward.
@Moo: yeah, MESS uses identical license as MAME. does this harm you as a user?
also you might want to notice that some progress on the Kaypro have been done in the past two years, thanks to the work by Curt Coder and Robbbert (among other things, MESS does not use anymore the hacked DOS it used previously), in case you want to give it another try.
@Huggybaby dammit :P
Doesn’t hurt me at all. I was just curious.
Now let’s all sing “We are the world”… :D :D :D
Great news. Can’t wait to compile it tonight.
Thank you Haze,Micko,etabeta and all other devs and contributors.Haze does mess going to emulate and general eletronics one day as tv’s,dvd players,and everything with cpu and display? I am asking as is there need to keep that stuff so one day get dumped.
Yes, Mess is ‘anything goes’, and if it can be emulated, it will be emulated as long as there is interest in emulating it.
That’s why ultimately MESS will be the longer lasting project, and the basis of why I think they should merge anyway. MAME has a very limited scope, and once the remaining arcade tasks become too difficult is highly likely to become an inactive project. At that point MESS will probably have to absorb MAME just to keep it alive and maintained at all, but I’d rather see things go the other way while MAME still has some momentum. Keep the MAME name and established reputation alive, albeit under an expanded scope, much like Multipac ended up being expanded into MAME.
One thing that is worth fixing immediately is all the wrong flags…fix those and Robert’s build becomes very desirable.
So what can be done to expedite flag fixing? Is it something a script could handle, or is plain grunt work needed?
Flags are down to personal opinion and usually set by whoever wrote the driver.
I don’t want to unflag SegaCD because while a significant number of games work fine, some important ones don’t.
Likewise flags in MAME (Imperfect Graphics etc.) tend to be set based on the overall hardware emulation, not specific game emulation, so some games end up flagged even if the games don’t (to our knowledge) use the features which aren’t perfect because they potentially could.
I don’t mind this situation, it makes it more difficult for people to sell unauthorized MAME bootlegs simply by applying a filter to the game lists.
btw, the Git is down right now, looks like the server crashed ;-)
Well,great news! what are the remaining arcade tasks become too difficult,can you post the remaining left Mame work?
“I don’t mind this situation, it makes it more difficult for people to sell unauthorized MAME bootlegs simply by applying a filter to the game lists.”
Yeah, but…unlikely it makes any difference in the end.
So, flags aren’t applied by game, but by system? I sense room for improvement then.
there are two levels of flags:
– the system flags which depend on the overall status of the emulation (so e.g. SNES is marked as imperfect graphics and not as not working)
– the softlist flags which depend on the specific emulation status of the specific game considered (so e.g. SNES games using SA-1 are marked as not working because the additional CPU is not emulated)
they work pretty well, in fact…
again it depends on author, at least in MESS, I believe ALL playstation based stuff is flagged, even if some of it is probably fine (or at least was before that recent regression) You could argue it’s perfectly fine to have stuff flagged anyway, the dither patterns etc. aren’t perfect apparently, althouh you’d never know it.
Some drivers are flagged for imperfect graphics per-game instead..
I think that the driver should “reverse inherit” the status of the games, so if there is any game marked with imperfect graphics, the driver should be marked as imperfect graphics.
If there is no per game flags but it’s known that some games have imperfect graphics, the driver should be marked as such, even if the majority work fine.
the situation is more complex tho, take NES for example, you could perfectly emulate the base hardware, but because (almost) every game depends on custom hardware in the cartridges your compatibility would vary anyway.
that’s why I say it’s down to the authors to use common sense, the flags are about how much an author trusts their driver as much as anything else.
Compiled it yesterday on Kubuntu 12.04. Works fine, except that it tends to crash the X server a lot and it’s the only application to do so. Upgraded to newer drivers, it doesn’t crash anymore but seriously messes up window management after a while :/ I also noticed that loading 7zipped mess roms without using a softlist (for example ume nes -cart /Games/Super Mario Bros.7z returns the error ‘Device Cartslot load failed: Unspecified error’. And Seibu SPI sound is messed up in the sense that only one channel is played back. I’m by no means saying this is your fault or your responsability to fix it :) I’m just wondering if these problems are known, and if not, whether I should report them. I googled for a bit and can’t find any relevant information. UME is the way forward.
Yeah, nobody added the 7z support to the non-softlist loading, so it won’t recognize a .7z and doesn’t know how to handle it. Unless the code is terribly contrived I imagine it will be a simple fix tho, surprised nobody has done it MESS-side tbh.
For your X Server errors etc. do they happen with regular builds? I’m not really familiar with the SDL codepaths but there’s nothing about the build which should be acting any differently to a regular MAME/MESS compile as far as those areas of the code go. Likewise SPI sound won’t be running any different code in your build to any other, if you’re building over an old tree / sources you might want to clear the NVRAM folder and let it reflash the roms if you didn’t do that? SPI sound definitely works on Windows.
It would definitely be worth your time testing the issues in a regular build, at least after the next ‘u’ release (things are a little unstable in general at the moment)
I did try removing the NVRAM for Raiden Fighters and reflashed before posting, but the problem remains.
I did compile using the archopts=-march=core2 -mtune=generic -mssse3 -mfpmath=sse optimization flags – maybe they’re the cause? I’m going to try a sdlmame4ubuntu build to see if I get the same errors.
Thanks for the tip.
I just came to say hello. :)
It might be your compile options (or even toolchain) yes especially the X server issues you talk about.
First I’d also check your .cfg files for the SPI games to make sure they haven’t been invalidated by a new version, there have been a lot of changes to the port handling, which could easily throw off reading of .cfg files and cause it to read 0 values for volume settings etc. (Ideally you should probably just run this in a clean folder if you’re not already, MAME gives no guarantee of user file compatibility across versions and many recent u versions have been unstable which is why I haven’t been putting out binaries)
The Windows toolchain is being bumped to a newer version more inline with many of the linux distros in the next release (u update or full release I’m not sure) but I’m already using that for testing.
Anyway I suggest not deviating too far from whatever the SDLMame defaults are otherwise you’ll send RB cranky even if you do use a standard build.
looks like the mess zip handling code is quite complex actually, lots of stuff duplicated from elsewhere.
could probably do with a ‘compressed file’ abstraction rather than calling zip specific functions directly. that would also make it easier to add other formats too.
I hadn’t noticed it before because I’ve only been using it on a machine with more limited space where I just have some MAME stuff.
Well, the UME target is definitely such a cool thing we couldn’t wait for the next official release to build a combined MAME/MESS binary with the GroovyMAME patch. Amazingly the existing patch needed no modification at all, it just compiled like a charm:
http://forum.arcadecontrols.com/index.php?topic=120331.0
Now we can benefit from automatic modeline generation and improved synchronizing options in GroovyMAME for console games too.
Great let’s start the avalanche.
greetings
I’m going to wait until the next stable release is out, then compile that without optimization flags. At any rate, it’s great to see that your work is being taken seriously now that there’s an official target.
with git up again, I was able to grab the latest source but unfortunately when compiling I got:
src/mame/video/bfm_dm01.c: In function ‘void mux_w(address_space*, offs_t, UINT8)’:
src/mame/video/bfm_dm01.c:149:10: error: variable ‘pos’ set but not used [-Werror=unused-but-set-variable]
cc1plus: all warnings being treated as errors
I’m using Ubuntu 12.04 64bit. Looks like I’ll have to wait a little longer. (I was able to compile the regular MESS and MAME target on May 11)
yeah, just remove -werror from the makefile, some of the devs aren’t using the latest toolchain which is a little more strict about certain things. the warning is harmless.
@Calamity: if you use clrmame to rename your roms according to software lists shortnames, then you can simplify the loading command to
mess megadriv -cart sonic
or
mess megadriv sonic
this can make the difference for some systems. e.g. if you have atari lynx games with headers (which are not recognized by software lists) you have to use fullpath launching; if you have atari lynx games without headers (the ones recognized in software lists) you have to use the shortname only without the path, or the loading code won’t be able to load the game properly due to the lack of header info.
Right 0.146 is out now, not at home currenly but will compile UME builds later.
Doesn’t look like the CHDMAN random hang on HDD conversions issue was fixed for 0.146, nor a number of the other bugs introduced in the cycle, but given I said I’d do a build synced to the release I’ll keep my word on that.
Compiling now on Kubuntu 12.04 32bit. It’s so cool to that UME is now being accepted by the mainstream MAME community. Concerning the X.org issues I was having with the prior build, I’m almost sure that it’s not MAME’s fault since OpenGL screensavers trigger similar problems.