David Haywood's Homepage
MAME work and other stuff

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.


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.. »

I said: “We went to the moon and now we’re watching these buffoons?”

July 7, 2011 Haze Categories: General News. 26 Comments on I said: “We went to the moon and now we’re watching these buffoons?”

MAME has emulated a Korean bootleg of Sega’s Fantasy Zone 2 remake for a while now. Given the title of ‘FZ2006 II’ and released as part of a Korean multi-game bootleg by ‘ISG’ it appears to make use of the data files from the Sega Ages Fantazy Zone collection, released for the PS2 in 2008, with various hacks applied (different memory maps + their own protection and such)

Anyway, this bugged me a bit, so I’ve come up with a tiny build of MAME which can run the same game but using the original data files from the PS2 disc, to use this you must simply get your PS2 disc, copy the ‘BIN.PAK’ file from it, and place it in a zip called fantzn2x.zip and run the custom version of MAME linked below using that. I’ve done the same for Bloxeed, because it looks like their bootleg of that was also sourced from one of the PS2 versions.

These obviously aren’t going to make their way into the official version of MAME in this form, but it’s less annoying than having to use a bootleg with hacked title screen and copyrights etc.

Original Sega Version – left ||| FZ 2006 bootleg supported in MAME – right

Fantasy Zone 2 (System 16C) original version FZ2006 bootleg

Fantasy Zone 2 (System 16C) original version FZ2006 bootleg

Quite why the bootleggers called it FZ2006 and used a 2006 copyright when it appears to be based off a 2008 PS2 release I don’t know, but Sega were no better really, stamping a 1987 copyright display in the attract mode.

This is based on the latest MAME sources (0.143+), but with most stuff stripped out. Download Here

Article title associated YouTube Video (The Eisenhowers – 1969, nothing to do with the actual update, I just happen to like it)

Go to article.. »

She can get up, shower, and in half an hour she’d be gone

June 8, 2011 Haze Categories: General News. 41 Comments on She can get up, shower, and in half an hour she’d be gone

As my involvement in MAME continues to wind down I’ve decided to make a fresh start to this blog.

I wanted to do a summary of all the things in MAME which I’ve been involved with, but the list was monstrous and quickly became unwieldy. I think I must have been actively involved in development on at least half of the supported titles in MAME in some capacity, be it writing the drivers from scratch, rewriting drivers based on new information, acting as support to other people, or simply fixing bugs in existing drivers when adding new supported sets and/or games.

While the overall structure of the project has changed a lot over the years MAME will always be judged on the functionality it provides to the end user, the history it has documented, discoveries, and the proof in the implementation, looking through the project it still lives and breathes work I’ve done in these areas, summing it up is simply impossible not to mention unfair.

Unfair? I’ve never been one to want to take credit for things I haven’t done, in fact I’ve often worked without credit, just to get things done, to help out, make things better; the project is, and always will be one of near unrivaled historical importance which is far more important than any personal gain from it. It’s also important to understand with emulation that you’re always working with things which have been created by other people. The CPU cores for example are an area I’ve had minimal involvement in (mainly just bug fixes when needed), yet without them almost none of the things I’ve emulated would have been possible. Claiming absolute credit for anything in emulation is just wrong, at least if you’re a team player in the project.

I might revisit some highlights here however, some reflective insight into the highs and lows of the last 11 years of my contributions to MAME. I’ll probably still work on a few MAME things as well as posting about other things which interest me here, there’s definitely at least still the early Semicom / Jeil / Cheil game ‘Brixian‘ to come at least!

I’ve previously stated my honest opinions on the direction I feel the project should head, some have agreed with that, others have disagreed, I’m still fairly certain things will end up exactly as I’ve outlined, the time period remains indefinite however. Along those lines, for anybody wanting to have access to the bleeding edge official MAME/MESS distributions (much more up to date than the u releases) I’ve added a little page which explains how. Maybe that can encourage development a little, allowing people to mirror and host daily builds, but I’m doubtful at this point.

I do wonder exactly where things go from here with the project in the short term. The things I’ve highlighted in previous posts there has been little interest in (I plan a recap on that at some point), but if I was a betting man I’d probably say something like Namco System 10 was the most likely next significant system to be emulated, after all, it’s just a Playstation with some protection, nothing fancy. Beyond that it’s just tumbleweed; promising progress shown on drivers for 3D systems which ultimately get abandoned or never submitted, things nobody is interested in working on, and a couple of others which are decidedly too hard, or simply impossible. MESS is still the most likely source of real emulation progress, and advances in shared systems could be the main source of progress in MAME going forward, the recent advancements in PC emulation thanks to some external contributions could help pave the way for some PC based arcade systems, although the 386+ protected mode emulation still needs significant work before that happens.

Speaking of MESS, you may notice the HazeMD stuff isn’t hosted here anymore. It’s obsolete. MESS is still using a version of my Megadrive / Genesis driver to which I’ve made many fixes since the last HazeMD release, and with the Software List support the internal database from HazeMD is already fully covered in MESS. With the latest MESS you can also take advantage of new features like the recently added HLSL shaders to give a more authentic looking output, so it makes more sense to use that. The purpose / goal of HazeMD was complete, and the only real advantage HazeMD had remaining was the old cheat system, and maybe better compatibility with some legacy hardware.

This is not the end, merely a new beginning.

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.