Osso recently purchased an unknown Korean title called ‘Rolling Crush’ and donated the board to Caius for dumping.

Upon arrival Caius posted a picture of the PCB.

(Rolling Crush PCB)

There are a few distinguishing features about the PCB, first of all it uses an MC68EC020 rather than a regular 68k like most Korean games, second and most significantly it had an AT89C52 MCU. These features instantly allowed me to identify it as a Semicom PCB, and as it happens it turned out to be the same PCB as Dream World.

(Dream World PCB)

The boards are essentially identical, but Rolling Crush does not have one of the AD-65 (sound chip) positions populated (top of the images). Interestingly this would bring it closer to the Baryon profile, which uses only a single AD-65 as opposed to the dual ones used by Dream World, however that PCB is a slightly different design.

(Baryon PCB – not identical)

Now this was interesting because the game was not sold as a Semicom game, nor did any of the provided screenshots or videos show a Semicom logo or Semicom copyright, furthermore it does not appear on any official list of Semicom games I’ve seen. The video Caius provided is embedded below. The blue-white colour fade on startup is the same as Baryon, and the sound effects (coin etc.) are also clearly Semicom but that’s as far as the obvious signs go.

Content not available.
Please allow cookies by clicking Accept on the banner

Once the dump arrived I looked in the main program roms of the game, and as expected there were a variety of Semicom related messages, looking in the graphic roms further bolstered my view that this was a Semicom development, the usual Semicom ‘Unicorn’ and could clearly be seen there too.

Unsurprisingly it was also protected like the other Semicom games too, with the MCU supplying the interrupt routine for the game at startup. This kind of protection is easy enough to deal with, I modified some code I’d used to extract the data from Dream World and Baryon, Caius then ran that code on the original hardware and took some pictures.

After entering all the data the game successfully booted in MAME. I tried playing with the various dipswitches to see if one showed a Semicom copyright, but none of them had that effect.

One thing I had noticed when looking at the program roms was a credits roll including names of Semicom staff, viewing this of course meant I would have to complete the game, and even on the easiest setting things started to get very difficult on the later stages. Thankfully MAME has cheat finding capabilities built into the debugger, and even if they’re not as good as they used to be I was sill able to use them to find some cheats allowing me to finish the game.

Finishing the game (50 stages) yielded the following credits roll after a psychedelic ‘Congratulation’ message.

So there you have it, the actual Semicom copyright, inexplicably only visible for a brief second once you finish the entire game! I don’t think the game is a hack or a bootleg* instead it was probably simply licensed to ‘Trust’ for sale / distribution. I wonder if there is an alt. version out there actually using the other Semicom graphics that are present in the roms.

*I’m aware the gameplay is a complete rip-off of Puzzloop, but the code and other assets are original

*edit* ArcadeFlyers has a flyer for the game, also mysterious because it too lacks any manufacturer information.

While the flyer lacks manufacturer information it does still hint at Semicom, the layout of the back page is similar to More More Plus with the ‘MEMO’ box.

UME is the complete/combined version of the MAME / MESS project.

With no clear sign of an official 0.154 release I’ve decided to put up an 0.153ex6 build for public testing.

We seem to be heading towards a good level of stability with this build, although some outstanding issues from the cycle do still exist, namely the DCS sound issues, and some H8 based games (Last Fighting) which no longer appear to run correctly.

I’m a bit limited for MAME time at the moment as you can probably see from the unfinished write-up for ex5, but there are a number of new additions and features I feel make it worth putting out this ex6 build for testing, these will be discussed below.

0.153ex6 is built from SVN revision 31277

UME 0.153ex6 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex6 sources

Here is the 0.153ex5 to 0.153ex6 SVN log

Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.153ex6 Windows binaries – 32-bit, 64-bit and all tools
UME/MAME/MESS split 0.153ex6 Windows *SDL* binaries – 32-bit
UME/MAME/MESS split 0.153ex6 Windows *SDL* binaries – 64-bit

Points of Interest

