Ultimate MAME 0.144 - 模擬器

http://mamedev.emulab.it/haze/2011/11/15/ultimate-mame-0-144/

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
http://mamedev.emulab.it/haze/files2011/ultimatemame0144_source.zip
32-bit Binary
http://mamedev.emulab.it/haze/files2011/ultimatemame0144_32-bit.zip
64-bit Binary
http://mamedev.emulab.it/haze/files2011/ultimatemame0144_64-bit.zip

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.


--