David Haywood's Homepage
MAME work and other stuff

The Gulf of Bothnia

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.

Go to article.. »

Post Release Progress

May 8, 2015 Haze Categories: General News. 4 Comments on Post Release Progress

A while back I covered Race Drivin’ Panorama, but mentioned that it wasn’t full functional due to the side screens crashing when selecting one of the car types.

It turns out that the cause of this crash was actually a regression affecting ALL the Hard Drivin’ / Race Drivin’ sets in one way or another that had been introduced during a modernization prior to my changes. Osso tracked down his error when addressing the original MameTesters report, and as a result Race Drivin’ Panorama now runs correctly, displaying full-screen views (no car panels) when selecting the Roadster rather than crashing; it turns out the code I wrote before was actually just fine and the game can now be marked as working.


Race Drivin' Panorama
Race Drivin' Panorama

Couriersud did some more work on Breakout, improving looks and performance (it now hovers around 100% on a 4Ghz i7 )


Breakout

Brian Troha located some alt Golden Tee Fore! sets, including the original release and the 2002 release. Tracking down the sub-revisions of this could be tricky, especially if the online system was used to provide game updates (I’m not 100% sure on that) Also the game stores a lot of data to disk, including operator info and records etc. as well as allowing full version updates to be installed via CD, so finding clean drives is next to impossible too. These definitely border on the annoying to preserve territory as a result.


Golden Tee Fore! Golden Tee Fore! Golden Tee Fore!


Golden Tee Fore! 2002 Golden Tee Fore! 2002 Golden Tee Fore! 2002

Even better news for fans of the GTFore! series is that Ted fixed the map display making them more or less fully playable.


Golden Tee Fore! Golden Tee Fore!

Peter Ferrie gave some much needed attention to an unknown gambler that uses a i186 CPU. Turned out to be some kind of multi-game. One interesting thing with gambling games is they often have undocumented init codes which are required before the game will boot, sometimes even finding out how to access the page where you need to enter the code can be a challenge. Finding the code screen on this one wasn’t too tricky (last screen of the test mode, although it doesn’t explicitly ask you to enter a code) but working out the actual init sequence required took some digging through the game code; turns out it wanted keypresses of “1 1 X X 1 1 1 X X X 1 1 X 1 1 1 1 X 1 1 1 1 1 X 1 1 1 1 1 1 X” where X and 1 are 2 of the buttons the game uses.

This also required him to hook up a number of other components in the driver, although even with all this hooked up it doesn’t work quite correctly; never underestimate the amount of work that goes into making some of these run tho, they might look like dumb pieces of junk but they can be an interesting emulation challenge to those interested.


i186 based gambler i186 based gambler
i186 based gambler i186 based gambler
i186 based gambler i186 based gambler

Another gambler, this time one running on a Hyperstone CPU was dumped by system11. The hardware is by F2 system and very similar to their ‘Mosaic’ game. It fails to boot with a ‘Secret’ Error, which I’m guessing is something similar to the above, or a protection check.


Royal Poker 2

Go to article.. »

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.

Close