David Haywood's Homepage
MAME work and other stuff

Ultimate MAME 0.144a

November 18, 2011 Haze Categories: General News. 26 Comments on Ultimate MAME 0.144a

I wasn’t expecting quite such a positive response from the initial ‘Ultimate MAME’ post, but it seems like a decent number of people really like the single binary concept.

Anyway, there were a couple of issues with the MESS 0.144 source on which it was based, these have since been resolved, as well as several other changes made which may be of benefit to this build. In the 0.144 release things like c64 would just crash due to aforementioned MESS bugs, and the code for some MESS drivers would end up being compiled differently to a standard MESS binary due to it being hidden behind #ifdef MESS defines in the source. Micko has done some work on removing those cases, although he did manage to introduce some additional conflicts in the process which I’ve fixed and submitted a patch for.

Anyhow, what this means is that I’ve done a quick update of the build against 2 newer GIT revisions (MAME and MESS which should fix this handful of issues.

Combined Source (0.144a)
32-bit Binary (0.144a)
64-bit Binary (0.144a)

Also I’ve decided to add some screenshots of various things running in this build :-)


Miner 2049er Island of Dr. Destructo
Left: Miner 2049er (from the C64 software list)
A classic C64 platformer shows that the C64 driver works in this release, simple and popular arcade style gameplay on a home system,

Right: The Island of Dr Destructo (Amstrad CPC, from a TOSEC disk image)
Inspired by the classic arcade Two Tigers but arguably more fun, albeit a bit slow paced like most things on the platform. Always lots going on as you attempt to sink everything from Battleships to an actual island. One of my favourites

Pi R Squared Time Gal

Left: Pi-R-Squared (Spectrum, from TZX tape image)
A unique puzzle style action game on the ZX Spectrum which would have IMHO made a good arcade title. Two directions and a ‘switch’ button allow you to traverse between rotating gears. You must complete 360 degrees of each circle to collect the item inside it, and to finish a level you must collect the parts of a formula in order, while avoiding the enemies. Sound is sparse, but the gameplay is addictive.

Right: Time Gal (Sega CD, from Software List)
The laserdisc arcade version of this isn’t emulated in MAME yet, but the SegaCD version is fully playable. Not a big fan of these FMV games, but some people like them.

Pole Position Sonic The Hedgehog Megatech

Left: Pole Position on the Vectrex, Port of the classic Namco title running on this unique vector based home system, if you thought Vector monitors only existed in fancy arcade games like Battle Zone, think again!

Right: The Arcade Megatech system running Sonic The Hedgehog. The actual rom is identical to the Megadrive / Genesis version, but crippled by a ‘pay for time’ timer. You could install multiple games tho!

Pole Position Sonic The Hedgehog

Left: The original Pole Position Arcade from Namco

Right: The Megadrive / Genesis version of Sonic running in the very same Genesis driver as the Megatech version above, but without the crippling timer system!

The Apprentice Speedy Dragon

Left: The Apprentice on CDI. The CDI might not have had many good titles, and you could probably even make a case against ‘The Apprentice’ rather easily, but it sure is pretty, and much like ‘Hotel Mario’ on the same platform it presents what could have made a pretty decent arcade game rather than the god-awful (yet still better than most of the home output) quiz games which were released on the platform in the Arcades.

Right: Speedy Dragon, from the obscure Super ACan system. Emulation is still preliminary, but it’s an interesting Sonic inspired adventure.

Wec Le Mans Burnin' Rubber

Left: Konami’s Classic Wec-Le-Mans, one of the most solid arcade racing games of it’s time.

Right: Burnin’ Rubber for the ill-fated GX4000 (an 8-bit home console based on the Amstrad 6128, released far too late) Burnin’ Rubber is clearly inspired by Wec-Le-Mans, with the majority of gameplay elements mirroring it closely, sadly it’s so sluggish it’s nearly unplayable, the original Amstrad 464 port of Wec Le Mans was a lot more playable! Still, an interesting experience.

Summer Carnival '92 Recca Aleste

