David Haywood's Homepage
MAME work and other stuff
May 11, 2015 Haze Categories: General News. 38 Comments on The Gulf of Bothnia

As has widely been reported commit 5df1b60963060ea61de7bed8d2e8f68f284bf1d9 marks the beginning of a new age of MAME.

The UME project, which began life as ‘Ultimate MAME’ in 2011 has dissolved into what from this point on will simply be known as MAME.

The option to build an ‘arcade only’ version of MAME remains as a subtarget, and likewise you can still build MESS if you have no desire for the arcade drivers, however the default ‘out the box’ configuration is now one that encompasses ALL the work that is being put into the project. I expect the other build options will evolve over time to become more hardware focused for example, allowing you to build a solution containing all drivers using a given device (which would obviously be beneficial to development) The way we generate the build solutions now using Genie gives us the possibility to explore more options in the future.

At the same time you’re also seeing a drive to clear up the licensing a little more. This, like the above, is just a step in the project maturing. As an arcade-only emulator it was easy to write MAME off as nothing but a toy; while it did have a number of other uses the majority of what it did (and what people ended up using it for) was run games. By bringing in the more serious side of the project we end up with a more professional piece of software with numerous irrefutable uses that extend well beyond any simple misconception of the project being nothing but a toy. With that more professional front to the project the need for a standard license also becomes greater, and I also feel more comfortable in re-licensing my code to be more permissive knowing that it is part of something that has many more legal uses. Obviously a number of the issues with older code that were raised before remain, but we’re in a better place right now than back then.

The main topic for discussion when it comes to MAME doing more than just arcade games is ‘what does MAME stand for’. While people like to put forward suggestions for new names still fitting the acronym I think the most important thing is not to focus on what the letters stand for, but to simply focus on what MAME as a brand stands for. For the longest time now ‘MAME’ has represented a bridge between the past and the present, a project providing a platform to keep creations of the past accessible, providing documentation (an insight into how things worked), reusable components, and importantly a place for those interested in emulation to do their work. Just like nobody really thinks of ‘SEGA’ as ‘SErvice GAmes’ the traditional meaning of the MAME acronym is less important than actual work we do.

If you still want something to mentally associate with the ‘new MAME’ then the suggestions of “MAME And MESS, Emulators” and “Multiple Archaic Machine Emulator” do strike a chord with me, but I doubt the official acronym will be changing, it simply represents where we came from.

People have asked what my opinion on all of this is, probably expecting me to have a lot to say about it now that it’s finally happened, however, I don’t. I don’t mind that the UME brand is gone, it was a fun thing, and yes, I did like the name (EMU backwards, the combination of two things ‘U and ME’, the way it was creatively used in the word ‘ConsUME‘ etc.) but in the end the project was only ever a means to an end, a way of showing that the projects could work as one, and a way of ensuring no further conflicts between the projects crept in after they’d ended up really quite far apart at one point. The brand has served it’s purpose.

I think, as the project grew up, this kind of change was inevitable; just as arcades saw a steep decline interest in the baseline MAME project saw a steep decline; hardware we were emulating was being better tested by non-arcade systems, and a lot of developers were already starting to write more code for the emulation of non-arcade systems than arcade ones. The flexibility and design patterns required for the non-arcade systems were already starting to define the project too, leading to better more reusable code. The source repository used for both projects already existed under the ‘MAME’ name only, the source distributions were already shared, and releases were already being made from the exact same code revisions. Mametesters has also already been taking bugs for the non-arcade side for a while, and a number of other sites were providing support for both due to improved awareness that they really are both built from the same sources. In that sense what we see isn’t such a big step at all, just another small step.

Obviously some work needs to be done on unifying terminology, there are many places in MAME which refer to things as ‘games’ (or in MESS as ‘systems’) where in reality a unified term (something like ‘machines’) would apply better to both the arcade ‘machines’ and home ‘machiness’, but again that would simply be refinement, and another sign of the project becoming more serious, and more mature. Concerns with UME such as not being able to identify the type of system from the XML are more likely to be addressed now that everything is included in the primary target.

For an end user (not interested in developing) all it really means is that you get the option to do more with the binary you download; you have the opportunity to see how the code used for emulating Sega C2 / Megatech / Megaplay games fares when asked to run larger parts of the Megadrive / Genesis library, you have the tools at your fingertips to explore the different home ports of various arcade games and compare them. If the new additions don’t interest you then you can simply ignore them, just like you ignore so many of the terrible games supported by MAME right now.

