I’m going to write this and post bits in real-time, keep having ideas for something like this, but never finding time to lump them all together

Boulderdash, some say it’s a genre in it’s own right, something completely original which sprung out of nowhere, but is it?

Both Dig Dug, and especially Mr. Do offer almost exactly the same digging tunnels experience, and the same basic boulder falling / crushing mechanics, right down to the boulders only falling once you move away from directly underneath them.

While the gameplay is Dig Dug has different objectives Mr Do. even sees the primary goal as collecting a number of items in the level in order to clear it.

Then you’ve only got to look at something like The Pit, which came out before even either of those, has the digging mechanic, boulders, and even has you picking up diamonds as well as the maze-like structure and ‘which is the safest route’ puzzle mechanic a good 2 years before Boulder Dash surfaced.

So, hardly an original game really is it? It’s just a combination of existing elements, a natural progression onto a larger scrolling playfield, and some further tweaks to the game rules (falling collectibles, rocks which stack up instead of just breaking)

That said, I like Boulder Dash, and when I look at the Arcade conversions of it I can’t help but feel they leave a lot to be desired.

First up you have the Max-a-flex version. This is the original Boulder Dash game by First Star Software, the Atari 800 version to be precise. The problem is it’s *too* much the original game. It hasn’t been adapted for arcade use at all, it merely has a coin based timer bolted on which doesn’t even have a proper display connected to it. It’s not a real arcade game at all, just a lazy port which cripples a perfectly good version of the game into being time-based rather than skill based, because no amount of playing skill can stop a fixed timer from expiring.

Then you have the two Data East versions. The first was released on the obscure Deco Cassette System, it’s painfully slow, has laggy controls, very ordinary graphics, and poor scrolling compared to the Max-a-flex version. Overall it’s just not a great deal of fun to play. It’s a real arcade game at least, but not a very good one, especially not for 1985.

The 2nd Data East version was released 5 years later and is the only proper 16-bit arcade version of Boulderdash. The game looks a lot better, but again it just feels rushed, for lack of a better word. There’s a lot going on with the graphics, a fake 3d look to the blocks, you even have a map in the corner, but then there are odd choices too, like the scrolling clouds in the background, what sense does that make? Also things like the scoring system haven’t had any thought put into them at all, the ‘high score’ table actually just shows the scores of the last couple of people to play the game, it isn’t an actual high score table at all! It’s not the *worst* version I’ve played, but I really don’t like the mazes (too many small, pointless levels and ones which just seem closer to a random spray of objects) and the graphical modernizations do nothing for me at all. It’s fairly fast, and has a good variety of enemies, although things like the fades are badly programmed and look ugly even on real hardware (again pointing at it being rather rushed) It’s just one of those games you’re left thinking could have been a LOT better.

Then we’re left with the Kyle Hodgetts efforts; Diamond Run, Dangerous Dungeons (plus the bootlegs Toffy and Super Toffy) and the unfinished Diggerman. Kyle is generally known for his god-awful conversions of other games, his god-awful redemption games, and a couple of other unspeakable titles, but it looks like he noticed the same thing, a lack of good arcade verisons of Boulderdash.

His first effort is Diamond Run from 1989, a conversion of Ghosts and Goblins, which retains the G&G music giving for a rather odd sounding Boulderdash clone. The game is slow, and ugly but throws in some nice ideas from the very first level, ultimately it just becomes too tedious to play tho.

Dangerous Dungeons was the follow-up, this time a Double Dragon conversion. Released in 1992 it’s actually the most recent of the released Boulderdash games (if you don’t count the Korean hacks of it) The graphics have been touched up from Diamond Run and the gameplay is a lot faster, and while it is still very much an 8-bit game with 8-bit graphics it does play faster this time around, although it’s not perfect. Like Diamond Run it has various elements not present in the original game, you start with some sticks of dynamite you can place to blow things up bomberman style, and there are encased diamonds which must be hit by a rock before they can be collected. The bootleg Toffy is almost identical with a changed title screen, while Super Toffy reworks the graphics again and adds adult cutscenes! Of all the Boulderdash arcade games this is probably the one I enjoy the most, but again it’s a shame it’s so slow, and unpolished looking, especially for a 1992 game but the Double Dragon hardware was rather awful, just look how slow the original game is!