Left: Summer Carnival ’92 Recca for the NES – an early game from Shinobu Yagawa, who is better known for his work at Raizing and Cave. The SH3 based ‘Pink Sweets’ takes it’s bomb mechanic right from this rare classic which is every bit as manic as his later games.

Right: Aleste for the MSX. Nowhere near as manic, but interesting to see actual MSX games running in MESS as the offerings based on the hardware in MAME are all a bit weak.

Parasol Stars Dracula X

Left: Parasol Stars for the PC Engine – Many claim this did exist in the arcades, Taito say it didn’t. There were ‘licensed’ but very crude timer-based PCE systems which could potentially run it, but you may as well just run the real thing without an ugly timer tacked on to reset it when you stop inserting coins.

Right: Dracula X for the PC Engine CD – Just to show that CD support works too

Disney's Aladdin Disney's Aladdin

Left: Disney’s Aladdin, the original classic Megadrive / Genesis Game

Right: Disney’s Aladdin, the original classic Megadrive / Genesis Game but with some ugly hacks applied by Chinese bootleggers so that it works as an arcade game. This one is supported in baseline MAME as a result while the original isn’t due to it being a home only game. A great injustice I say.

Metal Slug Metal Slug 2nd Mission

Left: The NeoGeo MVS classic Metal Slug

Right: Metal Slug 2nd Mission for the short-lived NeoGeoPocket Color, a solid adaptation of the game which due to the premature death of the system never really got the credit it deserved.

Bari Arm Bomb Fusion

Left: Bari Arm (Android Assault) for SegaCD… One of those crazy ‘This should have been an Arcade game’ shooters.. developed by Human who did make a couple of arcade games, missed opportunity for sure!

Right: Bomb Fusion for the ZX Spectrum… This one could easily have been a classic arcade, make contact with the various balls which are falling around the screen to have them follow you, and take them to the crate. You need a certain number to exit the level, but all the time there are bombs ticking away which you need to defuse to avoid the radiation level increasing, all while avoiding the other enemies.

Pac Attack Cosmo Gang The Puzzle

Left: Pac Attack on the SNES, Home Only Release

Right: Cosmo Gang The Puzzle… Somehow the Pacman theme of Pac Attack suits the game mechanics far better, a real shame this was the only true arcade version.

Penguin Land Doki Doki Penguin Land Arcade

Left: Penguin Land for the SMS

Right: Doki Doki Penguin Land Arcade, notice how the Arcade version look a lot worse than the SMS version, it’s actually based on older hardware, so much for that theory that the home versions were always just inferior versions with worse visuals ;-)

Puyo Puyo Kirby's Avalanche

Left: The original Puyo Puyo arcade game, running on SegaC2 hardware (derived from the Genesis VDP)

Right: Kirby’s Avalanche, a SNES exclusive adaptation of the game featuring Nintendo’s well known Kirby character. The Genesis also had a similar adaptation using Dr. Robotnik as the lead character. It’s a shame these adaptations never made it back into the arcades really because they’re appealing in their own ways.

While creating these screenshots I have noticed that things like the inputs in the X68000 don’t seem to be working properly (which is a shame because there would be some nice comparison shots otherwise) I need to check if that’s just a regression in MESS, or if I’m using the driver incorrectly, or it’s something MESS specific which isn’t getting compiled quite right in this build. Likewise I was a little surprised to see the BBC Micro not booting because I wanted to put up a Chuckie Egg shot. I’ll investigate those later.

As you can see tho, the code does a reputable job for a good number of the major systems, and while some of the later ones still need significant amounts of work the MESS component of Ultimate MAME does give a good variety of extra functionality to the base MAME emulator, allowing for easier testing of shared components via. a far expanded library of games using them. There is huge potential in such a combined project!

A lot of people who only care about ‘the games’ write off console versions, and old computers as being trash and simply not worth playing, but each and every library contains a good number of gems which can hold their own against any arcade game in terms of gameplay and graphics, and even when they fail to do that they often have their own unique charm and are in some cases of great importance, as I hope some of the shots above demonstrate. Open your mind :-) For the majority of the things pictured above all the code is actually already in baseline MAME, just not being used to it’s full potential there due to the arcade only policy, to me that’s a real shame and one of the reasons I created this build, what’s the point of writing code, and painstakingly testing if it’s then only ever going to be used to 5% of it’s potential in the primary project?