From a developer point of view not much changes immediately; new developers get more in their build by default, and on a sufficiently high end system (as I’ve recently found out) build times and link times are still good. For developers on weaker hardware the old targets can still be built, and hopefully in the future things will become even easier with more focused targets for specific cases becoming much easier to generate than ever before. The project benefits because developers are more immediately aware that their changes must work with all sides of the project, as by including everything by default we’re showing we value it all equally.

There are always going to be people calling the project ‘Bloatware’ or throwing ‘Jack of all trades, master of none’ statements around about the project, but in the end the people calling it Bloatware are never really going to be satisfied as long as it emulates things they don’t personally care about, and the only way we’re going to master the emulation of many systems is by increasing exposure, getting people on board, and working hard on doing what we’ve always done; every little step counts. One thing I’ve noticed with MAME is that it stands the test of time a lot better than many of the smaller emulators even if there is room for improvement (the number of older but popular emulators that fail on simple things like coping with a wide-screen display without distorting the image is disturbing for example, I’ve found myself using MAME/UME very often simply due to little things like that, there are many advantages to it being an active and open project with a wide variety of users and tasks that need to be done meaning we’re never far from a release)

Moving on to more random thoughts, I guess UI builds will adopt the existing MESSUI code (as it provides a way to use a number of features that MAMEUI doesn’t) meaning those who have been asking me to do ‘UMEUI’ for a long time might finally get something along those lines, although I’d definitely still recommend a real frontend over either.

Overall it makes me happy to see that the public response has generally been positive, with some uncertainty over how things will work, but I’m sure once there has been a release or two with this as the default configuration people will find it a lot clearer.


You can follow any responses to this entry through the RSS 2.0 feed.

F̈ucktastic! :D

nice write up
I’m not fully sure why there should be any separation / differentiation between arcade and home hardware in the xml, though… external ini files can handle that with ease ;)

Thanks for this complete explanation Haze.
Keep the good work!

So, MAME will finally support Parasol Stars ;)
Oh, ok, not the rumoured-not-to-exist arcade version then!

the “the rumoured-not-to-exist arcade version” is just a PCE on a timer (we *know* it exists as a Tourvision cartridge – an unofficial PCE based system) so yeah, the exact same thing is now supported, but without a timer resetting your game if you forget to insert a coin every 3 minutes ;-)

afaik (according to Taito sources) there’s no legit credit per set of lives arcade version, even if the game was clearly designed around such a system. I wouldn’t rule out somebody in Korea having hacked one up to behave like that, much like the Genesis and SNES based boots we’ve seen (Super Street Fighter 2, Gundam Endless Dual, Final Fight 2 etc.), but even over there such extensive hacks were more exceptions with the usual route being to hook a console up to a timer circuit.

Would there ever be scope for the PCE on a timer to be added to the arcade side of MAME? Or does it depend on anything being found in the wild…?

If such things are dumped I’m sure they’ll get added, in some cases the timer circuits are crude discrete things tho that really just power down the system / lock out the inputs when they expire meaning they’re utterly generic and can be applied to anything.

for some reason people seem to be selling such things for far higher than should be the market value, meaning not many get dumped.

there are actually a number of PCE-in-a-timer systems in MAME already, see all the sets marked as ‘(Tourvision PCE bootleg)’ note, that right now the timer system isn’t actually emulated tho, hence the ‘not working’ flag.

The ‘Blazing Lazers’ and ‘Paranoia’ sets you see in MAME are likewise ‘PCE on a Timer’ sets.

The actual Parasol Stars Tourvision cartridge hasn’t been dumped, the game code likely matches the regular PCE version, but until it’s dumped from an actual cartridge it won’t get added.

There are also adapters for PC-10 and Nintendo Super System to allow plugging in of 100% regular game cartridges (not everything works mind you) so I guess those will eventually end up being supported too, in MAME, using the softlists that were developed for MESS. The official merger makes supporting such things more logical.

At last! It’s nice to see UME come to fruition. Well done.

As a coder, it makes so much sense.
As a front-end developer, this is amazing.
As a admirer of all the work that was put into MAME, MESS, UME, and whatever, that’s makes now baseline MAME a madly powerful emulator, with fantastic objectives: emulating stuff accurately and so, documenting systems.

The new MAME as this standing on shoulders of giants feel to it. Hail the new MAME! Now with even more lovable stuff in it \o/