One area of interest I covered in the 2013 write-up was the progress being made by Samuele Zannoli on the Sega Chihiro platform – an arcade version of the original XBox. The emulation of that platform has seen further improvements to the 2D rendering over the lasts few weeks, and now includes debug code to disassemble the various shaders that get uploaded by the game code. Performance is still very slow, running at around 2% speed on my 3Ghz Core 2 system so actually seeing the progress in action is very time consuming. To save time I’ve recorded a short video with -aviwrite, it took about an hour and a half to record but gives you a 3 minute preview of the current state of the emulation. The emulation hangs MAME shortly after the end of this video (when the 8th place high score is displayed) so I quit before then. Please note, this contains some rapidly flashing colours so if you suffer from epilepsy or similar conditions you might want to avoid viewing the video. The title screen comes in at around 1:14.

Content not available.
Please allow cookies by clicking Accept on the banner

With Ken Sei Mogura I tackled a part mechanical game in MAME, Robbert has been doing similar by looking at Bally’s Baby Pacman, a Pinball and Video game hybrid. Obviously simulating the entire pinball table is a bit beyond MAME at present, and PinMAME already supported this years ago, but it’s good to see progress being made on the emulation of the video part in baseline MAME. Even without the pinball part emulated if you map all the pinball triggers to keys then you can fool the game into thinking you’ve hit the targets on the Pinball part to unlock the power pills and allow you access back into the maze. Currently sound doesn’t work, but this is one I had been hoping to see progress with for a while. He has also been working on Granny and the Gators, but that is a more complex setup and doesn’t currently boot without hacks. There was another Video-Pinball hybrid in the form of Gottlieb’s Caveman, the video hardware for that one actually looks really simple so I might give hooking it up a go myself.

A feature a number of people have been anticipating for a while is NeoGeo MVS multi-slot, and I’m happy to be able to say that the ex6 build shows the first steps of this being integrated into the main codebase. An external contributor took my original work from the turn of the year and reworked it to be a bit more modern before submitting it. Thanks to “S. Smith” (or whoever you are) for this contribution.

If we use the commandline

ume64 neogeo -cart1 fatfury1 -cart2 fatfury2 -cart3 fatfursp -cart4 rbffspec -cart5 rbff2 -cart6 garou

then we can boot the NeoGeo emulation with all 6 slots filled, so the menus look something like this.

After inserting a coin you can then flip through each of the 6 slots using the 3/4 buttons (next game / previous game on the cabinet)



The Unibios also recognizes all the slots, so if you’re using that you can run the CRC test on any slot

Please note that this support is still considered preliminary. There are a number of issues, primarily that cartridges should handle their own Z80 banking, rather than it being a global thing. The only game I’ve noticed this causing issues with first hand is Thrash Rally which has no sound on the MVS with the current slot system, although it seems to be a badly programmed game anyway. AWJ has volunteered to look into doing the Z80 banking properly, although I don’t know if that will be done in time for the next release.

A couple of the actual MVS games seem buggy too, for example a few titles will cause the NeoGeo to not initialize any cartridges in slots after the one the cartridge is in if the NVRAM of the NeoGeo is blank. Two such games are ‘kof95’ and ‘kof2002’. I believe this to be an original game bug because the ‘kof95a’ / ‘kof95h’ set fixes the bug. This would be a very rare occurrence on real hardware as it appears it only happens if the NVRAM area for that slot is completely uninitialized, if another game has previously initialized it then things are fine and a simple turning off/on of the system is enough to have all cartridges recognized if it does ever happen. In MESS it’s a slightly more common occurrence because the first time you boot the system you’re working from a completely blank / unused NVRAM.

It’s also worth noting that for games with watchdog protection you’ll get a single reset PER game upon first installation of the cart, meaning if you boot with 6 games all of which have that protection you’ll get 6 resets, this is normal. Many of the bootlegs / hacks also fail to properly respect RAM boundaries for multi-slot configurations and fail if used in them, or fail to advance the game after an attract cycle, again this appears normal and I have a feeling the hardware would act in the same way.

One final note, the slot system uses the Software List, there are a number of entries missing from it at the moment.

If you don’t care about the multi-slot system then the existing NeoGeo emulation works exactly as it has always done, and you can ignore this extra functionality.

Moving on, a last minute addition to the ex6 build was the NON-WORKING set of Rolling Crush. This game was recently dumped and hopefully I’ll be showing you some progress on it shortly. The board was purchased by Osso and dumped by Caius, the copyright shows (c)1999 Trust, but it’s clearly a Semicom developed game, it uses common SemiCom sound effects, has unused Semicom logos in the ROMs, runs on a Dream World PCB (with an AD-65 removed) and uses exactly the same protection systems as every other SemiCom game meaning to get it working I’ll need to extract the protection data. He uploaded a video from the original PCB here. I’ll be working on this over the next few days!