Go to article.. »

Ultimate MAME 0.144

November 15, 2011 Haze Categories: General News. 37 Comments on 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
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.

Go to article.. »

Moving the Goalposts

November 9, 2011 Haze Categories: General News. Comments Off on Moving the Goalposts

While the biggest talking point of 0.144 might be the decision to not include the driver for the Cave SH3 based hardware after what can only be described as a polite request from Cave to not include it just yet this is not something which bothers me especially.

As a result of the work on this driver, even with it removed, MAME has gained significant improvements to the SH3/4 core (over double performance on many of the most common opcodes and a number of bug fixes making it more suitable for other applications), an audio core (the YMZ770) which could lay the groundwork for the eventual decoding of the MPEG audio in games like Star Wars Arcade (it’s very similar) as well as emulation of a number of peripheral chips such as the RTC9701 which combines a Real Time Clock and EEPROM. By comparison the actual gains made to MAME far outweigh the decision to not include the actual driver, the majority of the work I did there was these reusable parts (the SH3, the RTC) and to me it’s the basic component emulation which gives MAME it’s value as a project.

Despite this, I’m once again subject to very personal attacks from a member of the development team for even looking at the driver, calling it irresponsible and stupid, which is really hypocritical when you consider that the very same developer still has a ‘4 Bitcoin’ page offering to write a MAME driver for said system if people pay him! That doesn’t both me too much either, because said developer, despite clinging on to how he’s worked on whatever AAA console games has still only ever made minor contributions to MAME/MESS.

What does bother me is the loss of another feature in 0.144, far distant from the Cave stuff.

In 0.141u1 the Megatech driver was updated to work with the Softlist support from MESS (which is also in MAME by default), in turn this allowed a very clean implementation of the multi-slot technology used by the system in MAME using a standard of code which has been developed over the last few years to a high standard. This was around 10 months ago, and that support has been there ever since.

For the release of 0.144 I was working on the same thing for the NeoGeo MVS, I’d converted the driver to use a software list (with help from the MESS driver for AES which was already ahead of the curve by having support for a software list for many months)

I was coding to an established standard, for something nobody has complained about in 10 months, inline with the way another copy of the same driver already works to facilitate some source level cleanups, and give the option to run the MVS in proper multi-slot mode, with MAME now being the only reputable NeoGeo emulator lacking that feature.

At the last minute, after my submissions were accepted, that’s ALL been ripped out, but not just the NeoGeo list, the entire MegaTech list, the STV list, everything, gone, with only the internal database remaining. The very foundations which I was going to use for Multislot, gone. The existing support for Multislot in Megatech, gone.

Working for Mame lately is like talking to a three headed monkey, one says one thing, the other says another, then the third disagrees with all of that and puts your contribution to waste.

The reason given, apparently the software list standard isn’t good enough for MAME, it should *all* be internal. In essence I’ve been told that MAME/MESS need a *3rd* standard for ROM loading, a sort of pseudo soft-list internal hybrid. Given that this doesn’t exist yet, that means the 5 hours of work I put in already has gone to waste, and there is no actual way forward.

I don’t even think this makes sense, the MESS lists are getting to the stage of being mature, the technology works well, they were ugly at first but as things stand they work well, they’re effective, and for systems with removal media like home consoles, and the MVS they represent an absolutely ideal way of representing the cart content, with better documentation value than hiding stuff in a MAME source file and greater flexibility on top of functionality, for example, you get free namespacing which really helps make things more manageable.

The reasons just seem to come down to superficial stuff, the XML is ‘ugly’ (I agree, most XML is, but it’s a standard) or some false illusion that a list which isn’t hardcoded into the MAME binary has less ‘value’ than one which is, which is utter nonsense because they’re all distributed as part of the same package anyway.