The final KH game is Diggerman, although it’s generally considered unfinished, and unreleased despite widespread availability. As a result of this you’ll reach levels which can’t be completed fairly quickly. Again it builds on Dangerous Dungeons, offering basically a cleaned up, faster version of the same game. The was based on the NeoGeo platform, and uses Face’s Gururin as a base which is no doubt why you main character is taken straight from that. It doesn’t really feel like a 16-bit game, and considering it was scheduled for release around 2000 it looks even more dated for period than many of the other efforts.

So despite the early roots I don’t really think the ‘Boulder Dash’ style of game has ever been well represented in the arcades beyond those initial incarnations of Dig Dug and Mr. Do which are both timeless classics. Understandably having to update an entire full level of boulders and diamonds falling everywhere is a significant amount more strain on an 8-bit system than knowing you’re only ever likely to have one apple / boulder falling at a time but even basic things like the presentation values have been sorely lacking.

For the KH stuff that’s understandable, they’re effectively indie games in the arcade, at a time when arcades were big-budget but the Data East stuff is a real shame and a missed opportunity to create something really special.

The most surprising part is how huge both games were on home platforms; Boulder Dash was ported all over the place, the Spectrum had several official versions, a level editor, and numerous other packs available for example and the game was a staple ‘must own’ game for most 8-bit computers, as well as being available on 16-bit machines such as the Amiga and Atari ST.

The games also had huge communities around them, with many unofficial versions springing up. My personal favourite on the Spectrum was one called ‘Earth Shaker’ which started life as a game sent in by a magazine reader, then ended up on one of the Covertapes. It’s apparently also had an XBOX 360 release in 2010, although I’m yet to try it because I don’t really like buying non-physical games and it’s digital only. Earth Shaker was fun because it threw many additional elements into the mix, and compared to many Speccy clones of Boulderdash ran remarkably well, looked good, and even had decent sound effects / music. Levels not only had your usual dirt/rock combinations but also Bubbles, Fire and many others which gave the game great variety, it was also a real challenge like all proper Boulderdash games!

Rockford can be considered the official sequel to the game, and was released on many platforms, including the Spectrum which was a very playable port, capturing a good sense of speed, it supposedly had an arcade release, but that’s never surfaced and I don’t hold any hope of it being good quality because it was meant to be on the Amiga derived Arcadia system, which is another of those which cripples your game by time, not skill (and worse still, the maximum allowed playtime is set by the operator on those games)

Speaking of the Amiga you ended up with PD libraries with sections dedicated to custom maps for the game ‘Emerald Mine’, and while that wasn’t my favourite Boulderdash game on the Amiga (I always preferred Balder’s Grove) it shows again that there were a huge number of fans of the game.

For some reason the game never made an appearance on popular consoles like the Megadrive, and while it did appear on the NES it seems like another wasted opportunity to produce a high quality 16-bit version of the game.

Recently there have been more versions and more ports of the official game than ever, so at least things are making sense now, although the lack of a genuinely *good* arcade version is something history will always show as missing and that I feel is a real surprise, and a real shame.

There are many one-off, often obscure games which you play and think would have made great arcade games, but few as popular yet never perfectly captured.

Kittens surely works better, but IGS didn’t make any games called Kitten World, so Dragons will have to suffice.

Anyway, Dragon World 2001, and Dragon World Pretty Chance are the subject here, both of which are now emulated.

Dragon World 2001 is the 4th major installment in the Dragon World series from IGS, and Dragon World Pretty Chance is a modified version of the same game with adult themes and a background revealing mechanic.

Like the rest of the series these are Shanghai style games (not Mahjong! even if they can use Mahjong tiles) with various special powers to help you get through. Not amazingly original, but there you go.