– tweaks to SMS timing
– trap15 wonderswan noise channel
– gameboy Li Cheng pirate mapper
– further Konami cleanup
– RB: Apple II – Support for the Mountain Computer Music System
– slight C64 speedups
– CPU modernizations (some reported slowdown?)
– Couriersud continued netlist work
– SH2 dynarec speedups for low end systems.
– Cool Pool 2nd button (wasn’t fully playable before?)
– Save State core stability fixes for some edge cases
– Older Snake Pit and SDI clones

(more soon)

UME is the complete/combined version of the MAME / MESS project.

I’ve noticed some interest in the Ken Sei Mogura update below, but so far hadn’t got around to posting a binary with support for it. UME 0.153ex5 has support for the aforementioned title (along with a better internal layout from hap) in addition to a number of other things I’ll cover later.

DCS sound system based games (eg. Carnevil, California Speed, NFL Blitz) have been broken since the DCS based Williams Pinball display drivers were improved so I was hoping to see that fixed before issuing a new update, but it hasn’t yet happened; hopefully it will be fixed before there is an official 0.154 release (probably still a month away at least)

0.153ex5 is built from SVN revision 31072

UME 0.153ex5 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex5 sources

Here is the 0.153ex4 to 0.153ex5 SVN log

Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.153ex5 Windows binaries – 32-bit, 64-bit and all tools
UME/MAME/MESS split 0.153ex5 Windows *SDL* binaries – 32-bit
UME/MAME/MESS split 0.153ex5 Windows *SDL* binaries – 64-bit

Points of Interest

We’ve seen a number of prototypes show up over the last few years, some of them early builds, some of them almost indistinguishable from the final versions of the game. Another one so far falling into the latter category is a Raiden Fighters SPI Cartridge. ‘Karen’ found this version of Raiden Fighters and it displays an interesting message on the title screen ‘EVALUATION SOFTWARE FOR SHOW LICENSEE TUNING – GERMANY’. This message is present in the ROMs for all versions of the game, however it isn’t usually used. We know TUNING licensed a lot of Seibu’s games (including the Raiden Fighters games) for use in Germany, so it makes sense that them might have been sent preview versions. What makes a little less sense is that the board is an Australian region board (according to the region byte) and was found in Australia.

It would be easy to write it off as some kind of hoax / hack, but the actual codebase is clearly a different revision than any of the previously supported sets at least, so it’s definietly not a cheap hack of a set we already know about, and could actually be earlier code, although so far we’ve been unable to identify any actual differences in the gameplay so it’s probably close to the final, or maybe even a later revision than those used in Japan if it was sent for evaluation after the actual Japanese release. I do hope somebody attempts to identify all the differences in the various Seibu revisions one day because most of their games have a number of builds.

Along similar lines what appears to be a ‘close to final’ US / World revision of Galaga 88 was found / dumped by Andrew Welburn. There are only a few differences between the ROMs found on this PCB and the final PCB but all the ROMs were hand-dated and in one of the graphics sockets there was an extra rom containing only the fonts and a few other characters – it has the earliest date and is probably a leftover from an earlier point in development because the game doesn’t seem to use it.

An early revision of Peek-A-Boo was also dumped. The ROMs on this one were marked as ‘Version 1.0’ and the title screen indicates that it’s a US set. Furthermore the game seems to be a ‘Paddle Only’ version because enabling the dipswitch for ‘Button’ mode causes the game to enter a debug menu after a few seconds. (This needs further investigation tho)

— early Joust 2
— early Knights of Valour Super Heroes

One fix that is likely to be overlooked by the majority is the one made to the Amiga emulation allowing the Arcadia game Space Ranger to function correctly. Space Ranger has been marked as ‘Working’ in MAME for a long time, but was another case of a driver being marked as working prematurely. To play the game you need 2 buttons, and for the majority of Arcadia games both buttons worked, however in Space Ranger the 2nd button didn’t, meaning you couldn’t use the net to capture / rescue the creatures along the bottom. It turned out to be an issue with the emulation of an internal timer, so hopefully the fix has also improved some Amiga titles where inputs weren’t responding correctly. Along with coming up with this fix Duke has also continued to improve other areas of the Amiga emulation although it still struggles with most copy protected software.