So, the wheel is going to have to be reinvented again, which not only seems insulting towards the MESS developers who have spent 2 years developing and maturing the softlists, but incredibly frustrating to me, because it’s now a progress blocker, and IMHO senseless anyway, the two standards we already have are mature and suit specific use cases well, introducing a third one would just be a step back 2 years and instead of concentrating on improvements to the existing softlist system to allow dynamic adding of CPUs or Dipswitchs functionality is going to have to be added back from scratch and maintained together with the rest.

Such decisions just baffle me, if people had issues with the software lists there has been ample time to raise them, 10 months of the MegaTech driver using them, even longer in MESS, yet now, when real progress is being made, they get pulled?

I absolutely wouldn’t advocate using Software lists for the majority of the MAME drivers, because in the majority of cases it doesn’t make sense, but in some it really does, and considering the developer involved has come out and stated he’s in favour of the project unification between MAME and MESS I can’t really think of many moves which could actually be deemed more damaging than this one in terms of not showing support for the technology developed in MESS.

Maybe all this will blow over, and things will get reinstated, or reconsidered. I certainly hope so, and do have a great deal of respect in general for the developer who has vetoed this, even if I really can’t understand the reasons. The problem is when you consider that the message coming from the top of Mamedev is ‘More Action, Less Talk’ and more action just ends up being greeted with apparent contempt and culling of progress I’m getting very mixed signals which are off-putting and end up making it feel like a risk to write code for MAME, even when things seem like a dead certainty.

The other irony here is that around 13 years ago there was a MAME build I was promoting and helping with called KBMAME implemented ‘softlist’ style loading for NeoGeo in MAME, in a non-xml format which seems to be what some people would rather see anyway. At the time it was met with open arms by the community, and yet 13 years later just trying to do the same thing manages to turn into a huge commotion even when there are clear benefits to be had.

At the end of the day I need a standard I know I can work to, with confidence and that’s not something I consider unreasonable.

*edit* The lists have been restored for 0.144, alongside the internal ones. While I’m not a big fan of the duplication this leads to it’s definitely a more amicable solution until something else is worked out. My frustrations at the original handling of this remain, but I’m glad to see some sanity has been restored ;-) From the looks of things this will be worked out further between 0.144 and 0.145 but in the meantime progress can continue. I do think that this is putting the MAME / MESS merger type stuff at a critical point tho because a solution which is fair to all needs to be found, and applied appropriately and consistently across the drivers of both projects to avoid creating further divides in standards.

Go to article.. »

Fruit Roll

September 23, 2011 Haze Categories: General News. 16 Comments on Fruit Roll

Just a brief update on the Fruit Emulation stuff.

I’ve spent the majority of my MAME time since the last updated (several hundred hours at least) just trying to sort and categorize the various sets that are around, figuring out the hardware, splitting things into appropriate clones, identifying cases where there are missing roms etc.

This has proven to be an incredibly time consuming task, not least because of the sheer volume of sets and variations on sets which exist. You’ll have seen in the last couple of updates there have been a lot of fruit machine romsets added, then renamed, split out, and reshuffled in cases where things were just completely misidentified before they were looked at for MAME.

It’s not really what you’d call a glamorous job, but it’s one that needed doing, as proper set support underpins any further work done in MAME, so despite no real visible progress in the emulation simply doing this is a huge step forwards towards eventually seeing the machines supported properly in MAME.

I know some people cited the monumental nature of this task as one of the reasons why FME would never happen in MAME, saying you’d need an army of people to compile such a database, I guess the reality is you either needed an army, or just one person severely lacking in sanity. Thankfully MAME had me ;-)

The majority of sets have been added now, so the number of *new* fruit machine roms added from this point in any single update should be rather small, although there is a lot of sorting and splitting to be done, which may give the illusion that a lot more is changing than really is. To begin with there was in the region of 5-6GB of sets to look at, I’m now down to around 50MB of stuff which isn’t identified by the latest MAME at all.

The good news is that even if I get hit by a bus tomorrow nobody is going to have to repeat this part of the work.

Go to article.. »

Stupidity in Moderation

August 2, 2011 Haze Categories: General News. 33 Comments on Stupidity in Moderation

Give me one good reason why this helpful post I made was deleted?