The ARM sub-cpu data has been extracted so that the sub-cpu can be emulated. Compared to DDP2 there isn’t much of it at all, only around 1kb of the internal space is used but it was still essential to get the game running correctly. Both DW2001 and DWPC use identical internal code. These were the last ‘easy’ PGM games to emulate, the remaining ones still don’t have a clear way forward.

With the exception of maybe the original Dragon World these should now be the best emulated in the series because Dragon World 2 still has lingering protection issues on some sets, and Dragon World 3 / 3EX doesn’t really work at all due to the protection use there (not primarily 027ARM based, could probably be figured out by studying the game code)

Here are some screenshots and videos, viewer discretion is advised with the Pretty Chance video, although I’ve tried to make sure nothing too sensitive is included (I suicide before too much is revealed) probably best not viewed at work tho :-)

Dragon World 2001

Dragon World Pretty Chance

logo by ALEXGIZH

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

As of 0.146 the UME target is officially provided in the MESS development tree, however the teams have opted at this time to not supply binaries of the build on the official site(s) so instead I’m supplying them here and dealing with support for them.

The builds here are produced using unmodified code from the MESS SVN repository which contains the latest code for both the MAME and MESS projects. As part of the unification the teams will be moving to a single shared SVN in the near future, although the projects will still maintain their separate identities and distributions, including this one, the UME build.

For the end-user UME allows a user to unleash the full potential of both the MAME and MESS projects from within a single convenient environment, using common configurations. It is designed to demonstrate how close the projects already are while providing an introduction to MESS and how some more advanced features of the project which MAME doesn’t utilize directly are used.

Why Should I Use UME instead of a regular MAME/MESS build?

No functionality from regular builds has been removed, so even if you don’t make use of any of the additional functionality you’re not losing out by using UME instead of a single project. Beyond that you have access to a whole new sub-set of platforms. For example you can quickly launch either the standard NES version of Super Mario Bros. the Playchoice 10 version, or the VS. System version using the same application which you’ve already set up and configured. The main added factor is convenience.

From a development perspective you have instant access to the components which exist in both projects without having to move code around if you’re simply interested in doing some quick tests. You also have access to a more flexible range of software and test cases for common components within a single project as well as a greater level of awareness over component reuse between the projects. This should allow for greater testing of code and hopefully reduce the chances of accidental duplication.

Why Should I Use UME instead of MESSUNI (another recent combined build)?

MESSUNI is what I like to call a discriminatory build. It is billed as a combined binary, but actually strips a large amount of both projects out merely based on flags and personal preference of the developer. Any seasoned MAME or MESS user will tell you that there are many things flagged which are actually usable to a good degree because flags are often used as a precautionary measure, especially in MESS where you have systems where several hundred games may function correctly on a system, but likewise many may not, so the flags remain.

Furthermore MESSUNI is built on the MESSUI code, which in turn is based on the legacy MAMEUI code. I’m aware that this is preferential to people over the commandline but the code has been rotting for years and introduces numerous stability and usability issues which will degrade the overall experience of using either MAME, MESS, or a combined build. The current recommended way to use the emulators is with the QMC2 frontend, which should support the UME build shortly.

Where Can I Download UME?

I’ve combined both the source, as well as 32-bit and 64-bit binaries into a single downloadable package HERE (61.8 MB). Tools have been moved to the ‘tools32’ and ‘tools64’ folders after each compile.

These are compiled with ‘gcc version 4.6.3 (rubenvb-4.6.3)’ on a Core2Duo system. The official MAME / MESS toolchain will probably be migrated to that toolchain, or one close to it shortly.

What’s New in UME?

UME 0.146 contains *everything* from MAME 0.146 and *everything* from MESS 0.146 please refer to the relevant what’s new lists for each project.

To be more specific it’s based on MESS SVN 15264, which is slightly newer but adds a fix which allows the tools to compile without error.

Everything?

