MESS is MAME, I’ve made this point before.
The functionality found in MESS, the ability to run console / computer based software can easily be added to MAME.
There has been talk of doing this officially for a while now, but every attempt is met by too many opinions, too many people trying to overcomplicate the process, and too much focus on offering LESS functionality to the end user and requiring MORE code to get there.
As a result nothing ever actually happens.
There are some devs saying they’ll quit the scene if it ever happens, contribute nothing more, there are people who really don’t seem to want to allow this functionality in MAME, even if there is no cost at all to having it, and a huge number of benefits in terms of testing, unified development and a cleaner source tree.
The most elegant solution to this problem is also the simplest one, and that is to wipe from your mind any concept that a system having a coin slot is a valid criteria for division, and simply treat the source trees as if that were the case.
The current MAME source structure has 2 main emulation sub-folders
emu – all common off-the-shelf, non system specific components go here
mame – all custom chips and system emulations go here
Inside each of these is currently a tree structure of drivers, video implementations, machine implementations, audio system implementations etc.
By default the mess project adds a further folder, ‘mess’ for non-arcade systems. On the surface that might seem like sound logic, but in reality it just creates uncertainty over where to look for files. By logic you’d probably expect to see video/n64.c in the /mess folder. N64 was a home console, but in reality it exists in the /mame folder, because it’s a custom component emulation which is also used by arcade games.
Proposals have been put forward to maybe create a 4th folder when merging the projects ‘shared’ but all that would achieve is bumping having 2 places to look for files right up to 4, and you’d still need prior knowledge that a system was shared between arcade / home use to even think about looking there.
Essentially the existing structure MAME already has is still the best, 2 places, making it obvious where to look. The most logical way to merge things would be to just move the MESS files into those folders, which, if you’re saying the coin / no-coin criteria doesn’t matter also makes the most sense.
The other argument people keep putting forward is that whatever system is created it should still allow the creation of MAME and MESS executables with ‘combined’ simply being another build target. This just seems to be avoiding the benefits of merging altogether. One of the big benefits of combining the projects is that in a default build every file gets built. When you’re dealing with a large number of cross-project shared files this makes the most sense, right now it’s very easy to break the MAME compile with changes in MESS (or vice versa) simply by not knowing that code was used in both. If all the dependencies are being built by default that simply can’t happen, in addition, you’re more likely to know where things are used for better testing of the actual emulation effects of any changes you do make. Creating an additional build target is again just more work, and ultimately offers less benefits, tiny builds of mame/mess specific stuff will always be possible with tiny.mak, but beyond that are unnecessary. Unsurprisingly, the easiest way to merge is to just keep the existing MAME target and integrate the MESS stuff into it, which again gives you the most benefits for the least amount of work.
So what’s the problem? Others have claimed that the work will take a significant amount of time, needs to be carefully planned, but again this just seems like stalling. Due to the size of the change and rapid daily changes which occur in both projects, it’s not really something you can take a significant amount of time over, it’s something which needs to be done in one swift action, and worked further on from there in order to keep everybody in sync.
In reality, it’s not a change which takes long to implement, at least not if you keep it simple. It takes about 2 hours if doing it from scratch, working out the modifications you need to make, working out where the conflicts between the project are and other such bits and pieces.
The other issues put forward against doing it the simple way are things like breakage of Save States due to MESS using a different signature, but that’s to be expected, and the signature issue could be resolved easily anyway. Given how often states break anyway I doubt many people keep them around.
More action, less talk is apparently the message coming from MAMEdev these days, and despite writing a lot that’s something I believe in, the whole concept of ‘if you want something doing, do it yourself’ is what has kept a lot of MAME development going over the years. With that in mind I’ve created a guide to creating an Ultimate MAME Build, one with MAME and MESS combined.
With this setup you can run anything from MESS in MAME, it ‘just works’, it’s wonderful. I can launch Megatech, or, if I don’t want the timer crippling the software, I can launch the standard Genesis versions. SNES, NES, PCE, Neogeo AES, NeoGeoPocket, you name it, it’s there, in MAME, working with the support from MESS. Want to see what state the PSX and Saturn are in? You can do that too, it sheds plenty of light on the work needed on those MAME drivers which you otherwise don’t see. I know not everybody is going to want to follow that guide.. so.. introducing
—- ULTIMATE MAME 0.144 —-
Source
32-bit Binary
64-bit Binary
The only real difference with the MESS stuff compared to what you’re used to with MAME is the launch syntax, as the majority of MESS systems use Software Lists instead of the internal Database, but as discussed in the previous post here, such support is needed for MAME and Multislot support anyway, so those on the ball won’t find it to be anything new.
“MAME genesis sonic” (or “MAME genesis -cart sonic”) will launch Sonic for the Genesis / Megadrive
some systems are a bit more complex, for example PCECD
“MAME pce -cart scdsys -cdrom draculax” would launch Dracula X for the PCE-CD. The syntax is more complex because that’s just how the system works.
for regular MAME stuff everything works just as it did before
“MAME pacman” will still launch pacman
There is absolutely no loss in functionality.
All in all it’s very easy to use, and having that functionality and code within the same project as MAME is invaluable for developemnt and testing alike. I just hope something like this is integrated officially sooner rather than later, because it will make working on heavily shared systems a lot easier and no doubt lead to many more bugs in MAME being quashed as the MESS drivers expose them.
I will give on word of warning. The ClrMAME support for the Software Lists is a bit flaky at the moment for users of that, they can still be imported however, and there is talk of integrating the lists into the -listXML output too. Some MAME frontends may struggle, but QMC should work because it’s been developed to the higher MESS standards already.
Anyway, in conclusion, I’ve always tried to push for progress, always put my money where my mouth is when it comes to such things, that’s exactly what this is here. I just hope that people do eventually start to see that this solution, which is by far the easiest solution, is also in many ways the most logical solution with the least complications and most benefits. This isn’t something that needs months and months of debate which ultimately end up nowhere, it’s just something which initially needs doing in one single operation, as soon as possible, with a level of commitment which means people will accept it and move forwards and work on any issues which arise from there otherwise it simply won’t get done as the last few years have shown.
FWIW there might be some -listxml breakage issue with the MAME/MESS trees on which this was based anyway, so I might have to update the ones used and change the builds here, but I’ll post notification if I do.
Obviously I can only work with what’s out there ;-)
Awsome , Thank You ..
Keep moving forward :)
A question, is it possible to load any file, or only the ones in the database? Like,
mame genesis -cart “Columns (W) (REV01) (Advanced Sound Test by drx – Hacking CulT).bin”
Also, can you launch from a disc drive directly, such as:
mame psx f:\
… or something similar.
mame genesis -cart “Columns (W) (REV01) (Advanced Sound Test by drx – Hacking CulT).bin”
yes, that works
mame psx f:\
no, and IMHO that isn’t really desirable behavior, forcing it to work with a real CD drive makes things non-deterministic and adds an extra layer of potential failure, not to mention it would never be practical for things like GD-ROMs anyway. Using an image of your media is better anyway, it prevents wear and tear of the original disc, or in the case of writeable media, prevents accidental change of the original media. Basically the less potential sources for impossible to reproduce bugs caused by the user’s PC the better, MAME/MESS should behave the same on any system regardless of hardware, only the performance should differ.
I believe somebody mentioned current versions will accept bin/cue in addition to the CHDs, although I haven’t tested.
Functionality is simply inherited from MESS :-)
Since you have your own MAME/MESS fork thingie now, does it mean you’ll stop urging MAME/MESS to add your changes? (I mean the intrusive ones that not everyone agrees with, like this merge or the NeoGeo softlists).
That would be quite a relief really, since every time it happens it causes quite a stir on the list. And the usual school playground fighting on the shoutbox. :P
This is proof of concept for what should be done, it isn’t a fork.
Obviously I’m not going to stop pushing for actual progress to be made with doing this properly, as having to maintain my own fork defeats half the point (I spend my time maintaining a fork, not benefiting from it, net result, MAME/MESS lose out)
Likewise this doesn’t get properly tied to any versioning information until it becomes official, so again I can’t personally use it for development because I near enough depend on that.
So no, you guys still need to work it out. I’m just proving that it can work, does work, and that the simplest approach is also the most logical ie. showing progress, not the endless list politics which lead to nothing.
To put it simply, maintaining a separate fork is counter productive, it uses up valuable dev time, and lacks key development aids as well as official support, while further dividing how people work rather than uniting it. If it were as simple as just maintaining a separate fork I would have done it long ago. The only solution to those problems is when something like this gets officially accepted.
A number of key devs have said they think it’s a good idea now, and I’m simply showing them (and others) that there are no major issues with doing it this way, and that in fact many of the claimed benefits of more complex merge methods wouldn’t be beneficial at all, just confusing. It can be done, with minimal effort, and what I’ve posted here shows that it works.
Just to clarify, this is a legitimate build, it is within the license, it does not contain CaveSH3, and it can be posted anywhere, assuming the site admin aren’t just jackasses. The build instructions are right there, it’s more than compliant.
I’d recommend if you want to post it, or variations of it to other sites that you mirror the files on sendspace or similar, as a couple seem to have ‘issues’ with linking here. I don’t especially care about people linking to here, as long as people can benefit from the build.
But again, I’d like to stress that this is fully legitimate, and not in violation of any terms of either project. I notice a number of people have been saying this is an ‘Illegal build’ and getting it taken down. That is not the case.
A.M.A.Z.I.N.G Amazing
This makes it sooooooo easy to forget the disaster of the official 144
The single exe for both is a thing of perfection.. I think I love you
The King is back – Hail to the King
Nice proof of concept!
It is a nice way to get people to stop talking and start doing… Just a side effect of software dev. We like to talk and talk… Then have a meeting about talking about it. When the actual work could have been done a month ago. I have seen it too many times on too many projects.
Also not sure how anyone would think it is an illegal build. The license is pretty liberal other than, the no profit and naming bits.
I tryed this and played toe jam & earl in the same emulator as super mario wld and parasol stars and street fighter and king of fighters
Am I dreeming is it real I will use this forever it is the best
I really like this. It’s neat, tidy and a big improvement on the sprawling mess of folders found in the unintentionally ironic titled MESS
The points you make all have strong merit and I don’t understand why any person with a background understanding of emulation would argue against them
Thank you for keeping MAME ahead of the game, I believe your changes will be accepted soon
+100 on that Amazing
Fanfuckin’tastic is what this is !
Maybe I’m saying something really stupid but… What about merge the 2 tree into one the MAME folder become “Arcade” the MESS folder “_Other” and put a switch into makefile so people can choose to build either MAME, MESS or both together. The “Arcade” have priority so the shared stuff go automatically there…
Sorry for my poor Eanglish
All we need now is a good GUI
The ‘problem’ with having more folders is you end up with more sub-folders with the same names, more places to look and in the end it just becomes ugly. Having 3-4 places to look for video files is not better than having 2, especially when there really aren’t *clear* dividing lines, nor do people have prior knowledge of which common systems were actually shared between home/arcade meaning often you’ll have to look in all 4.
The current structure is clear cut, structures beyond that are IMHO redundant.
Haze thanks for this proof of concept and I sincerely hope this gains traction.
While I haven’t paid any attention to the code status of Mame…I have with Mess…and as often as I see code being pushed and pulled from each project, seems like a lot of effort and very potentially error prone.
Which I can only see becoming more problematic as time rolls on.
So you certainly have my praise for getting your hands dirty with this.
@ thain
hmm I think Mala, HyperSpin, GameEx, Maximus, AtomicFe, …. all make wonderful GUI’s. :)
David, drop me a mail about what cmpro needs to support to get better softwarelist support.
I try to express myself better;)
I do not understand the arguments against the unification of the source …
I was thinking of a single tree from which to generate the MAME and MESS as we know them now, or the “Ultimate MAME”. The not shared part of source (the Machines) could be put into 2 subfolders called “MAME”, “MESS” or “Arcade”, “_Other”. The priority can be assigned to Arcade, so if a machine exist in the 2 “World” you’ll find it there…Everyone should be happy this. A MAME dev can ignore the _”Other” folder, can even distribute the source without that folder if he wish. An user that want everything (like me ;) can build the Ultimate Edition. Not talking about the simplification of code maintenance.
However thank you from this “Proof”
Thanks for this, it is really a great proof-of-concept. I, too, don’t understand why there is such reluctance in the projects to merge them (political or otherwise).
Anyway, all great ideas take time, so I hope this catches on with both projects, and maybe in some months/years we see a unified source structure with one SVN (or even git ;-) instead of the MESS (sorry for the pun) of the current sources
Keep up the good work!
-Darkstar
@Arch – as I’m seeing it there is no technical benefit to dividing the source code, only technical problems. Going to a lot of extra work just to keep the mame-only / mess-only elitists happy seems like a waste*. I think the hope is that by getting everyone onto a single ultimate build, they can stop the needless divide and work as a single ultimate team.
* if someone has a non-political reason as to why I’d want to use two separate builds and not the ultimate one, I’m all ears :P
(Also, yay git ;-) While that’s my personal preference, any DVCS would make it so much easier for me as some random third party guy to work on the code, which in turn makes it more likely for me to have code worth contributing back)
Can I say what I think of this here without being censored?
Nothing has been removed so far, so unless you’re unreasonably offensive, or start posting links to dodgy builds / rom sites you’re not going to get censored. (or you get caught by the spam trap, in which case I won’t even see your post)
I do understand that some people don’t like the idea of having a single project, and I’m actually very surprised by the overwhelmingly positive feedback here so far, I did at least expect a few negatives based on some of the comments last time this was mentioned.
Anyway, Shish, yeah that’s pretty much the crux of it. In my eyes hardware is hardware, dividing it by coin slot is no more valid than dividing by genre, dividing by year, dividing by number of buttons, if the games used a trackball etc. and merely suggesting such ideas to Mamedev would have you laughed out the room for well established good reasons.
For some reason however people have got this idea that just because there’s a pin on the system which when triggered causes the game code to increase a counter somewhere in RAM is reason to divide things, and have the supporting code in entirely different folders. I can’t understand this.
You see things like Aladdin, Final Fight 2, and Penguin Adventure in MAME, these are bastardized hacks of the console versions done by Chinese bootleggers, but just because they added support for a coin system to the game suddenly they’re 10x more legitimate and worth supporting to MAME than the originals from which they were derived, and that’s a bizarre situation. In those cases MAME is *already* emulating the hardware, and it would give a far clearer view of the situation if MAME also supported the native systems from which those hacks were made alongside them, in the same binary. Doing this requires next to no extra code, just the Software List file, a bit of handling for different cartridge types, and the flick of a switch, and suddenly you have a world of extra functionality for free and the original games, as well as the hardware from which the bootleg is derived are properly represented too. (For the example Megadrive, SNES, MSX) Those are far from unique cases, there are Russian bootleg titles based off ZX Spectrum games too. It was a dirty industry, both home and arcade. I’m sure there are home games using hacked code from arcades too, for a recent example of that look at the people hacking the Type X stuff to run on a standard PC instead of the custom ones used in the cabs.
There is also a group of people who want to divide MAME further, who somehow think they would get better performance, or more manageable code by doing that. You don’t. History has clearly demonstrated by going that way you just end up with fragmentation, and harder to maintain subprojects which just end up dying or being based on such old code bases they end up stuck in a corner unable to properly progress and unable to be of proper use to the main project due to the dated codebases (AgeMAME, PinMAME, mameUI)
That’s what it comes down to anyway, for any other situation MameDev have clearly shown that they think sub-division is bad, which is well justified. For some reason having a coinslot vs. no having a coinslot is creating an illusionary wall which they seem determined to stick with even if the projects do get merged officially. If anything all this divide represents is a big inconsistency on policy using a very flimsy argument of something requiring coins to justify it.
In the end it’s all just hardware, plain and simple, any emotional attachment to ‘this is an arcade’ ‘this is a console’ needs to be lost in order to further development. I’m sure eventually things will end up being collapsed down, just like this proof of concept, it just seems like Mamedev are determined to take the long route there, rather than the short one.
Very good
does it play xbox
You mean does it emulate the Xbox? No, not yet.. MAME will need to emulate it eventually for Chihiro, but even then it will be very slow.
Run on an Xbox? probably not an original one, the modern MAME/MESS builds are too demanding afaik all the ports to that are based off really old ones where merging like this simply wouldn’t be possible because the projects were too far apart at the time, plus early versions of MESS *really* sucked, it didn’t end up with a bad reputation for no reason it was worst in class for pretty much everything it emulated.
On a 360, no idea, don’t really care.
Keep the good work,does any of the fronteds work with your build?You should do it a year ago,just to see if the people will like the idea of merging them,some people in mamedev may not like it ,with absurd arguments,but majority of fans like it,
A simple light frontend would be icing on the cake :)
I think QMC2 should work with it, as I mentioned the guy doing that has kept up with the latest MESS developments.
I don’t use a frontend myself, but I doubt a lot of the ‘MAME only’ ones support the Softlists etc. yet due to them being quite a new concept to MAME despite their widespread use in MESS. MESS is a lot more ‘cutting edge’ and thus the frontends you use have to be too :-) The MESSUI code part of MAMEUI might handle it too if somebody were to build with that, but that has other well documented issues. I know robbbert has taken up the task of keeping that compiling, so maybe if you ask nicely he will do a build with that integrated*; I know the basic internal menu doesn’t really have full support yet.
If QMC2 doesn’t work it might be a problem with the -listxml, in which case I’ll probably issue a new build based on the current sources instead.
As I said this isn’t really a fork tho, and isn’t something I’m going to religiously maintain (mainly because I hope it opens the door to it actually being done in the main project where there would be real tangible benefits to development due to it being official and under source control) That said, if a build does have critical issues, or there are worthwhile improvements made I’ll probably find a bit of time to update things because it’s a handy build for end users still.
* I’ve made a post on the forum he reads, can’t promise he’ll compile anything tho.
Epic job on this. I was waiting for something like this for a while, since my point of view was pretty much the same, coin slot or not, its a machine that runs a program (Or game if you prefer).
I have been following your progress for a while Haze, from Naomi to CPS3 wips and stuff, and I think you’re pretty much awesome.
Keep making progress! :)
Ultimate – what an appropriate name for this combined exe. It really is the ultimate emulator and it can only get better.
Thanks greatly for doing this – my words won’t count for much but it really is the best thing anybody has done for the emulation scene in the 5 years just gone
— I really can’t thank you enough
Haze: The Steve Jobs of emulation. Always innovating, Always speaking his mind. Loved by many, Hated by even more.
Thanks for all Haze! After Mame/Mess combined, it’s possible return to work to hyper neo-geo or konami M2 hardware emulation? It should be a great christmas present for your fans.
Great work. One of the best emulation news of the year, maybe.
Oh, And regarding the voices of this being considered just a fork and fragmenting the community, I just say: ignore them and go on your own way. Keep working on this project, I’ve a good feeling that this is going to end like the old egcs vs gcc debate. Actions talk louder than mere words.
Wonderful innovation Haze – well done!
While most of the other devs are tweaking things here and there, you are one of the few that actually aspire to bring Mame to the higher echelons it truly deserves.
Let’s hope that the dusty elitists at Mame Dev can see the light in their tunnel vision and appreciate how much simpler, easier, time efficient and effective this really is.
Let’s also hope that twisty (the administrator over at the mameworld.info forums) drops the nonsensical ban he enforced on any mention of your name, finally gains a little more maturity, and allows everyone to discuss this issue openly. (Perhaps they have some job openings for him in Syria!)
In my opinion I see no issue over the naming of the “Mame” project, should this become official. It can still be called “Mame” without any complications, because it is a software that specializes in arcade emulation…Just because you can buy doughnuts at Burger King, it doesn’t mean you have to rename the whole brand to “Burger and doughnut King!”
It seems the whole reason for resisting this sensible integration has been due to nothing but fear of change. “Oh, what’s going to happen to our beloved arcade emulator if we mix in the consoles!” Breaking habits can be tough when you’ve been doing the same thing for so long. But to discover something that is truly better than the old, you have to be bold and venture down new paths! As small a change as this is, it could open something truly wonderful for Mame, because innovation breeds only more innovation…
The other thing I’d like to say on this issue relates to generations..
I’m 30 now, not a wee nipper by any means. My primary memories of ‘classic’ arcades are there being some cool looking stuff, but not actually even being tall enough to see / play half of it properly.
A lot of developers who have worked on MAME in the past, many of whom are older than me, no doubt saw arcades as something ‘special’ or ‘different’ and likewise the systems they owned at home as ‘special’ but for different reasons (arcade games were always big, flashy, cutting edge technology, home systems were lower powered and has very modest adaptations of the games) This created very different, albeit strong, polarized emotional attachments to each type of system with each loved for different reasons.
I think that emotional connection is what caused the project to be divided like this in the first place, but once you get to the 90s you’re increasingly seeing the exact same technology used for the arcade games and home games. To the later generations, who are really the potential future developers of MAME there really is no difference, arcades were nothing special, just other platforms. This divide simply never existed for them, the games they saw in the arcades weren’t significantly better than what they could get at home, plus arcades in general started to die out, social habits changed, so they became less and less significant. There simply is no emotional attachment.
MAME has to appeal to new developers (and users, who often become developers) in order to progress, that means it has to be in touch with their views. Trying to enforce some kind of view that arcades are ‘special’ and belong in their own project, or even sub-divided within the same project is lost on them. They’ll just do what I’ve done, look at the hardware and go ‘huh, it’s the same’.
They might be curious about the past, but if they want to see what ‘Street Fighter 2’ was, they’re not going to care if it was an arcade game, a console game, or both, they’ll just want to fire up an emulator and see what versions of Street Fighter 2 it runs. Somebody might mention ‘Lemmings’ to them, or other classics, they’ll do the same (and the Arcade prototype of Lemmings is far from a good representation of it)
I’d say the viewpoint that things need to be split is somewhat prehistoric. It’s easy enough to see where it comes from, but do such old viewpoints have a place in a public project which by very nature is trying to break down the walls between ‘old’ and ‘new’ by allowing everything from the past to run on current generation systems?
For Konami M2 the last person working on it was Phil Bennett, he had most things going ingame, but it’s been a long time since he showed anything. Definitely not something for me to work on.
HNG64 progress is simply stuck, there isn’t enough evidence given by the register use anywhere to make progress with confidence too many conflicts, even the debug modes are relate to the ‘game specific’ use of features in the current configuration rather than the way the hardware works. They could *really* do with the IO MCUs being decapped to improve the I/O simulation too, but again that’s not happening, and there are 3 of those to do (fight, drive, shoot) Sound banking doesn’t make much sense either, different games upload their sound to different places, but all of them eventually jump to invalid code.. I’ve exhausted all possible avenues for making progress on that driver, it needs a fresh pair of eyes and/or hardware testing (which is hard because it’s all surface mount)
AMAZING job Haze, like every time.
MAME always meant progress, I don’t get why some people push so hard NOT to merge with MESS. Maybe I don’t understand the underlying politics. I don’t care though. It is an open-source project ain’t it?
Push harder people. It has to be done officially.
Brilliant Idea!
I think what some old hands probably forget is the hardware manufacters of arcade/console/calculator/fruit machines probably went to the same rom chip company, something that happened in the 1970’s right to present day.
I see Mame/Mess as a historical document of these individual chips, whether it belonged to a coin-op/ gambling machine or a console it is still a Rom Chip with a specific function, as this proof of concept works, and as these comments are showing that this is what we want…. GO FOR IT GUYS – it is going to make all the devs jobs easier isn’t it?