The steady flow of Spanish versions of games continues, this time with a professionally made (possibly licensed) version of Space Invaders from Electromar. This has all the texts translated and even has a nice touch in that the Invader steals the ‘M’ of ‘FIM’ and replaces it with ‘N’ as opposed to replacing an inverted ‘Y’ of ‘PLAY’ in the regular versions. You can thank Roselson of AUMAP for finding this one.

Another interesting finding was made when Artemio dumped his 2 Crude Dude board. Quite often when people dump boards they take a rather lazy approach of dumping only the program roms, even in cases where other roms are socketed. What Artemio found is that later revisions of 2 Crude Dudes are meant to use an updated tile rom, with some changes to the Japanese characters. His actual board was a US version so these tiles are unlikely to be used on it, but after looking at some photos it appears the later Japanese versions should also use this revised rom and were not doing so.

I mentioned hap improved the Kensei Mogura internal layout a bit, this is how it looks now

– Sinclair QL work
– x68K blending work + other fixes
– Konami cleanups
– More MSX improvements
– Better Namco System 1 memory maps

One from the ‘requested at a timely moment’ department is the fix made to Super Volleyball. A number of gameplay elements were missing, such as marker arrows, player hints and the confetti after scoring. The fix was actually simple, the bug was caused by an incorrect loading of the sprite roms, meaning it WAS drawing those elements, just with blank tiles. Fixing it turned out to be nice and easy. I don’t know if it’s always been like this, or regressed during other cleanups. Fixed now anyway.

The recent work by Roberto caught my eye too, we’ve known for a long time that there were some other ‘games’ on Cherry Master hardware and his most recent update shows emulation of two of them. Tetris and Pacman.

Now you’re not going to want to actually play either of those. The Tetris version is criminally boring, the playfield is so wide you’ll have hit the quit button long before you’ve filled a line and the aspect ratio is just odd. Pacman isn’t much better, on my first play I managed to glitch the game so that one of the fruit items was stuck on the screen, couldn’t be collected, and wouldn’t disappear, furthermore the ghosts tend to move mostly at random but usually end up simply blocking your access to the power dots by congregating around those areas. Don’t expect smooth movement on the games either, the hardware has no sprites, only tilemaps.

The reason these existed was not so they could be played, the games are just facades, as Roberto mentions they simply hide Cherry Master games behind an innocent looking exterior. This worked in a similar way to the drugs trade, these Cherry Master games were banned in various places, so importing / exporting them wasn’t allowed, and if you were found to be operating them you’d have your boards seized / destroyed as well as being handed large fines or worse. By hiding them behind a more innocent looking game (even if said innocent looking games were probably just as illegal with all the ripped art assets) these games could be operated with greater secrecy, and switched between titles with a secret operator input if needs be. I’m glad to see these dumped / emulated because we’ve seen the same things but with physical protections too, for example light sensors so that if the cpu boxes were opened to inspect the games the content was erased – needless to say between boards being seized and the kind of physical protection I mentioned some of them are rather rare now, but it’s part of history that needs documenting.

Some of the most important work done on the arcade side of things over the last few weeks has been a number of the devs putting in some hours to figure out decryption keys for a number of Sega FD1094 based games where we didn’t have the CPU modules, or the modules we had were already dead. This isn’t easy work because although the basic structure of the keys can be generated from a seed there are areas of them were customized in each CPU and working these out requires extensive studying of the code between sets. Andreas Naive and Chris Hardy were the ones doing this work, with hap acting in a supporting role to hook up driver level differences between the games. For the most part this isn’t especially rewarding work as the clones often only differ by the encryption types used, however it’s important work and in some cases subtle differences can be seen. Out of the various sets that were decrypted the System 16B version of Ace Attacker was the most interesting, it required the controls hooked up in a different way, and also interestingly uses a different font for the ‘Insert Coin’ text with an actual graphic being used where the System 16A version just used ordinary text.

(more soon)

The last time I covered a previously unemulated title in the official Street Fighter series is when I was announcing that CPS3 had been emulated for the first time and you were seeing the first screenshots from my work on Street Fighter 3.