Compiling MAME from scratch can take near on an hour. I suggest 2 lines to change it, and achieve the same in 5 seconds, thus making testing a LOT easier, and it gets deleted. That’s how paranoid the mods over there are over MAME and MESS being associated with each other, and the reality that they’re exactly the same thing.

Deleted?

Really, I’m 100% serious, that was deleted. It’s indefensible. I think China has more freedom than this, yet they claim it’s not political? That was an entirely legitimate way of helping. Next step they’ll probably make that impossible just to spite everybody. I’m trying my best to help MAME, even metaphorically sell it to new potential developers and users (a big part of the FME push below is for that purpose), but this kind of crap WILL drive legitimate contributors away.

This is also why forking would be impossible, it would be censored in the same ways, then declared a failure.

Go to article.. »

I see today with a newsprint fray, My night is colored headache grey

July 25, 2011 Haze Categories: General News. 78 Comments on I see today with a newsprint fray, My night is colored headache grey

MAME has been doing a good job of emulating several video based slot machines for a while now, for the most part they’re easy enough tech to get going and if anything the more simple ones can be a pretty good starting point for understanding how to write a MAME driver. They have a few idiosyncrasies associated with them such as the need to simulate payout hopper hardware which doesn’t apply to most arcade games, but for the most part they’re just like anything else.

One area that’s lacked attention in recent years however is the non-video based gamblers, which have been prominent in UK arcades since the 80s, and are in many ways just as iconic as any other classic video game. The 80s and early 90s machines especially had memorable melodies, and art, attractive patterns of flashing lights and were clearly developed by people who were interested in creating an experience that was not only about winning money, but also having fun, something which really set them apart from the majority of gamblers produced outside the UK, and the very methodical design of most video based ones.

There’s no technical reason MAME can’t emulate these, and emulate them well, there are a couple of potential problems I’ll talk about later, but essentially they’re just a bunch of off-the-shelf components stuck together. The machines are in part mechanical, but really things like the fruit machine reels can’t truly be considered any more mechanical than the various input devices MAME supports, they spin under the control of the program, and their position can be read back.

As a matter of fact, MAME is so adept to emulating these things that the basic codebase (CPU cores etc.) of one of the more popular existing emulators was ripped straight from an older version of MAME, as shown by a source leak. Source leak? Well yes, the emulator is ‘closed source’ in complete violation of the MAME license, although people had suspected it stole MAME cores for a long time even before the code was leaked. The MAME license is very clear, and always has been, that if you derive something from the MAME code then the source must be available. A fair number of people have come down like a ton of bricks on the author for not abiding by this, and deservedly so, based on what’s been said the team would be well within their rights to take legal action over it, especially as if reported by some, it was also previously sold.

My take on this is quite simple, as long as the author agrees to release sources to any future versions as per the license agreement I don’t mind too much about the past, finding the old source trees at this point would no doubt be rather tricky. I do applaud whoever leaked the previous code to prove it wasn’t entirely an original piece of work however.

I’d also say that just because code was stolen doesn’t detract from the work put in to actually emulating the machines. Sure, without the MAME cores the project may never have come about, and sure, any findings should have been shared back by keeping the project open, but there is still real work involved in emulating the systems. If everything automatically fell into place MAME would automatically emulate systems be emulated as soon as there was a CPU core, which simply isn’t true. Furthermore work would have still been needed on some of the cores because the fruit machines in several cases used variants which weren’t supported in the cores (although again, such fixes should have been shared back via the project being open)

Anyway, with that said, it is about time MAME started paying more attention to these things, with, or without others co-operating. In MAME terms all these things are simple systems, and there is very little reason they shouldn’t be emulated. One of the most complex parts of emulating a system is usually the video hardware, and these have none, their video is 100-200 lights which illuminate actual artwork on the cabs (you could picture the lights as the video hardware if you wanted, but the actual workings are rather different)

The only game that really runs in current versions of MAME is ‘Dr Who’ You can see an example of this being rendered in MAME with external artwork, using the artwork system at http://maws.mameworld.info/maws/romset/m_bdrwho (Click ‘artwork’ next to Mr. Do)

