Whac-a-Bison (Vega)

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!