Ideally everything, yes, although due to an oversight the megatech.xml and stv.xml software lists from MAME are not in the MESS SVN tree despite being in shared folders so are currently absent. That isn’t an issue however because the primary method of launching these is with the internal setlists anyway. This will most likely be resolved once the official development teams are sharing an SVN.

When Shouldn’t I Use UME?

UME shouldn’t be used for reporting things to Mametesters, doing so will result in lots of angry developers chasing you with cattle prods. If you encounter a bug in UME you should verify that it occurs in a regular build too. There is no reason why a bug should be specific to UME, but it makes sense to check first.

Future Plans for UME?

I’ll make an effort to put out a build for each ‘u’ release (as long as I feel the overall ‘u’ release is stable enough) as well as each final release (which should be stable..) People are welcome to compile and post their own builds, especially for non-Windows platforms as I’m unable to supply those myself.

Anything Else?

I’m currently undecided over setting up a new sub-page for UME builds, or just posting them as part of the regular news stream here.

As of MESS SVN revision 15179 the UME (Universal Machine Emulator, aka combined binary) target is present in the MESS SVN tree
(mirrored on the GIT too)

This target can be built using the command
make TARGET=ume
(or make -j6 TARGET=ume if you want to use more cores when compiling)

Hopefully people will remain open minded about this target, and it doesn’t become some sort of taboo subject.

There might still be some issues with building the tools which need cleaning up (windows specific hacks which things like wimgtool depend on, but exist only in MESS) but as far as a working combined binary goes you should be good to go with that.

As I’ve stated I will provide these binaries for the next major release synced to the point of whichever release comes last (MAME/MESS) (the projects are usually synced at each others release points anyway)

For day-to-day use the MESS tree isn’t 100% synced with the latest MAME developments, but usually gets synced up within a day or two, so it isn’t usually an issue. There will be an eventual move to a new server where development of both projects will take place, and I’d assume the target will be carried over when that happens.

As I’ve stated elsewhere the main advantage of this solution is convenience, if you’re running MAME anyway you may as well be using UME instead. That way if you ever get curious about how something else runs on one of the consoles, or just use the project to it’s full potential then you have that option already at your fingertips. The quality of the MAME emulation is the same as always, and the integrated MESS emulation provides a ‘good enough’ solution for many computers / consoles which could save countless hours in setting up and learning a completely different emulator if all you want to do is quickly test something in a familiar environment. I’m not going to lie and say MESS / UME is currently better than the standalone emulators, but it can be a heck of a lot more convenient if you’re already familiar with MAME and don’t need all the bells & whistles offered elsewhere.

I hope this does eventually increase exposure to the MESS codebase for people who might have been weary to try MESS otherwise, I fully understand that not many people are going to want to actively search out MESS on it’s own, but if you already have the code in the binary you’re using anyway there is nothing to lose by trying it as a first option and in many cases it will be just fine. Obviously having it as an alternative build doesn’t quite have the same impact as having it as the main build, but hopefully people will see that they have nothing to lose by building this target, even if you just ignore the MESS side of it completely!

I’m assured by various people that proper support in the QMC2 frontend will be available with the next major release too, so again that’s one reason I’m not supplying binaries yet, although I imagine the QMC author can take the addition to the MESS tree as a sign that the UME name / configuration is final now and put something out :-)

Personally I find it pretty cool to know that I can run the Genesis version of Sonic using the exact same codepaths in the emulator as the Megatech version (just sans the annoying menu), and in addition to that use the very same code to run the majority of the Genesis library rather well. Likewise I can compare ports easily, and really have a whole new world to explore without leaving the confines of the emulator. It’s also good for seeing how solid the emulation code used for a number of MAME systems is when exposed to a larger software library, and thus building (or destroying!) confidence in the accuracy levels of MAME for those systems or understanding how well the Arcade games on the platform actually utilized the hardware compared to the more general software library. It’s an adventure of knowledge and new discovery.

As I said, I’m not posting binaries yet, although I won’t stop people posting them! (I’d love to see others taking the idea and running with it) but this is just a heads up to the ongoing progress really.