That event generated a lot of publicity for the project, some good, some bad, but one thing it did do is make people realise that MAME was still around and that we were still working hard on improving the project; it got people interested and allowed them to see what else we’d been working on in the years since they’d last taken a look.

This update concerns a different member of the Street Fighter series, one of the harder to come by titles and I’m hoping it helps demonstrate how MAME is branching out.

The game in question is “Ken Sei Mogura: Street Fighter II” and it’s kinda special. Street Fighter II is arguably one of the most influential arcade titles of all time, after seeing the success of the game almost every other arcade developer immediately felt they had to come up with their own vs. fighting game to compete with it.

Ken Sei Mogura is another product that came into existence due to the iconic status Street Fighter II had quickly attained but until recently it had remained undumped and unemulated.

For those not familiar with the game it’s an official Capcom product developed in conjunction with Sigma and the relatively unknown Togo. The video and audio for the game are provided by Capcom’s popular CPS1 platform, the very same board that powered Street Fighter II itself. The game uses the original Street Fighter II assets and a modified version of the game engine so it’s fair to say it’s one of the closest relatives to the original game.

The twist here is that this is not an actual fighting game, it’s a Whac-a-mole title, one of those games where little heads pop up and you have to use a hammer to hit them back into the ground. The whole machine is Street Fighter II themed, the moles are Bison (Vega) characters and the on-screen characters play out a fight based on your performance.

There are a few videos of the game on YouTube, at least two of them from the same arcade in Japan, but it’s not exactly a common game these days.

Content not available.
Please allow cookies by clicking Accept on the banner

Content not available.
Please allow cookies by clicking Accept on the banner

Content not available.
Please allow cookies by clicking Accept on the banner

What makes the rest of this story more surprising is how I came to be writing this article in the first place. Of all places for one of these machines to show up the UK wouldn’t exactly be your first guess but that is exactly where a machine was found, in a disused location and already subjected to various levels of vandalism.

The man to secure the unit (or at least for the time being the PCBs) effectively saving them was Alan Meades who kindly got in touch with us about the possibility of emulating the boards.

He provided a number of pictures of what he had uncovered, confirming what we’d already been told; that the game ran off a Capcom CPS1 board, but also shedding some light on the additional hardware the machine uses. Manuals and connection diagrams (mostly in Japanese) were also found, interestingly there was an English translation of some bits of the manual which is curious because the game to my knowledge was never released outside of Japan yet the translation refers to Vega by his non-Japanese name of Bison.

The most significant thing that was discovered was the ‘Drive Board’. This Drive Board was one of several additional PCBs used by the game, and importantly on it was a CPU and a ROM. This, combined with some information in the manual shed some light on the unique hardware setup that had been chosen for this game.

The CPS1 board as it turned out was simply a slave board, it only works in response to commands sent by the Drive Board; all inputs etc. were connected to the Drive Board instead of connecting directly to the Jamma connector on the CPS1 board. This actually isn’t too surprising, the base CPS1 board is quite limited in terms of I/O capability with Capcom already having had to squeeze the kick harness connectors on the C boards so driving the game from a more suitable board with significantly more I/O ports makes a lot of sense when you’re dealing with the kind of mechanical hardware used by this game.

Anyway, it didn’t take long for both these boards (the CPS board and the Drive board) to be shipped off to Porchy who quickly dumped the ROMs on them, including the PAL (different CPS games use different PALs to control the graphic addressing and this one was unique to this game)

I quickly hooked up the CPS1 side ROMs in MAME and unsurprisingly they didn’t do a great deal beyond displaying a cryptic ‘LV’ error message. Porchy confirmed that the real CPS1 board does exactly the same when no additional boards are connected, so while it was initially anticlimactic it was also good news.

Before proceeding with the emulation a couple of things in MAME needed tidying up. The main CPU on the drive board was a TMZ84C011, or in clearer terms a Z80 clone with some extra I/O ports and the Z80CTC built in.

MAME already had emulation of the TMZ84C011 for a number of Nichibutsu Mahjong drivers where it had been used as both a main CPU and a sound CPU on a number of Mahjong game PCBs. The implementation in MAME however had simply been copy and pasted between drivers with the port handling hardcoded for each game. This is mainly because said drivers predate the modern MAME method of creating shared devices and setting up port callbacks for such hardware, and also predate the ability to define custom CPU types with built in peripherals. None of these limits exist anymore so I took a day or two to modernize that code and set things up properly, cleaning up the code and reducing the amount of duplication in MAME in the process.