About the system differentiation, while ini files could do the trick, tags or any metadata identifying roughly the type of each system would be more pratical and less hackish for front-end devs.

Between that and full github it seems the project is moving along nicely again. I could see something like mametesters being pulled into github and its bug tracking system. Also things like the external info (like mash history) and catlist being pulled in as well. All of that information is very interesting. I also could see things like ‘game groups’ becoming more interesting as parent child is not really the right term for some of the stuff in there. But that is more meta data than actual game work… But sometimes the meta data is just as important to hold onto.

I also noticed there are several dead trees in github leftover from the svn days (some are 2+ years old). Are there any plans to merge that code in or should it be pruned?

Congratulations Haze.

Thanks very much for your explanations Haze, and well done for proving that UME could be done :)

yeahh new age but consuming resources by becoming heavy (sorry my bad english). mame would want a light that was not asked both resource. thanks.

Hello ,Haze,when you post 2014 a year in MAME ?

Thumbs up Haze ! Good to see that MAME is maturing.

> yeahh new age but consuming resources by becoming heavy (sorry my bad english). mame would want a light that was not asked both resource. thanks.

combining the projects has 0 impact on emulation performance, why this misconception is still around in 2015 I don’t know.

the main reason MAME gets slower is because we make the emulation better.

Great News!
Out of curiosity, does this change anything about the emulation quality? IIRC there were some cores better developed in MAME compared to their MESS counterpart and vice-versa; are you merging those or are they still kept as separated cpus/modules?

There are very few cores duplicated across the projects these days, a lot of work was done on improving that over the last few years. The MESS PC emulation code could possibly benefit from some of the recent PCI work done in MAME (which would allow hooking up of the voodoo etc.) but overall we’ve done a lot of work in removing duplicate code, and refactoring things so that code can be shared; I fixed a bunch of bugs in Bloody Wolf last year by making that driver use the PCE emulation cores from MESS (with a little rejigging as the palette hardware was different)

I’ve noticed that some of the UI build authors are unfortunately being a bit stubborn over this, probably because the UI code is so horribly broken, exists as little more than hacks upon hacks, and barely works under the new scheme, and rather than fix it / use the MESS UI code as a base and improve that they’d rather not present users with the new capabilities. With time I imagine they’ll have no choice anyway as the current sub-targets will fade away in favor of more logical hardware based build filters, it’s just a case of if they want to prepare for the future now or delay it until that time then throw a fit again when their builds break. As much as I hate the UI code I might just have to offer the proper builds with it myself (unsupported of course)

Hello, Haze!
I’m not understanding all those license changes in MAME code recently.
I know that used to be a custom license but now all the licenses are changing, mainly for BSD3, GLP and LGLP.
Could you please explain why do these policies changes and how these changes will affect MAME project?
Thank you very much

As mentioned, we’re just opening up the files a bit more for others to use, making it a more useful resource to the community, making it easier to people outside of MAME to make use of the code we’re written. The license we were using made a lot of sense for when we were just emulating arcade games, protecting our interests, but when we’ve got a project as big as the two combined on our hands with the number of potential (legal) applications greatly expanded it makes sense to allow others more use of our code / emulator.

Our goal has always been to produce a comprehensive set of documentation, and a useful resource to hand down to future generations, and it helps with doing that.

The commercial use limits in the previous license made even education institutions and museums weary of using our code, for arcade systems that wasn’t the end of the world, but if we’re heading a serious project that deals with a lot of classic computers, terminals, and other things which are truly museum pieces, of no real practical use these days then it’s a lot more logical to allow our code to be used more freely, to help people learn.

I see a new working driver: Bandai Tamagotchi generation 1 hardware
It seems a big achievement. Is it or are there others emulators of it?
But there is nothing publicized about this fact? Nobody shows a screenshot? Nothing?

thank you

The only thing we miss now on mame is this in 3D, with a kid sitting on the machine :)
I really don´t care, but i accept mame doing this.
I want this wondefull game dumped.
The game is not so bad at all, and it’s great.
GoGo Pony by IGS. Similliar to WII Games.

I’m confused about the whole licensing situation. Unless I’m missing something, it looks like they’re simply trying to push through the license change which so many people had issues with a while back. Why are things any different now?

> Why are things any different now?
more of the main contributors are agreeable to it, it’s more of a team decision rather than alt licenses quietly being forced into files (which felt a lot more like a sneaky way of hijacking things) and a more active effort is being made to track down contributors.