I’d like to thank Micko (current head co-ordinator of both MAME and MESS) for checking in the target (and in fact being responsible for the code which has allowed this 100% clean solution in the first place) I hope people enjoy it and make use of it.

No, not clones as in alternate versions of the game, but clones as in a million clones of all the Street Fighter 2 characters attacking you for hours.

Maybe the idea of Street Fighter characters in a side-scroller isn’t a terrible one, but after the 1,000,000th time you’ve killed a palette swapped version of E.Honda it kinda drags on a bit, especially when the game offers absolutely nothing but hours of repetition.

There are good beat ’em ups, and there are bad beat ’em ups, and then there are beat ’em ups which are physically painful to play because they’re so badly designed. This game, known as “Jue Zhan Tian Huang” is definitely the latter. The entire game consists of either 4 enemies on screen at a time, all being clones of Street Fighter 2 characters, with seemingly random amounts of health, and an occasional boss fight against cyborg type enemies and a token SF2 character who will respawn until the boss is dead. There are no weapons, there appear to be 2 types of destructible objects throughout the entire game. The background are as generic as you can get, with an unhealthy liking for lift levels, it’s buggy, feels half finished in places, and will have you screaming ‘stop, stop right now’ by level 4, but luckily for you there are 8 levels broken into even more stages.

The game is also full of foreground elements which will obscure your view, some of the train levels mess with your eyes in ways which make you feel like they’re going to fall out by rapidly scrolling the foreground and background leaving you with what can only be described as a grid like pattern through which to view the action.

The hardware is Megadrive / Genesis based (the same board as Puckman Pockimon) and had the game been based off the Streets of Rage code it might have been good, but it looks like this is an original creation, or at least if there is any Streets of Rage code in there it’s so well hidden behind poor design you’re not going to notice it.

Here are some screenshots, including the ending, or at least I hope it’s the ending. There are protection checks throughout the game so I had to play until the end to make sure things were working. There’s a sound bank needs hooking up too, but the samples are so poor I’m not sure what’s right and wrong.

This could possibly displace Dragons Lair as the worst ever arcade game I’ve played …. I’m not making a video because that would involve playing it again.

Thanks (I think) to Yohji, Mr. CAST, B. Stahl, Smitdogg, The Dumping Union

The thing with Fruit Machines is that aside from the cabinet design, artwork and a couple of features they all look pretty much the same on the outside. Basically they have a bunch of lights, a number of reels usually 3+, some 7-segment digits for displaying credits and possibly a VFD / Dot Matrix Display for some additional text / graphics. Once you’ve reached the point of ‘Sample Playback’ You’re not going to see much difference in the sounds either, samples are samples.

That said there has been a clear progression in the technology too, just like video arcade hardware which I’m using to influence my decisions over what to work on. Basically the way I see it there are the following groups (Systems which are already emulated in MFME or other emulators are highlighted in BOLD, which is for the most part the same state as 6 years ago, ouch)

Very Old, Non CPU Hardware

This is the equivalent in Fruit Machine terms to Pong, no CPU, nothing to ’emulate’. Information I have on such systems is sketchy, so I don’t have a list of such systems (it’s possible they were custom built anyway) I’d guess these are entirely romless, because you’re not going to have a display either.

Early 8-bits

These are your Space Invaders equivalents, early techs using 8-bit CPUs, usually fairly basic setups, simple sounds etc. Growing industry starting to use CPUs offering solid ‘no-frills’ machines.

BFM System 83, BFM System 85, JPM System 80, JPM MPS(2), MPU2, MPU3, Original Electrocoin Bar X, Ace System 1, Maygay Triple M, Hazel Grove?

There are also some early ‘JPM’ games on unknown platforms.

Later 8-bits

Probably your ‘Golden Era’ there were a large number of manufacturers putting out platforms at this point, or refining the ones they had and reissuing them. I’d say these were your equivalents to the likes of PacMan, hugely popular machines which many people consider to be absolute classics. Linked boards also started appearing.