The other chip of note on the Drive PCB was a MB89363B. To work out what that was we asked Stiletto to dig out whatever information he could find on it. In the end it turned out to be a chip more commonly used in radios and simply amounts to 2 i8255 I/O chips glued together in terms of functionality. Again no great surprise the board was clearly built for heavy I/O use.

Santeri Saarimaa (Gridle from the old mame.net) also lent a hand at around this point, translating a few bits from the Japanese manual into English. It’s very uncommon to have a manual to work with when doing emulation work, but for a set-up like this it was a time saver; one of the pages lists (in Japanese) what each of the pins on each of the Drive PCB connectors is hooked up to and in this case that information came in handy because of the unusual way the Jamma connector is being abused as a communication port. By cross-referencing the diagrams in the manual with the standard Jamma Pinout I was able to confirm my initial feeling that the communication ports had been hooked up where the 4 joystick directions usually connect for each player (to form one 8-bit port) as well as where the two Player Start buttons and Service Coin usually map (for additional flags) That gave 11 lines for the Drive board to send messages to the CPS1 board. For communications the other way the usual Coin Lock and Coin Counter outputs were abused in a similar way to give 4 lines for communicating responses back to the Drive board.

I did a fair bit of tracing of the game code for the Drive board CPU at this point in order to try and establish where those ports mapped on that side of the setup and was able to quickly rule out a number of ports that were clearly dipswitch related, as well as those used for the coins, start lamps and start buttons thanks to the translation work Gridle had done.

One other set of accesses stuck out more than others, those turned out to be a serial port for communicating with the ‘Level’ LEDs on the control panel, due to the serial nature of the port (1 bit of data at a time) and frequency at which the LEDs are meant to change those ports were extremely ‘noisy’ in the logs compared to others. I hooked these up and the results were pleasing, the display made by the LEDs (lighting up from one end to the other) matched the power-on description in the manual.

Other ports were performing 0x3f (6-bit) masks on read and write operations, and often used in pairs. Knowing that there were 6 moles per player I quickly concluded that those ports must be the ones used to drive the moles and read the status of the hits.

In the end I was left with exactly the right number of ports / bits needed for the communication ports, however no matter what I tried they didn’t seem to want to map correctly. I knew these were the communication ports because if I returned completely random values the game did start to do random things, allowing me to produce screenshots like the one below.

In the end ‘hap’ provided some assistance here, it turned out I’d got everything hooked up to the right places but my logic was inverted (or more correctly, the communication logic on the PCB was inverted) so the commands that were being sent between the CPUs in MAME weren’t what was expected at the other end.

With that fixed the game attract mode started to run and the notes I’d made earlier about what each of the other ports should be were proven to be correct. I hooked up the start lamps and made a video of the current progress. The game was quite interesting to see in action at this point because none of the mole inputs or outputs had been mapped, this resulted in the game thinking all the moles were constantly ‘hit’ so if you coined up you would always win with the maximum number of points! (it also showed that Player 1 hits always take priority over Player 2 hits if you hit at exactly the same time, so in a 2 player match Player 1 would always win!)

Content not available.
Please allow cookies by clicking Accept on the banner

I then spent a bit of time cleaning up the dipswitches, and attempted to hook up the moles to some basic clickable ‘internal’ artwork. Knowing exactly which physical mole maps to which bit of the I/O port doesn’t actually appear to be possible without having a working cabinet running the test mode, so I had to make a few guesses; knowing one of the moles for each player was bigger than the others at least meant mapping 1 of the 6 was easy because during testing I noticed that one specific mole would always give 2 points instead of 1 point; obviously that was meant to be the big one.

That brings us to where we are now, a playable game that just a week ago was completely undumped and unemulated. A game that a couple of years ago people might have not even thought to be suitable for emulation in MAME due to the mechanical element of it. The actual game is quite short, you’ll play a round vs. either Chun-Li or Ryu (depending on which character you pick) and if you beat them you’ll face Vega. There are dipswitches to control the difficulty, but the main appeal of the game came from it being a whac-a-mole, so the short length is understandable, it’s not the type of thing you expect to play for an extended period!