as I’ve said above, there are still issues, deciding where you draw the line over what counts as licensable code if an issue, a lot of what you see in MAME is the factual representation of things, and if done right there is only one way in which it can be done… this makes it quite tricky to work out at what point ‘old code’ has been completely written out of the project because a lot of things would be identical if done from scratch..

there’s definitely still a question over the previous change of license Aaron pushed through (when the old MAME license was cleaned / tidied up) unless we assume that all code submitted prior to that actually had it’s ownership assigned to the team (that is the assumption I made when submitting code, but others could disagree)

not easy, but less rushed.

Open Source on MAME will more better and quick recovery of mame.
On PCSX2 emulator, in 2 years they have 88% of the videogames are playable.
Believe or not, mame will change forever, and this is only the beginning.

We still need people to develop it, and people using it in order to ensure that it’s better tested.

We still need everybody to pull together, including those doing derivative builds, rather than hacking away at our sources and stripping things out..

We need people supporting the idea of proper emulation with shared components rather than trying to tie unrelated and non-shared emulation cores under a frontend, the former of which is real work, the latter child’s play.

Changing the license alone doesn’t really mean much, we can’t just go pulling code from other emulators either because many are written using techniques that cheat in ways MAME can’t (eg. running sub CPUs as and when needed rather than everything being in a scheduler, multi-threaded CPU execution etc.)

It remains to be seen if the license change will actually attract new developers.

It was predictable that the UI ‘devs’ would be a-holes with this change

Robbert, Mamesick, JohnIV none of them can code their way out of a paper bag so just hack hack hack and resist changes

If there is justice in the world this will be where the shoddy efforts they make will make them left behind. Viva Mame Revolution

Not sure I’d say a-holes, but clueless, yes.

The fact they’re now hacking the executable name to remove the subtarget when they’re very much building a subtarget says it all really, I do wonder if we should maybe add a rule to the trademark stuff saying you can’t call it MAME (without permission) if you strip stuff out.

Maybe the UI code is bad or not. I have not bothered to look lately (last time was early 2000s). However, you guys now have a full libre sort of license. That does mean people are going to do things to the code you may not agree with. It is OK. You guys are the main line. They have to keep up with you. Not the other way around. Instead of dividing the groups. A better way would be as you have already started doing (include more!). Make them proper sub targets with a well defined interface between the core the and the GUI (maybe reuse/improve what libretro did as an idea). I remember years ago there were hooks in there for the UI guys. But that sort of went away (but it sorta didnt). MAME is a *very* daunting project to navigate thru for an end user. A GUI helps with that. It is why they are popular.

To put it this way the old MAME cmd line was not bad. MAME gamename. Not bad, fairly easy, anything special was in the docs. The MESS one on the other hand you need to get particular parameters on a computer to get it to load correctly. That is an exercise in frustration. You basically have to some knowledge of how the original computer worked in some way to get them to work at all and translate that into MESS jargon. That is where a GUI comes to the rescue. New programmers come from previous users…

> To put it this way the old MAME cmd line was not bad. MAME gamename. Not bad, fairly easy, anything special
> was in the docs. The MESS one on the other hand you need to get particular parameters on a computer to get it
> to load correctly. That is an exercise in frustration. You basically have to some knowledge of how the original
> computer worked in some way to get them to work at all and translate that into MESS jargon. That is where a GUI
> comes to the rescue. New programmers come from previous users…

well, home computer back in the 80s were harder to use than arcades, where you just needed to insert a coin. there is no way we can make the two of them equally easy ;)

however, you just have to (replace MESS with MAME, if you are not building the subtargets)
1. launch “MESS system -lm” to list the available media switches
2. launch “MESS system -switch game” and you’re almost done…
in the sense that you still need the knowledge about how to launch the game in the original system, but that’s usually the easier part of the burden… especially if you start using lua scripts to type the launch sequence :)

> well, home computer back in the 80s were harder to use than arcades, where you just needed to insert a coin. there is no way we can make the two of them equally easy

Heh, in some cases yes. But others were not quite such pain. I put a cart in I turn it on I am running. For example the Apple II. What one could consider one of the more hackable computers out there. You did not really have to understand it too well to get something up and running. Just be able to follow along with the included diagrams to put it together (which was a 1 time task). Then pop in a self booting disk and you were ready to rock. Where as in MESS you need to first know you are dealing with a disc which flavor of Apple you want, then if your particular program you are messing with expects some sort of expansion card. These are decisions you have to make every time you run. There are ‘extra’ things that have to be done every time that I did not really physically have to deal with on the old computers (it was already put together).