MPU4 (reminds me of Scramble, everybody rushing to get their games on the platform!)
Scorpion 1, Scorpion 2, Project Coin (ProConn), Castle, sp.Ace system, Maygay M1AB, Electrocoin Pyramid HW & revised BarX hardware.

Early 16-bits

The transition to 16-bit CPUs could probably be seen as your equivalent of CPS1, NeoGeo etc. Very similar to the later 8-bits but with more CPU power and different peripherals.

Jpm System 5, Jpm Impact, Astra hardware (Pluto 1-4?), BGT hardware, Stealth hardware, Stella (German?).

Later 16-bits / Early 32-bits

Consider these the equivalent of CPS2 or Taito F3. Mid 90s tech (~1996+) saw greater use of chips with integrated peripherals, to save on board space. These were popular systems with a decent shelf life and good flexibility but don’t really change all that much from the early 16-bit era, just refine it and allow manufacturers who didn’t have their own 16-bit platforms yet to catch up. Technically you might consider the 68340 used by some to be a 32-bit part, but in reality it’s not really all that different to the 16-bit 68307 or plain 68000.

Scorpion 4, Maygay Epoch, Pluto 5, MPU5

Everything above this line I’m considering looking at, I consider them ‘classic’ systems now, ones which have been phased out. Everything below this line I’m not actively looking at, skeleton drivers for *some* exist mainly through sorting of the sets. That’s not to say other people can’t look at them, but I don’t consider them a priority at all. None of the systems below are emulated (in a working state) by anything public at this point. The vast majority of things I’ve emulated in MAME have been 16-bit era 68000 based titles, so it stands to reason that the 16-bit platforms ABOVE are my main starting point, and I’ll be working upwards.

The modern era brought about faster processors (200Mhz+ Coldfires etc.) I don’t really have much information on these systems, they’re simply not interesting from an emulation point of view at this time.
Pluto 7+, MPU6, PC-based systems

Now keep in mind these are just my opinions based on what I’ve seen. The arcade system equivalents I’ve given are not meant as direct technological comparisons either, just how I see (from my limited exposure to the systems) their roles in fruit machine history. Some stuff here could easily be shifted by a generation, the exact lines are blurry. This isn’t meant to be a ‘my fruit machine is better than your fruit machine’ table, but instead simply a guide to what I consider viable in terms of emulation at the moment and to help people realise that while the machines might not look like the tech has advanced at all from the outside there were a large number of different platforms on the inside. There are of course oddball pieces of hardware which I’m not sure where to put, rarely used platforms and the like and things I simply haven’t been able to identify.

As you can see there are plenty of viable platforms both old and new which haven’t been emulated yet, mainly because a lot of the focus has always been on the more popular platforms and even within those there are a good number of titles which don’t work because they were paired with different external hardware for reels, hoppers, meters or had different security etc. There are also a number of platforms which aren’t listed at all, this is a very UK / Euro based list. The US, Australia, Russia (and presumably Japan) had their own industries and own games on other unknown platforms (although in some cases they just re-purposed old tech, MPU4 was very common)

Speaking of popular systems where only half the titles work Guitar recently released his ‘Project Amber’ which covers many of the MPU4 machines, including ones from the likes of Crystal which hadn’t previously been emulated properly. It also provides some really good looking lamp simulations correctly simulating many of the fancy light effects the boards do to create dimmed or ‘super bright’ lights, an area MFME has always been lacking and definitely a long-term goal of MAME rather than a short term one. I’d also like to thank him for his willingness to share his findings with MAME, which should save some time later down the line.

Obviously the Fruit Machines which are already emulated are a good target to get working because for any large amount of work you need solid foundations and it’s already well known what is needed for those, and there is always the chance to get a couple of titles working on already emulated platforms which require a little extra, MFME doesn’t emulate one-off custom additions, just the most common parts. The ones which aren’t emulated at all are of course more interesting from a technical point of view.

So.. not really a WIP update (I have nothing to report) just an information post.

Note, Comments are CLOSED on here for the time being, been getting quite a lot of spam, some of which has been getting through.