Archive for June, 2014

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!