UME is the complete/combined version of the MAME / MESS project.
Another unofficial update so soon? Why yes, that is what I’m announcing here. I did say I’d try and make sure people got new binaries for important bug fixes. In this case the Vector HLSL support has been fixed (by hap) over the last few days, and I consider that a worthwhile fix to put out a new build for the benefit of readers here.
Update 0.150×2, and it’s based off SVN revision 25563.
The changelog (simply a copy/paste of the SVN log) can be read here. This isn’t formatted as a whatsnew, but as usual I’ll summarize the main points below.
UME 0.150×2 Windows binaries – 32-bit, 64-bit and all tools
UME 0.150×2 sources
Points of Interest
As mentioned above the main reason I’m offering this the is fix for the vector HLSL that was made over the past few days. Other than that it’s only a minor update compared to the build put out just under a week ago; there have only been 63 SVN commits in that period.
This doesn’t fix the multi-screen problem with effects are used, but as vector HLSL is one of the recent ‘showcase’ features I feel it is still important progress on the road to getting things working. Unfortunately one of the showcase vector games, Tempest, still has emulation issues in current versions of MAME once you reach the later levels (the game resets) I suspect this is due to a flaw in the Atari Pokey emulation, possibly introduced when “Liberator” was fixed so the later levels worked there because that too uses the Pokey as a protection device and it’s possible there is some conflict in what they expect. Just a hunch, could be wrong.
Maybe the most important thing that has happened in this brief period is Couriersud returning to commit something. In this case the submission is only an optimization to the netlist emulation leading to a small performance improvement in the Pong simulation but the implications are greater. There are very few people involved with MAME who understand these old discrete logic games, I’d go as far as saying Couriersud is almost a one-man team as far as MAME work on them goes so his continued contributions are important if we’re to see progress in that area.
smf has also been tweaking the Playstation emulation a bit, fixing recent regressions in Tenkomori Shooting and Konami 80’s AC Special. Barry has continued to work on the Pinball drivers I mentioned in the 0.150×1 update.
The MESS side has also seen various misc fixes and additions, including work on the DECtalk ISA card for PC platforms and listing of some potentially useful disks etc. too. There was also a fix for loading tapes in the C64 driver thanks to a comprehensive bug report that made it relatively easy for Curt Coder to fix the issue. As always make sure to read the changelog because some of the systems / devices where changes have been made I’m simply not familiar enough with to write about.
Some CPUs were also modernized, I guess there’s a slight risk of breakage there (because any large scale refactor runs the risk of introducing some issues) For reference, the ‘NEC’ series CPUs are widely used in MAME, while the ‘Saturn’ CPU is not related to the Sega Saturn but instead a lesser known / more obscure system in MESS.
Personally I’ve been working with iq_132 on the PGM emulation, helping to improve the IGS025 / IGS022 emulation for Dragon World 3 / Dragon World 3 EX. iq_132 managed to get the games to enter gameplay with various improvements, while I implemented a missing DMA mode used to transfer some 68k code into RAM for execution as part of the copy protection. The emulation is still incomplete and the game will fail in certain situations e.g. when you continue, but it’s steady progress. I also refactored the emulation of these devices a bit to hopefully make it easier for iq_132 to hook them up in Luca’s igs017.c driver where 2 of the Mahjong game sets also use the 025/022 combo for protection.
Dragon World 3
Dragon World 3 EX
(iq_132 has been improving the PGM IGS025 / IGS022 protection emulation for Dragon World 3 with me providing some assistance, still not really working properly tho)
There’s also the fix I made for Thunder Dragon 2, mentioned in the a previous article here, and -mt was finally turned back off by default (although obviously if you have a config with it turned on, or turn it back on yourself you’re not going to see the benefit from it being disabled) both could be considered quite important improvements along with everything else I’ve mentioned.
Current State of MAME / MESS / UME
While current MAME & MESS builds are definitely good we’re still some way from having a perfect build. There are quite a few key MESS drivers (X68000 being a prime example) that used to work better a year or two back, although often because they relied on hacks. It’s a shame because if you want to use MESS it’s painful to go back that far because it’s only in more recent times that MESS has really started coming on leaps and bounds as a whole, even if it does have a long way to go. Likewise in MAME there are still some recent regressions that need nailing down such as the CoJag drivers not working properly. I’m not sure if these are another victim of the recent HDD changes or some modernizations. There was a fix to help with idle detection in the Jaguar DSP cores, but it doesn’t appear to improve the CoJag titles. Issues like the problems with the Mario discrete sound emulation are also starting to become worrying long-term regressions, likewise the Tempest bug I mentioned earlier. Things are however as a whole heading in the right direction.
you are almost a one-man team now as far as who understand ‘casual’ MAME users…i really miss old mamedevs (mish, dox, reip, acho..) who cared about ‘fun’ things…
Of course a vector HLSL fix is worth a new release, and any PGM progress is also very much welcomed, thanks Haze.
Yay! I can carry on working on retro-fitting my vector improvements to the new versions now. HLSL glow was the only thing missing (that I could never work out enough of to do).
Is not really working properly tho.
But is a good start.
Nice Job!
Its obvious
Haze is the longest Mame developer still here.
Haze knows what Mame must do.
Haze knows what we want to read
Haze knows what we want to see
Haze knows where Mame must go
Haze is the only developer that U N D E R S T A N D S
Haze is the only developer that cares
Haze is Mame
Mame is Haze
I don’t know where all this is coming from on a post about an unofficial update.
The u updates were scrapped because they were basically pointless at this point / not popular / didn’t radiate the desired level of trust due to them being seen as alpha / unstable releases which wasn’t really the case.
It’s not even like I’ve done much MAME work in this period. The only new progress I’ve even been involved with here is helping iq_132 with Dragon World, and typically when I’ve posted news about that kind of game in the past people have only been dismissive of it as being a waste of time.
People weren’t saying such things when I added all the Fruit Machine stuff either, and I’m still yet to finish that so it still sits there are a weight of unfinished drivers (bit disappointed new people haven’t started working on improving things there)
Likewise the developers of the project aren’t saying that about me wanting to do UME / turning our main project into a UME style one, it’s been branded as a trick, a way to force MESS code on people who don’t want it.. (I disagree, it’s just the natural course of progress, but whatever)
I just do what I feel needs doing, I’m not some kind of savior of the project, a fair amount of what I’ve worked on is unpopular in large circles (but my view has always been the 1% it appeals to will value it a lot more than the 99% who don’t care for it hate it)
Maybe this is just some kind of sarcastic troll? I don’t know.
Furthermore, not all the things I propose are ‘fun’ I’ve suggested in the past that maybe MAME should start documenting test software we’ve created ourselves, software designed to give immediate pass/fail results on various aspects of our emulation where we know the exact results on real hardware. That would have no ‘fun’ factor, but would immediately tell us if we’ve broken functionality somewhere without having to be good at the games (for example right now to trigger the Tempest bug you have to play it for a while, a simple series of pass/fail checks would be more useful) People who just want ‘fun’ would probably accuse me of clogging up MAME with such things, and saying that they shouldn’t be part of the project because they’re not arcade games, but surely if they’re integral to helping develop and test the emulator then they should be? Right now we don’t really have any polished software like that for any platforms anyway, most of the test software we’ve used is just quickly hacked together to test very specific things and provide feedback in ways probably only the original developer understands ;-)
You could definitely say I’m pushing for MAME to evolve, but a lot of that is pushing towards making it a much more serious, less ‘free game’ focused project some people see it as where the hardware emulator and technology we provide is undoubtedly the centerpiece. Part of this is in integrating MESS (my UME style vision) where there are hundreds of other types of system, many of which definitely couldn’t be branded ‘free games’, some with no real use at all (old terminals, eeprom programmers etc.) others that might help with genuine archival efforts outside of the project and have real value way beyond any notion of playing games. In part I feel this is essential for the long-term health of the project, because it shows that our intent really isn’t ‘free games’ but instead documenting and writing emulation cores for anything we can possible emulate (and if there was to ever be a legal challenge to the project I feel this would be important) Again, I wouldn’t really brand that ‘fun’ although personally I find it to be fascinating. Of course people who do just want ‘fun’ benefit from the MESS drivers for popular systems too (several of which have large amounts of free software, and in some cases don’t require firmware roms, or the companies have already approved distribution) so it’s really win-win
I’d also like to see a situation where MAME can be used as an educational tool, for teaching people about assembly languages, showing how these old things work. I feel it’s always good for a programmer / developer to have some low level understanding, and a knowledge of the past even if very little of it applies directly these days. Again not really ‘fun’ There’s another side to the ‘education’ role too. Most of this probably comes from the MESS side tho, but as the systems it emulates fade more and more into obscurity the role of MESS educating people in how they work becomes more important. Sure most standalone emulators can hide the gritty details but you can almost guarantee every popular platform has at least one piece of software where you simply have to do things properly if it’s going to work.
The possibility of the emulator just emulating individual components interests me too, interfacing with the real systems etc. Due to timing concerns and other issues that’s still a long way off being practical for many scenarios, but you’ve already seen the communication possibilities the port-midi support brought to the MESS side. I guess that is kinda fun if it interests you ;-)
So again.. I don’t see why I’m being championed here, in my eyes the future of our project is what’s in MESS, and that’s hardly a revolutionary idea. MESS has always been an extension of MAME, and is slowly becoming the most important part, the part with the most practical legal uses, the part with a real future, and the part that will take the rest of the project forward.
Just because I show progress on arcade emulation and highlight improvements in playability doesn’t mean my allegiance is strictly there, I wouldn’t be offering UME here if I didn’t think our future was the complete project including all the bits that are far less desirable.
I don’t care for everything you’ve worked on but I greatly admire your dedication, the amount of effort you’ve put into the project and for sticking to what you believe even when you catch so much shit for it. Rooting for underdogs is what I tend to do, though. :) Everyone that works on or has contributed to MAME/MESS/UME deserves praise (even the ones who act like complete egotistical fuckwits that know who they are and shall remain nameless) but you have been one of the most active and communicative members in recent history, as far as I’ve seen. Please keep doing what you believe is right and don’t let the people you’re unpopular with get you down.
If someone isn’t doing what makes them happy then what’s the point of doing it?
ah test rigs. everyone wants one. no one wants to support it. you are not alone. many projects out there are in the same boat.
No one’s being sarcastic Haze. And no need to get hung up on the fun comment.
Allow me to paraphrase you:
The 1% your work appeals to will value it a lot more than the 99% who don’t care for it or hate it.
sorry, didn’t mean to come across as hung up on it, I just found it a little confusing when I’ve always tried to push for practical uses and a lot of the basis for me thinking UME-style is the future comes down to the very different uses it offers :-)
personally I do consider a lot of it fun, because I enjoy the technical side of it, seeing how some things were related, how one area influenced another etc. but yes, the quote you’ve used sums up my feelings well and is what you have to remember with a lot of MAME work.
If you put it to the vote I’d say 99% would vote for the removal of all Mahjong games and Casino games, but the support exists for the 1% who do (and does no harm to those 99% who don’t) That’s one reason it’s hard to convince people that a full UME style build is the future because tho you’re naturally going to have more people who don’t care about that stuff than do, so even to see the level of take-up I’ve seen is very impressive IMHO. I bet if I was to put it to the vote less than 25% would be outright in favor, which makes constructing an argument for it kinda tricky, but at the same time if we made decisions based on such popularity statistics elsewhere in the project we’d probably end up with something that only ran PacMan, Street Fighter II and some Cave shooters because they’re about the only things you’d get a large consensus of people agree are worth emulating (and if you target a young enough group they’d probably not care for Pacman either)
Most of my MAME work has been driven simply by what is possible, it’s the only approach you can really take.
I guess I do try to present things in a fun way, highlight the things I know are going to have the wider appeal, and I guess I do feel that is important too. You need a way to get people interested in the project before they’ll explore any deeper so obviously highlighting work done in areas people can relate to and are familiar is good for that, and good for getting people to actually update to new versions (which likewise is important for the health of the project, having people running old code is never going to help us find bugs in or improve the current code) So in that sense, yeah I do try to make sure the updates have a bit of fun in them :-) I guess putting up the screenshots also helps, it’s a bit like the old ‘WIP page’ MAME had, and the pictures + small quotes are certainly easier to digest than my blocks of text (the same principle applies, if people find the pictures interesting they might delve deeper and read the text to gain a better knowledge of what is going on, this site is after all in part to help educate people about such things)
Yeah, Firewave was doing some test for some areas of MAME, but actual test software that runs in the emulator to provide known results vs a PCB (and can be run on multiple PCBs to verify they all act the same) is something more unique to emulation fields compared to standard tests.
The main problem is in the time you spend polishing up the software so that it’s reliable and somebody other than you has a chance of understanding the results is often best spent finding out more things about the hardware while you’re in a position to do so.
‘fun’ here is an academic word…’bug-free’ ;-)
or ‘playbility’…i think your interest is not much different than ours…except that fruit machine things…after all game is all about fun…
“I don’t know where all this is coming from on a post about an unofficial update.”
I would say it speaks for what you do :-).
Anyone here have some love and passion about mame?
Geez!
They only care to destroy the people’s work.
Haze please don´t give up, every secound is precious for a few fans.
I never think you are the only one working on this… :/
Haze reminds me from time to time to a free electron. There is no middle with him…People either love or hate what he does for MAME and the choices he takes…But I appreciate him for who he is, that’s all !!!
Umm…well anyways.
The glitch with pokecardu on gbcolor still exists on the last build and likely still will exist on this build. Maybe it has to do with that -mt stuff! <_<
Other than that, I have nothing new to mention. Let the battle for UME rage on.
Tempest is failing the POKEY RNG protection check and subsequently trashes its variables when your score passes 150,000. Couriersud has been informed…
Almost certainly a conflict with Liberator then, bet it was introduced the same period that one was fixed.
“LED Storm Rally 2011”
I did one last dig. taking all things at face value since I don’t know any of these people.
it seems that:
it was donated (not sold), and tested working beforehand.
A guy called Bryan McPhail had said it was working in MAME when he implemented it.
The youtube vid posted wasn’t created or posted by the donator of the board.
Guru dumped all the roms correctly
so if everyone is being truthful, then the issue lies within MAME. but if MAME is known to be correct, then someone isn’t being truthful.
I can see why you’d not want to waste time just trying to find out when you know the end result could be the same point as you started.
I guess we’ll just not know until another working board comes up.
Cannot compile mame0150:
Since around last 3 or 4 mame releases i cannot compile mame using this:
http://es.tinypic.com/view.php?pic=21oa8g8&s=5#.UlnP0VOaQwp
Result:
http://es.tinypic.com/view.php?pic=2a69ug1&s=5#.UlnPylOaQwq
Environment: Pentium 4@2.5GHZ, 1GB RAM. Windows XP SP3.
yeah, it’s a fairly well documented issue (in MAME terms) with the current Mingw packages / GCC versions, Windows XP, and certain processor types.
There is no real workaround, you can use the older toolchain but due to other bugs some drivers won’t work. Likewise you can do an older GCC (for vconv.c) + Visual Studio compile, but Visual Studio builds tend to be much buggier and slower.
The error is a bit confusing, Illegal Instruction suggests that the compiler is trying to use an opcode not implemented on your CPU, but I’m told using a newer OS allows it to work, so it might just be the compiler triggering a false error. Compiling on XP was a bit flakey even before this with some drivers inexplicably failing to compile without crashing the compiler (simply moving where functions were in the file would fix that) but this problem as you’ve seen simply causes it to fail on every file.
Unfortunately there is nothing I can do to help you, and nothing we can change in the MAME source to prevent the error. Maybe there are newer tools that don’t have the issue? The problem is there aren’t really any of the developers still on XP + older hardware to check when things get changed over, and XP support might end up going away entirely if we do multi-channel audio.
“There is no real workaround, you can use the older toolchain but due to other bugs some drivers won’t work. Likewise you can do an older GCC (for vconv.c)”
Speaking for MESS compilation. You can use an older MinGW toolchain mixed with newer Qt and Python but the lua script support doesn´t work. This is the only limitation as far as I know.
Yeah, I think it might hit a few drivers MAME-side but it is probably the only real option.
Not an ideal situation, but kinda out of our hands. I’d recommend people don’t distribute builds made with the old tools tho because unlike visual studio builds etc. it isn’t obvious they’ve been compiled with an unsupported version.
As a workaround to the build problems, you might be able to build the 32-bit executable on a newer OS, but specify the required “march” settings for a Pentium 4 that only supports SSE/SSE2…
-march=pentium4
I was talking about people which “not” want change the OS or hardware and where the official tools doesn’t work.
Forgot to say and to avoid confusions what whit the lastest mingw displayed in the mame page screenshot (mingw-mame-20121207) it worked for a few releases in the same Hard/OS environment, anyway i’ll try whit a newer MS-Windows. Just for curiosity sake i tried whit ReactOS (an early october trunk build: bootcd-60601-dbg.iso) and got the same error (in real hardware).
interesting, that points it back at being the compiler / cpu combo rather than the OS (which makes more sense and is what I’ve long thought) but I guess such bugs can manifest themselves in different ways.
The same error whit same Hardware environment but under Windows 7 SP1.
ok, that’s more what I expected to hear, guess people weren’t really using the same tools when they claimed W7 fixed it.
So you’re really stuck with Anna’s suggestion of using the older tools + the python & qt bits.. I have a feeling whoever packaged the compiler we use compiled it with processor specific optimizations turned on.
I feel AnnaWu’s suggestion results too complex to me: Manage 3 tools at same time?, how?.
And krick talking about “march” (?) settings for a Pentium 4 that only supports SSE/SSE2…
“-march=pentium4” i thinked must be added in “make” but not works ¿?.
Maybe is related or not but i tried too whit GUI “Mame compiler V1.3” CPU optimize label in two ways 1) “Auto detect”, and 2)”Pentium 4 (-SS3)” whit the same error, but only under Windows XP SP3, should i try under Windows 7 SP1?.
It won’t work.
The actual compiler must have been compiled with settings that don’t work on your CPU. This could well be intentional so all future versions might exhibit the same problem.
There is nothing you can do with the current compiler and your current CPU.
If AnnaWu’s suggestion is too complex then I’m not sure you really need to be compiling MAME in the first place, actual development is much more complex.
It sounds to me like the only reason you want to compile is to apply mods that we’d rather not have applied and are potentially dangerous.
Thanks for the support, not offense, but i’m only interesed to still compiling MAME myself to gain a minimun of performance. Sorry, for the generated suspicions, not indeed.
Performance benefits from the optimizations aren’t really noticeable in my experience, they just tend to leave more drivers broken or slower when the compilers messes up the optimizations ;-)
Not even Intel compiler builds are faster because there is some code in MAME that is called very often and has been specifically tuned for GCC (the delegate code) would be kinda nice if Aaron added the proper optimized VCC and ICC codepaths tho for more direct comparison.
Sorry for assuming the worst, but once people start mentioning ‘Mame Compiler’ it usually ends up being because their only reason is they want to apply certain patches, and even in recent times those patches have caused issues for the users of them too (eg. somebody was moaning controls weren’t saving, it was because of the ‘nonag’ patch they’d applied)
Well i don’t remember where but i read somewhere in the web something like this: “compile MAME and you might gain around bettween %5 an %20 in some drivers” the first time i compiled MAME and comparing release bin vs own bin i noticed this, Example: Neo Geo driver runs around 80%-85% bin vs 100% in my own bin. So my experience and whit the hardware (Pentium4 2.5GHZ, 1GB RAM, Nvidia 5200 FX 128MB) is a good thing to me. Other good example i remember is in Data East’s “Sly SPy”. In others drivers (wich i don’t remember) the improvements speeds are minimal (%5).
Anyway, ironically according what are you said, few days ago i’ve compiled ReactOS 0.3.15 and compared bin vs my own bin i used a benchmark test app to compare, and results test are worst whit my own bin maybe around 5% if not the same, anyway i don’t see in ReactOS page any or even trought the web the -supossed?- benefits to compile it.
I feel this thinks looks like terrible complex to me and whit my VERY vague knowledges even results more confusing.
You said: “they just tend to leave more drivers broken or slower when the compilers messes up the optimizations ;-)” but i don’t understand it.
I’m surprised you’ve seen 20% speedups, that’s more typical of going from 32-bit to 64-bit (but obviously you’re not doing that) Typically I’ve seen maybe 2-3% difference on an optimized compile at most with some drivers getting faster and others ending up slower.
The modern version of the compiler you’re trying (and failing) to use actually made several drivers slower when we changed to it, but we changed because the older one (despite being faster in places) was producing wrong code for some drivers and the debugging tools shipped with it didn’t work properly for 64-bit either.
The main reason for compiling isn’t extra speed, but instead so that you can work on the development of it, and improve it or alternatively to help test changes being made in the project. This applies to ReactOS, it applies to MAME and it applies to most open source projects.
I finally said to avoid confusions what the performance improvements was obtained compiled ever following the instructions from mamedev.org whit command line and executin “make” whit the source code as comes but in last times i’ve used GUI “Mame Compiler 64”. I hope someday can do test performance between rel bin and own bin on x64.
Thanks for your contributions in creating such an amazing emulator. I recently removed many stand alone emulators for systems that MESS/UME emulates better. Though, I encountered some small issues, for instance, Comix Zone for the Genesis loads with a flipped title screen, otherwise gameplay is fine. Also some Atari 5200 Games such as Frogger and Pac-Man have graphical issues, Frogger is unplayable as a result. These issues are present in both 0.150 and 0.150×2 releases.
If you are using a pent4 that is why you are probably seeing some decent speedups. That particular cpu has a very long pipeline and is susceptible to pipeline stalls. It is why the AMD chips were usually better than Intel chips of the time. So the compiler can help hide some of that. If the devs are seeing mis-compiles from the compiler I would defer to them. They do not happen very often but they do. When they do they can be extremely frustrating to fix. I usually see it when you try to be clever with #define macros. It would also make a case for updating the compiler suite again if the bugs have been fixed.
However, you would be better served by buying the lowest end current gen ivy bridge intel core cpu. It would probably trounce it speed wise by a good margin. The p4 is getting very long in the tooth at this point being nearly 6-9 years old at this point even if you have one of the last ones. It wasnt that great of chip at the time even…
I have another PC, Athlon XP 3000+ probably i’ll give it a try.