David Haywood's Homepage
MAME work and other stuff
June 7, 2014 Haze Categories: General News. 56 Comments on 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.


Cabinet

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.


Manual

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.


Drive Board

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.


PCBs PCBs

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.


LV Error

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.


Connection Diagram

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.


LEDs

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.


Kensei Mogura

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!


Kensi Mogura Kensi Mogura
Kensi Mogura Kensi Mogura
Kensi Mogura Kensi Mogura

56 Comments

You can follow any responses to this entry through the RSS 2.0 feed.

I’ve never cared much for whack-a-mole or Street Fighter anything but this combination is pretty interesting. Whack-a-Moletal Kombat would have been better, though. ;)

Great Work Haze, it will be easy to play on a XBOX 360 Controller. Please Bow Down to Haze.

Interesting videos, this can use buttons or “clicking”?

So the game turned up in a disused building and had somehow survived the vandals what a lucky find
i wonder how many other games dumped in MAME turned up in such an unusual way

Nice suprise,

Thank´s again.

;)

you can map it to buttons but I feel clicking gives a more authentic experience.

there were actually *2* copies of the game (complete cabs minus bits that had been damaged / stolen) there..

Congratulations Haze, and thank you for the detailed article – very interesting to see what yourself and others had to go through to get this thing working!

Pretty cool. :)

Fantastic work, shitty game.

I really dislike the way the new art in this game is generic anime crap. It doesn’t match Street Fighter 2’s aesthetic at all, and it gives it a really cheap and inconsistent look. All the non-SF2 art sticks out like a sore thumb. I guess Sigma or someone else actually did the art? It doesn’t look like Capcom’s work from that era.

Yeah, the art used during the attract mode does look a bit out of place. I actually like the style of it, and even the attract demo, but it doesn’t really ‘fit’ here.

LOL!

http://www.videoamusement.com/images/whack-a-mythbuster1.jpg

Why they not put a video, to show us some myths?
If we win, they show us a good myth.
If we lose, they show us a busted myth.

Amazing game to play on mame, only looking to the numbers… sigh. *_*

That’s art shift for you. The same thing happened with the Mega Man series, and is the reason why the classic series and X will always appeal to me more than any other one. Not to mention that the franchise was dumbed down from a NintendoHard™ platform game to a Pokémon type game (e.g. Battle Network).

Could’ve been worst. Sex poking machine. LOL

This was great read.
Thanks to everyone involved.

Good work haze

Always the best news here & the same for last year

You keep Mame allive. Haze Mr Mame

I agree about the 3d model rendering of the mechanical user interfaces. That would be potentially more useful for MESS, but examples as this one show us that MAME can also benefit from a 3d layout system.

I must mention GollyGhost as another game supported by MAME that involves mechanical parts (a diorama of a haunted house) and that would be really cool to see with a 3D layout system. Specialy if we render the 3d models of the player 1 and player 2 guns moving based on the user input (by still dragging the mouse probably).

I also would like to use a 3d layout system in my Replicator 1 desktop 3d printer MESS driver.

We would then render the graphics of the HD44780 LCD emulation to a buffer and use that buffer as a texture in a portion of the 3D model of the full 3D printer. And the printer would then be seen moving its extruder by means of counting the ammount of steps requested by the emulated firmware for each of the machine’s stepper motors.

Without a 3d layout system, though, all we can see are the LCD messages. It feels like an old calculator :-P

PS: …anyone here feels like emulating a soda vending machine ? :-D

Thanks go to all those involved.

bakajawaka looking for some trouble here.
Get a life nigga.

If you don’t feel like writing the whole driver for your soda machine you could submit a skeleton with the details you have, explaining what it is.

as for 3d printing.. maybe some framework for MAME/MESS to print 3d model files.. based around the limitations / process used by the printer, that would be kinda interesting. (and could of course show bugs in the printer firmwares if results are unexpected)

Yes, indeed. It would make sense to have a printpreview for 3d printers as a way to validate the correctness of a 3d printer firmware. Specially useful during actual development of firmware :-)

Now… I’ve been dealing with paper printer drivers in MESS recently as well (EPSON LX810L/AP2K and Daruma DS348). And one doubt that I have is how to deal with the output of the printer? I mean… how should I proceed to render whatever the printer is supposed to be printing on paper?

I see 2 ways to do it:

A) Rendering onscreen by creating a video driver in src/mess/video
I’m concerned though that this is a bit of cheating since the paper output is not REALLY a video device… (thinking of actual video cards here)

B) Somehow making MESS output a PDF file (LOL)

I’d rather choose option A and maybe implement B as an optional cool feature. But option A still seems a bit wrong. I’d like to hear what you think of it.

You could do either, I thought there was some kind of PNG output now? I could be mistaken tho, I haven’t actually exploreded this area of the project.

Would certainly be interesting to see a ‘printed’ PDF sent via an emulated PC + printer drivers doing various dither effects etc. (I guess you’d need some kind of HLSL style simulation of the ink for inkjets so that there was appropriate colour bleed and things looked as intended ;-)

Dear Haze,

You need to come to terms with Mame being Dead. A pathetic excuse of a game like this won’t save it.

LibRetro is where its at now because it gives the best parts of Mame and great 16-bit games to play too. Mame is doing nothing.

The Assassin

Screen output with paging controls is fine for starters, and it certainly helps you to figure out quickly if stuff is drawing incorrectly :)

Amazing achievement, amazing post, amazing ideas popping out among the comments. I love you all, guys:)

If all you care about is playing semi-recent games without paying for them, then yeah, I guess you could say it’s dead.

If you care about the more ‘behinds the scenes’ side of the arcades, the bits maybe you didn’t get to see first hand then there are still things being being discovered just like this one.

Personally I find this really interesting, especially the way they hooked up the secondary board to communicate with the CPS board etc. I also consider it very lucky that we found a complete cab of it, had only the CPS board turned up we would have been very confused as to what it needed, and definitely unable to make it work because all the actual game logic is running on that secondary board. We’ve already got too many cases where only parts of systems are dumped (many of the Sega redemption ones for example)

If you care about the non-arcade side of things we’re still seeing a lot of activity too, MAME plays lots of ’16-bit’ games, so I can only assume you mean home system games (Genesis etc.?) in which case MAME does a decent enough job too as long as you enable the drivers (as I do in UME)

I don’t normally care much about CPS games, but I thought this one was fascinating in terms of how it was hacked together. The gameplay’s not gonna set the world on fire, but that’s almost beside the point. A lucky find plus some good teamwork is the sort of thing MAME/MESS/UME continues to do very well.

Dear TheAss,

You need to come to terms with LibRetro being shit. A pathetic excuse of a rant like yours won’t make it better. LibRetro is where it’s at because it gives the best part of MAME to the worst part of the community and bites the hand that feeds it. LibRetro is emulating nothing.

Another really interesting post, congrats on getting the game to work!

I hope that somebody starts a project for 3D-scanning the bits and pieces of all these machines (maybe even including the PCBs?). That would give me some hope for MAME to eventually support Kani Kani Panic, one of my childhood favs. :D

Hello Haze,

Amazing accomplishment. I am glad you’re still making Mame alive, been following your work for years and I can’t believe you’re still there as motivated as ever.

While we are at it, I would have never dared before but since this bug has been there forever, could you take a look at Super Volleyball ? It’s been bugged forever. It’s missing a layer (priority problem maybe ?) that makes it almost unplayable…

A few years back I took some pictures and made a video of the real pcb (that i own) running and posted it on mametest.

http://mametesters.org/view.php?id=4348

I am sorry to use this article comments to make such a request but i am effraid this game will never be fixed otherwise.

Thanks for reading and keep up the outstanding work.

Don’t feed the trolls, etc.

Yep, a 3d layout of the cabinet with the Bisons (Vegas) popping up and down with hammer interaction would be nice to see some day.

OT: Haze, I’ve been getting warnings from time to time when I visit Kale’s or your blog.
This is with IE and Firefox, both warn me about a domain not related to emulab. Not posting the domain here just in case.

Don’t listen to that stupid faggot Guru!!!! Guru the rom dumper for MAME is a fucking asshole!!!! He makes headbangers look like shit. Guru and Tingoes, if you are reading this, go fuck yourselves Assholes! GURU IF YOU THINK EVERYONE AT MAMEWORLD ARE TURNING INTO NAZI AMERICA AS YOU ARE QUOTED SAYING, >>>>>>>> THEN MOVE THE FUCK OUT!!!! ASSHOLE!!!<<<<<<<<<<<<<<<<

Hi Haze,