Content not available.
Please allow cookies by clicking Accept on the banner

With MAME these days we’re always looking for new and different things to emulate, it actually surprises me greatly that there aren’t more mechanical whac-a-mole games in MAME, we could easily emulate non-video ones if they were dumped exactly the same way the non-video mechanical part of this one has been emulated.

Eventually I still hope MAME gets the ability to recreate full 3D cabinets, the layouts you see at the moment are basic 2D ones using the internal layout system, those could of course be improved using scanned artwork etc. as Mr. Do has done for a number of other games.

So if this article grabbed your attention and you’ve managed to read it to the end I hope you’re now more aware of how MAME is always changing, always growing, and how things you might not have even considered emulation candidates very much are these days. We’ve got this kind of thing, Fruit Machines, and if you look at the MESS/UME part of the code we support computers, consoles, cash registers, you name it. If it can be emulated then as a project we’re interested in emulating it. If you found this update interesting then please share it!

Special thanks must go to Alan for securing this incredibly rare piece of history, Porchy for dumping it and hap, Gridle and Stiletto for their roles in helping to get it emulated not to mention the original authors of the CPS1 driver and all the various components I’ve made use of in doing this; if the whole thing needed to be done from scratch it would have been a lot more time consuming!

I’ve been spending a bit of time looking at the various Tecmo drivers (hence asking if anybody has an original Final Star Force video) and decided to look at the ‘Master Ninja’ bootleg while I was at it. There were various issues in MAME, and still are, however I’ve improved the sprites so you can actually play it now.

it turned out that the sprite system was actually the same as the ‘Dragon Bowl’ hack of the game, while the game code is clearly derived from the World / European ‘Shadow Warriors’ release. it’s possible the bootleg is part of the chain between the original game and Dragon Bowl; the tilemap handling is also the same as Dragon Bowl. I’m guessing neither game supports the ugly blending effect the original has when an enemy is lying dead on the ground and about to vanish.

While I was doing this I noticed that the game tells you to ‘INCERT COIN’ and was wondering if any of the sets had this corrected, they don’t not even the Japanese release which is dated 1989 on the title screen instead of 1988, I guess they didn’t care or didn’t notice, but it’s unusual to see such a common message mangled like that. Here are the various title screens for comparison.

As you can see the bootleggers actually drew their own logo using the basic Shadow Warriors one as the starting point.

I still need to figure out what sound system the bootleg uses and tidy up the code.

(and yes, I know somebody is bound to ask about Automat in the comments ;-)

UME is the complete/combined version of the MAME / MESS project.

There was a mixed reception to the previous post about the new colours for Nemesis etc. They’re not going to be reverted (the new code IS more correct even if some people apparently don’t like it as much as the old hacks) but if you want to try them yourself here are some new binaries. I was going to post some at the time but ran out of time to do it.

0.153ex4 is built from SVN revision 30687

UME 0.153ex4 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex4 sources

Here is the 0.153ex3 to 0.153ex4 SVN log

other misc binaries (if you don’t know what these are you don’t need them)
Split MAME/MESS 0.153ex4 binaries (32-bit and 64-bit builds) are here
UME/MAME/MESS 0.153ex4 binaries (32-bit and 64-bit) built with Intel C++ Compiler 14.0.3.202 Build 20140422 are here
UME/MAME/MESS 0.153ex4 binaries (32-bit and 64-bit) built with Microsoft C++ Compiler 18.00.30501 (VS2013 update 2) are here

Points of Interest

As mentioned above the main reason you might want to give these a test-drive is the new code for the Nemesis colours, as covered below, however there are some other things worth talking about.

There have been a number of additional regression fixes etc. from the team submitted over the last week or so to combat issues caused by recent refactoring so these builds should be once again more stable than the last ones. Work has also continued on the MSX and Amiga driver reworking, check the change logs for details there.

One thing that seems to have slipped under the radar on all the MAME news sites is Any’s dumping / addition of the Konami game ‘Step Champ’ This, until now, was an unemulated Konami competitive Minigame collection with a step pad a little like the Dance games they made so popular (and no surprise one of the mini-games is a dance based one)

Skeleton drivers for some later Stern Pinball titles have also been added lately, along with set-syncing against PinMAME, probably not the most interesting piece of news, but a lot of people might wonder what the bulk of the new additions are, so worth mentioning.