MAME’s artwork system, as you can see, is perfectly capable of rendering such a display, and without the artwork you get a fallback to the internal layout (which in the case of these is a grid representing the lights, handy for debugging) Some work is probably needed to make the reels scroll more smoothly (they’re rather hacked in at the moment) and a layout editor would be handy (done by hand at the moment) but in reality there are no real showstoppers in being able to represent the display, in fact it might even become feasible to write a program that converts the already extensive collection of layouts created for other emulators to work with MAME (I haven’t studied their formats and requirements yet)

The only other real caveat I can think of in terms of MAME is the timer system, I’ve noticed with the existing drivers that some set incredibly high frequency timers, especially when playing samples, this unfortunately can cause MAME to run like a dog due to some pretty severe flaws in the design when it comes to this use case. Not everything is affected, but some are.

In terms of emulation the games can be incredibly finicky, testing the hardware extensively, and outright refusing to run if they detect a fault. Naturally this comes from the requirement of the original machine to be reliable, and often secure ways to deal with regulated payout amounts etc. As long as things get emulated properly this isn’t a real problem though, just extra work.

In terms of what’s dumped, it’s a mess. You can find dat files documenting fruit machine ROMs, but for the most part things are poorly sorted, give no indication of hardware, have multiple hardware revisions within the same sets, and even have things which are completely misnamed. Furthermore, even beyond that many sets are just plain incomplete. I was looking at the Epoch hardware stuff and out of ~150 games only in the region of 4 actually have sound ROMs dumped, and for other systems the only complete sets are in many cases non English versions. We’ve already seen this problem even with a large number of the video based games in MAME, missing question ROMs and such.

To make matters worse the community built up around the existing emulators seems to have a philosophy of ‘find a set that works and stick with it’ yet in many cases these fruit machines have multiple clones, for different payouts, different regions, in addition to bug fixes. One game I counted has in excess of 100 clone sets and the majority of these are completely untested, and some have been obviously hacked just to add insults towards people in. People seem to have attempted to make up for missing sound ROMs by substituting them with others from games which usable, but still wrong sound, and in some cases it appears where only sound ROMs were dumped, substituting missing program ROMs from games with similar gameplay. Sorting them out is going to be a complete nightmare. To make matters worse some of the emulators appear to have adopted a console ROM like format for some of the MPU5 hardware games, requiring correctly split ROMs to be merged into a single file before they work, creating further confusion.

From a documentation point of view it’s a tower of neglect. It’s going to take years to sort out, and while I *greatly* appreciate the efforts of the people who have attempted to make dats for these things (I’m sure plenty has been saved from being lost as a result and it has saved me an enormous amount of time) there is still a ton of work to do. To a degree it’s understandable, it’s hard to categorize things which don’t work, if you’re lucky the games contain the title in plaintext somewhere in the ROMs, but many of the earlier ones don’t. Without being able to run the code it’s not always obvious what hardware things are, although there are usually hints based on code / data structure and that kind of thing.

Where is this leading? Well, I’m not a huge fan of these games myself, but part of being involved in emulation development is keeping a level of impartiality, if as a developer you only work on drivers for games you like then you end up being rather limited in what you can do, so, I’m putting into action a plan to at least try to sort some of this out.

As a first step I’ve created skeleton drivers for the common platforms, these really don’t do much yet, but they act as placeholders.

Secondly, I’ve started trying to identify each and every set I can identify, and move it to the appropriate skeleton driver. For the initial pass I’m lumping all the clones in the same set (they’re too unwieldy to sort at this point) but splitting out anything which is obviously mixed in with wrong set, and adding precursory comments where things appear to be missing or bad, to mark in the correct way later.
Obviously some games are on unique hardware, like anything else, and with no hardware information these will be tricker, but I’ll come back to them at a later date. Some of them are clearly things like CD jukebox ROMs and even one for a VHS player anyway, so are more likely to be put in MESS at some point if anything.