I understand the MESS syntax (now). But it a very command line sort of thing. Command line has its place but it is kinda of tweaky in this case. It is a *lot* better than it used to be. But for some reason I still feel it is cumbersome.

I will use it. But I grumble while I do it (thats just the lazy old fart in me) :) There as some things command line excels at. This just does not feel like it is one of them. If feels like a ‘programmer’ interface. One that is perfectly functional and does everything. But is a steep learning curve. I could see a lot of people I know (who are perfectly capable of doing this) getting frustrated with it and saying ‘not worth my time’. It also feels like an interface that was designed to be automated by another program.

>especially if you start using lua scripts to type the launch sequence
That is a cool method I have used in the past. Writing my own launch scripts (I personally would use CMD, bash, or python). But it is something a more advanced user will do. But it really is just step one into writing your own ‘GUI’ to make it easier to use? You wouldn’t bother with it, if the command line was not picky? You are automating a task that you find burdensome.

My point is to make it more accessible. GUI does that. Once you grow past the GUI the command line becomes more interesting. We all were beginners at one point. My other point is GUI will continue to be ‘hacks’ until a standard interface is presented from inside the code. The thing is no one wants to write a GUI. They are rather dull and boring things to write.

The Apple II machines in particular have a configuration curated by default to run the large majority of software (and probably 99+% of games) at their best as-is. If you pull the MESS BIOS and MESS Softlist torrents from you-know-where, you can literally “mess apple2e oregontr” to play Oregon Trail, or “mess apple2e karateka” to get your Jordan Mechner on. That’s about as close to the ease-of-use of “mame galaga” as you can get.

>>> It also feels like an interface that was designed to be automated by another program.

In some way it is. At some point, dev have decided it would be a better idea to concentrate on developping core than spending much time maintaining an UI.

So they let this job to external developpers, and some did some very good thing, like QMC2 which make using the mess part far less annoying than when you’re using command line.

That’s cool. I have a humble question about a ‘bug” I’m having with UME that it doesn’t happen with MESS. When I try to run a MSX2 cart using “msx2″ machine, UME gives me the following error (note that MESS works without errors):
[code]D:\emulators\mame\ume>”D:\emulators\mame\ume\ume64.exe” msx2 -cart1 “D:\emulator
s\MSX\MSX2\cartridge\Zombie Hunter (1988)(Hi-Score Software).zip”

Unknown system ‘msx2’
“msx2” approximately matches the following
supported games (best match first):

ax350 AX-350 (MSX2)
ax370 AX-370 (MSX2)
canonv25 V-25 (MSX2)
canonv30 V-30 (MSX2)
canonv30f V-30F (MSX2)
cpc300 IQ-2000 CPC-300 (Korea) (MSX2)
cpc300e IQ-2000 CPC-300E (Korea) (MSX2)
cpc330k CPC-330K KOBO (Korea) (MSX2)
cpc400 X-II CPC-400 (Korea) (MSX2)
cpc400s X-II CPC-400S (Korea) (MSX2)
expert20 Expert 2.0 (Brazil) (MSX2)
expert3i Expert 3 IDE (MSX2+)
expert3t Expert 3 Turbo (MSX2+)
expertac Expert AC88+ (MSX2+)
expertdx Expert DDX+ (MSX2+)
fpc900 FPC-900 (MSX2)[/code]
Is this a limitation caused by UME ? Shouldn’t it work the same as MESS ? I have a thread in EmuChat messageboard for a more detailed conversation:

Nevermind. In latest MESS builds newer than v0.151 both msx and msx2 machines were removed…

Right, the MSX / MSX2 aren’t computers, they’re rough specifications for computers. MESS supports the actual models of computer based on those specifications.

If you want to run Japanese games you’re best picking a Japanese model etc.

Well these news definitely gave strong emotions.
I was always a fighter (from the side of a power user) for this cause of merging the two projects, years ago, resulting in making enemies and getting banned in fora I was a member for years (I wonder if the same guys still administer them).
I also “pushed” QMC people to re-contact you and the result was QMC-UME (that actually now led to the first front-end to be so ready for the change in MAME).
A great day in Emulation and happy I may have took a tiny tiny tiny part in the story (although 99.999% of people will never realize).
REALLY good work Haze. Well done.
How are things these days? Are you closer to the main team? Have things changed in that front?

I cannot wait for your next project here. Take your time to post it. ;)
Mame will be more strong in 2016.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.