I was looking at MAME’s list XML file, and it seems like a lot of the information in it is wrong.

For example, aerofgts says it’s a 4 player game, but it isn’t. It’s just a 2 player game. Should I report these or send in diffs, or is it intentional and I’m missing something?

in the case of boards with standard connections it will often it will list what the board can support as opposed to what the game had hooked up, this is fairly common for platforms with a large number of games.

I’ve also improved the layer alignments, and removed an extra ROM from the US set (with the Korea/UK/Spain flags in it, I don’t think the US set is meant to use it and it was causing glitches?)

Amazing ! You’re most definitely a King !

Thanks for looking into it, you made my day. I guess it will be included in the next release ?

yes, the changes will be in the next release

:-)

btw your PCB (as posted on MT) looks to have a different rom setup compared to what we have dumped, I’m wondering if our gfx roms are from a bootleg (it was a 2 board setup, the one pictured is a single board with mask roms?)

looks like the dumped PCB was this design
http://www.citylan.it/wiki/index.php/Super_Volleyball_%28Japan%29

note, this PCB has no video system markings, although I guess it could be cloned from an alt original board design.

Weird indeed, My board even have a serial number so it looks “kinda” genuine…

I guess i’ll wait for the next version of mame to see how it works the way it’s supposed to be.

hey Haze, you mentioned this a while ago:
[quote] Drivers are defined with either a GAME( macro, a CONS( macro, COMP( or SYST( depending on what type of system they are. This information was previously unused, but the emulator will now attempt to parse ‘arcade.ini’ for anything defined as GAME. and ‘console.ini’, ‘computer.ini’ or ‘othersys.ini’ for each of the others.[/quote]
Would it be possible to add a system tag (or other name) into the -listxml output for each game ? This would improve UME support in my frontend Emu Loader. Currently there is no way to know if a game is arcade, console, handheld or computer.

It is a king.

TMPZ84C015AF-6

I have added a sketch for this TOSHIBA Z80 CPU+CTC+SIO+PIO to the src/emu/cpu/z80 directory a while ago because it is needed for the (currently non-working) SONY PVE500 driver in mess.

I’ve had some sort of problem with device tags when hooking up the interrupt lines internally.

Sounds like this chip may be very similar to the TMPZ84C011 used in this Street Fighter whack-a-bison board. Would you mind taking a look at the src/emu/cpu/z80/tlcs_z80.c code to check whether I committed some silly newbie mistake? Also, seems like both chips could potentially be merged into a single file, right?

Datasheet for the one used in pve500 is here:
http://datasheets.chipdb.org/Toshiba/Z80/TMPZ84C015B.pdf

http://www.datasheetarchive.com/dlmain/Datasheets-X2/TDSA852000-4.pdf

This file lists both chips under “TLCS-Z80 ASSP Family”

Are you referring to the Chunners’ picture with her name (which uses CPS2 SSF2 font for her name) in the background? Seems like it is recycled from the SF2 anime movie (this game and the anime came out in ’94)

I also own a CASIO electronic typewriter called Casiowriter CW-16 which uses the same TLCS-Z80 variant as PVE500 (the TMPZ84C015AF-6 chip)

I’ll need to take a look, but most of the logic in the tmpz84c011 core (other than the i/o ports) is just trampoline logic to keep the ctc inside it where it belongs. I’m not 100% sure if it would work in more advanced use cases (although I don’t see why not)

TMPZ84C015A would be just trampolines, and a watchdog timer. From an implementation point of view, it’s less complex than the one in kenseim.
I’d put them in the same file.

Can you help me with that whenever you have the time to do so?

sure

Hate to flog a dead horse, but the last time I asked around about where to go with emulation of the ZSG2 system I seemed to get conflicted views about the source of the remaining issues.
hap seemed to think going from driver notes it was something to do with the DSP, but there’s instruments that don’t seem to be playing at all (or at a very very low volume if present), but R.Belmont suspected a bug in the sample decoding/processing rather than required filtering.
I read from some portions Haze that you helped out in doing the initial decoding of the samples from the ROM. Any ideas on this? Must be simpler than some of the stuff you’ve tackled lately surely.

Was this from an arcade in Margate as I remember seeing it there on trip one bank holiday about 10 years back and it looked sorry for itself then. Anyway great find and glad you could preserve this.

all good things come to those who wait (*may be lies)

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close