Identifying the ROMs is as much about looking for common structure at the moment, obviously for already emulated stuff there is a guide, if something is running in an emulator already, it becomes rather obvious what hardware it is. 68k and H8 code can be identified by a large quantity of certain hex values in the code, which is good for splitting Impact and Epoch apart. MPU5 stuff tends to all have a similar vector table, 68xx stuff (usually MPU3/4) has vectors at the end. Maygay M1AB hardware always has a MayGay copyright string just before 0x10000. Bellfruit stuff has very specific encryption patterns. The 3rd party stuff is often hardware, especially on the earlier systems as it’s quite obvious some of it was developed by reverse engineering the hardware from scratch, and thus doesn’t conform to the same standards.

After nearly a week of having myself locked in this room and doing nothing else this is where we stand right now anyway. I’m going through this process, and several of the main systems have comprehensive preliminary lists. At this point many things are probably named incorrectly, there will be duplicates, there will be bad dumps, there will probably even be things I’ve misidentified, but it’s going to be a long hard slog. A few things do actually boot, especially MPU4 games, but most fail on the characterizer (game specific PAL), or reel errors, because of variations in the hardware attached. For the more complex systems there is extra hardware still to be emulated before they even start to do anything so the skeleton drivers really are just that (eg. MPU5 uses a variation of the 68020 called the 68340, which has extra timers and DMA)

Once things have been sorted, and the majority of valid looking sets placed somewhere, then a more focused effort on emulating the hardware can take place. No particular rhyme or reason exists for this stage yet, it’s going to depend on what seems the most viable, what can be broken down into smaller chunks and tackled most easily. I imagine this stage is likely to be when sets start getting split out into clones better, as the differing requirements in terms of extra hardware of each of the sets will become more clear as emulation processes (many expect data recording devices, some variations expect jackpot / percentage keys attached, while others work with dipswitches etc.)

Progress will also depend on exactly what degree of burnout is being felt over these things at that point. As things stand I’m doing this pretty much on my own, just bouncing a few questions off people to clarify one or two things. Many of these systems are ones where external contributors could become involved, as I’ve said near the start of the article, they’re all just combinations of off-the-shelf hardware, so emulating them shouldn’t be too difficult, but rather require a good understanding of how the components should work.

In the end, if MAME can do a good enough job on these things hopefully we’ll see many benefits. First off, the petty arguments which seem to dominate the Fruit Emu scene would be done away with, for all the problems with MAME none sink quite that low. You’re guaranteed the source, and guaranteed a complete knowledge dump of everything the developers involved know, no holding back of information and such. Hopefully all the nonsense with the other emulator and stolen source will become irrelevant as MAME obsoletes it anyway.

Secondly, these things will hopefully end up being properly documented, that’s going to take a long time, but the framework exists, the MAME database is a great place to make a permanent record of what’s what. Right now there is no central point of knowledge for these, neither in terms of the hardware, or software, even Googling the names of many of the machines turns up nothing which is worrying when you consider a key part of all these machines was what they looked like!

Thirdly the emulation of many of the components used will improve, as I’ve said earlier, these things can be very fussy over the hardware working correctly, and will provide some excellent test cases.

Forth, it could lead to improvements to the MAME artwork system, more flexible custom elements for things like the reels. I know one day I’d still like to see full 3D cabinet support in there and these would be a perfect showcase for something like that if it ever happens.

Fifth, MAME is the ideal platform for emulating the one-off obscure boards, the majority of components you need to work with are there already, you don’t have to write (or steal!) CPU cores and sound cores just to quickly test what hardware something is, you have things at your fingertips for testing, so hopefully it will lead to many of the more obscure machines being emulated in some form too, even if finding the artwork for them will be another challenge entirely.

Sixth, MAME is a platform anybody can contribute to, the compile tools are always freely available, and getting it to build it literally a one-stop process. Nothing fancy is required, if *you* want to contribute to fruit machine emulation MAME allows you to.

On closing I should stress that none of this is magically going to happen overnight, the underlying message here is that there is a lot of work involved. I’ve been up all night, and asleep half the day, every day for the past week just trying to make headway into this, yet I know as soon as the next MAME update is out somebody is going to slag off the addition of these sets, because either they don’t care about them, or because nothing actually works yet without even considering the work that has gone into it so far.

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