Until it showed up a week or so ago I had never heard of the game ‘Fire Ball’ by FM Work, but the screenshots on eBay made it look like a Bomberman ‘clone’.

Team Europe picked up the board and dumped it. The hardware was a z80 based board (with an additional Z80 for sound) so definitely not based on bootleg Bomberman code, but instead an original Korean product.

Even with original Korean games the hardware is usually cloned from something else, and identifying what it is early can save a lot of time. (I actually ended up discovering the Black Touch ’96 is a modified clone of SNK’s POW hardware – many years after I added it, had I found that earlier it would have saved me a lot of time figuring out the video hardware!)

The cloned hardware is rarely a straight 1:1 copies, usually the sound systems are degraded, clocks often changed, sometimes graphics hardware is tweaked (for higher BPP tiles, as we saw with Lock On previously covered here) and physically they look nothing alike so when trying to work out the basis of a piece of hardware you have to look for ‘unique’ characteristics in terms of addresses used, sprite / video formats etc. in order to pair the cloned hardware.

Anyway, with Fire Ball I decided to start by decoding the graphic tiles, that turned out to be simple enough, 3 sets of graphics, 2 sets of 4bpp 16×16 tiles, and a set of 2bpp 8×8 tiles.

I then started looking at the code for the main CPU. It’s was a Z80 program, clearly driven by an NMI (Non-maskable interrupt) rather than the regular IRQ0 signal on the PCB. Generating an NMI too early caused the game code to crash, so clearly there was an external enable / disable flag for the NMI generation. The only real things the game did of note aside from clearing RAM were some port writes, especially to address 0xf80e. One of those was surely NMI enable. The last thing it wrote there, before sitting in a ‘halt’ loop was 0x08.

Searching the MAME source for “0xf80e” in the memory maps gave precisely one hit. The driver for Legendary Wings (lwings.cpp)

Mapped at 0xf80e there was “AM_RANGE(0xf80e, 0xf80e) AM_WRITE(lwings_bankswitch_w)” which on the surface might not sound like what I was looking for, but if you look in the actual function you’ll see it does a few things, including having an NMI enable flag on bit 0x08.

Legendary Wings also used a 2bpp text layer, 16×16 4bpp sprites, and 16×16 4bpp tiles.

It quickly became apparently that it was the base FM Work had used to create their cloned hardware from.

Anyway, I added it to the driver, taking note that the sound system was definitely different, this PCB used a single M6295 for sound, none of the Yamaha chips of the original hardware.

None of the games in the driver supported 4 players, so I also had to figure out where the extra inputs mapped, not really a challenge, and then tackle the sound. Worrying there was a big epoxy block on the PCB, however we’d already established that removing it only caused one thing to happen, the sound stopped working. Team Europe had also already decided to throw caution to the wind and open it up, there was actually very little of note inside, just 2 20pin devices.

Hooking up the sound didn’t take long, it isn’t great, but that’s because the sound hardware is awful; test mode lets you test every sample. Having hooked it up I’m actually left a little confused as to what the purpose of those devices inside the block are, maybe they’re related to the sound banking or memory map for the sound, because the actual sound system is very simple, a simple M6295 driven by a tiny program, with some sample banking.

I played through the game a bit, noticed that the 3rd boss and above had corrupt graphics, noted that the game has twice as many sprites as anything on the original hardware, and found the sprite bankswitch address (same location as the rom bankswitch)

Interestingly, because this game has a single 0x20000 program rom, rather than 3 0x8000 sized roms like the other games in the driver a chunk of the program rom is inaccessible. Alone this isn’t too unusual for these Korean games, often such areas are left blank in roms or just duplicate the first part of the data.

What’s weird here is that the inaccessible area is mostly a direct copy of the first ‘fixed’ / ‘non-banked’ part of the program code but with a very slight change, 2 pieces of code are switched around.


3822: CD 73
3823: 00 23
3824: 3E 72
3879: 73 CD
387A: 23 00
387B: 72 3E

2nd copy in rom
3822: CD 00 3E call $3E00
..
3879: 73 ld (hl),e
387A: 23 inc hl
387B: 72 ld (hl),d


I’m not sure why this is, I don’t think the 2nd copy can be banked in, maybe it’s an older copy of the game code before they fixed a bug, I haven’t worked out when the code is called either.

Anyway, the game is fully playable, although clocks and refresh rate aren’t verified. Here are some screenshots (and yes, the 16-pixel border on the left is correct, only test mode uses the full width)

I’ve also uploaded a video of it to YouTube, not being played well, but enough to show you the game.

When a game shares a name with a different but much better known game it can prove tricky to track down, and, in cases where nothing is known other than the title it’s difficult to know if you’re looking for an original game, a license, or a bootleg.

Philko’s Lock On is one such game, sharing it’s name with the still rather obscure, but better known (in part due to emulation) Tatsumi game from 1986.

Until yesterday we didn’t really know what to expect from this game, but completely out of the blue a user called ‘marcus’ dumped a PCB for it and submitted it for us to emulate.

There are a few Philko games in MAME already, a couple of shooters running on hardware that was cloned from Side Arms (Whizz / Dyger / Turtle Ship) and some simple puzzle style games on a sprite-less System 16 hardware clone (Atomic Point and Snapper)

Looking at the PCB / roms the hardware here didn’t quite fit either of those profiles, it was 68k based, so no the sidearms derived hardware, but it also had sprite roms, so it wasn’t identical hardware to the System 16 titles, also it had an OKI M6295 in sound section which none of those have either.

The sprite roms were clearly non-tile based, and looked clearly like Sega System 16 format sprites, so the first and most logical route to explore was that this was a more complete clone of Sega System 16 hardware than used by the other Philko titles. There were a couple of issues with this assumption, first of all, the tile roms were clearly 4 bits per pixel graphics whereas the original System 16 hardware and Philko clones were all 3bpp. (In English this had 16-colour per tile, not 8-colours per tile)

Either way, I quickly hooked it up in the System 16 driver, and it booted, even showing me some sprites, the assumption WAS correct, however it would need further work, Philko had made significant changes to the hardware while copying it. It was immediately obvious that the palette RAM was bigger, again, fitting with what had previously been observed, if you have 16 colours per tile then you need more colours in total. Oddly, even with that all set up, and the base of the sprite palettes adjusted accordingly the colours were still off. It turned out that palette format had also been changed here, from the xRGBRRRRGGGGBBBB format of the original hardware to a simpler xBBBBBGGGGGRRRRR (where each R/G/B letter represents a single colour bit) Adding support for that alt format fixed the colours.

Sound was also different, I used the emulation from Whizz as a base, because clearly, from observing the reads / writes that’s what Philko had done, but here there was also an extra port used to access the OKI M6295 sample playback chip. As none of the clocks were measured on the PCB, nor the divider pin for the OKIM6295 I’m not 100% sure the sound is perfect.

With all that hooked up, inputs sorted out, and dipswitches deciphered to a usable level the game was playable. It seems like it was heavily influenced by Capcom’s US Navy / Area 88.

Interestingly the game doesn’t show a copyright on the title screen, but there’s a Philko disclaimer on the startup, Philko tiles in the tile ROMs, and a 1991 date on the bottom of the high score table, one of the dipswitches flips between ‘Korea’ and ‘Europe regions. Philko was also one of the few Korean manufacturers to actually have their own marked custom chips too (albeit only one of them on this PCB, the others had generic markings)

Also of interest is that the game does attempt to program what appears to be a clone of the Sega memory mapper chip (used for dynamic memory maps on System 16 etc.) although I haven’t currently hooked it up as dynamic, might have to see if it really does program valid values tho.

Again Big thanks to marcusfor dumping his PCB here. The picture provided alongside the ROMs is shown below.

I’ve also uploaded a video below, you can see some minor clipping issues on the left side in attract, but I’m 99% sure those will happen on a PCB too, the image it’s scrolling around is part of one of the tile layers and simply isn’t wide enough to cover the area where you can see the blank space.

Another one that was all but forgotten this time last week saved from extinction.

Nosunosu and ShouTime got this obscure Korean title dumped.

It’s so obscure I’m not 100% sure who actually made it, there’s no manufacturer information shown onscreen, in the ROM, or on the PCB.

There’s an entry in the Korean games database for it but that’s about it.

Seems to be unique (but simple) hardware, the whole thing was emulated from scratch using MAME / MAME cores in around 3-4 hours.

I’ve recorded a video below, and will probably put up some static screenshots later.

Refresh rate and PCB clocks for the 68k / M6295 haven’t been measured so are guessed at the moment, but it looks and sounds reasonable to me; it’s not even a bad game even if it borrows all its ideas from Rally-X

*edit* here are some snaps

For those wondering, yes, most of the graphics in this game are stolen from elsewhere, there are 3 sets of background tiles for example
The first set is from ‘Sim City 2000’ ( you can easily see one of the buildings that was stolen near the center of the image at http://www.moma.org/interactives/exhibitions/2011/talktome/assets/TTM_211-large.jpg )
the second set is from ‘The Settlers 2’ ( the catapult shown on http://img3.picload.org/image/argppro/testen.png is one of the buildings)
and the third set of tiles is from Caesar 2 ( you can see several of the buildings in http://www.agamesroom.com/library/images/screenshots/caesar2/caesar2ss3.gif )

SC2k was originally released in 1994, the other 2 were 1996 releases, which makes sense considering this was likely released around then too.

Vas Crabb made some improvements to Cat and Mouse a while back, but in the end we discovered that one of the graphic roms had been dumped as half size.

We knew Vernimark owned a PCB of this game, so I got in contact with f205v to ask him if he could double check the ROM and dump it as the correct type. This process took a couple of weeks, but eventually f205v got back to me to tell me that the job had been done.

f205v updated his site with the details .

Using these details, and a bit of deduction Vas was able to find how the game banks the sprite ROM; on the PCB there’s a wire leading around the PCB from one of the pins on the chip at L14 (the graphic rom) which I guess has something to do with it, see the image linked below. In emulation terms, it’s an otherwise unused bit of the sound latch. Also note, the position next to the socket is marked for a 2716, which is presumably why the rom ended up being dumped half size, the ROM on the PCB is actually a 2732.
http://www.citylan.it/wiki/images/a/ad/174_main_PCB_component_side_detail5.jpg

Vas also improved the colours in the game using the close-up of the resistor network
http://www.citylan.it/wiki/images/c/ca/174_main_PCB_component_side_resistors_detail.jpg
however it is possible one of the values is still slightly wrong because the 3rd resistor down on the left-most column looks like it might hav been repaired / replaced in the past, as Vas noted in the driver

“Blue uses 47R and 820R on the PCB we have a photo of, although the 47R resistor looks like it could be a bad repair (opposite orientation and burn marks on PCB)”

So if anybody else has a Cat and Mouse to double check that it would be good, the impact of it potentially being wrong is nothing serious, as the value we’re using works well, but it would be good to know the original value for sure. Also if anybody has a Cat and Mouse PCB that runs the ‘set 2’ from MAME then the last program rom on that set still needs redumping, it should also be a 2732, not a 2716, Vernimark was unable to help with that because his PCB is the ‘set 1’ PCB in MAME.

Anyway, here are some screenshots of it running with the improved colours and correct sprites; the old lady with broom sprite was completely missing in the previous graphic roms, as was one of the orientations for the dog.

MAME 0.170 has been released over at mamedev.org.

The Snow Board Championship progress shown below is included in the release, although currently still relies on the decryption table (luckily it compresses down really well, to about 60meg) That’s the only really noteworthy thing I was involved in for this release, been a bit busy.

The S14001A improvements should not be overlooked, they were contributed by one of the guys who worked on making the original hardware and provide a noticeable improvement in the sound quality for Berzerk etc.

If you haven’t already checked out the ‘Wing Force’ prototype you really should do, such a shame the game never made it to market because it’s a really good take on the general ‘Raiden’ formula. Only real downside is that it’s a bit too easy, and the game hadn’t got to the stage of the dipswitches being hooked up so there’s no way to adjust the difficulty, still, it’s a good fun game, especially for the more casual players who might have found shmups to be already be getting a little difficult by the time.

One final important note, the 0.170 release could do with a good bit of testing, some core changes went in that mean some bad code that was ‘safe’ before is no longer safe, and will cause MAME to crash, there were quite a lot of drivers programmed using this bad assumption, and while Tafoid, Mooglyguy and myself have tried to eliminate all the obvious ones with some extensive regression testing the tests we’ve been able to do only cover driver startup, which means that we’re not getting 100% code coverage. If you encounter anything unusual, eg. missing sound, graphics, or just outright crashes that didn’t happen in 0.169 then please let us know, on a project this size it’s practically impossible to test every case ourselves so we are relying on end users.

To close this rather short article I’d like to make one final callout to a few people who haven’t yet got in touch with us about relicensing their code. Any code that we do not get permission to relicense will need to be dropped from the project and rewritten, something we would prefer to avoid if possible.

The most significant of these is ‘insideoutboy’ who worked on a few drivers with me back in the early 2000s, working on drivers such as ‘Popper’, ‘Car Jamboree’, ‘Flower’ ‘Super Cross II’ and ‘Marine Date’ The only contact information we had for his is an old (no longer active) hotmail account, as well as some also no longer used / active accounts on forums (the old ztnet ones etc.) It seems that nobody has really heard from him outside of the period he was active. There are users on gamefaqs with the same username, but they’ve already been contacted and deny being the same person. To the best of our knowledge he was located somewhere in Australia, so if you have friends there who contributed back in the day who might have gone by that name, please do let them know we’d like to get in touch.

Two other fairly significant ones are ‘Edgardo E. Contini Salvan’ who wrote the driver for Namco’s Toy Pop / Libble Rabble, ‘Enrique Sanchez’ who wrote the Yie Ar Kung Fu driver, and ‘Ed Mueller’ with the Birdie King driver.

There are a couple of others too, for non arcade drivers, and one or two where where we have contact details we still haven’t tried yet, but if anybody does know for sure who the above people are, and can point them back our way that would be preferable, ideally we’d like to relicense drivers as BSD-3 clause, but GPL / LGPL is also an option. Dropping drivers and rewriting them is a last resort, but if no contact is made we will have no choice but to do that.

I was staring to think we weren’t going to get any Snow this year, only rain, lots and lots of rain….

However, even if there’s no snow outside, I can present you with some snow for MAME, in this case the news that Gaelco’s SnowBoard Championship is a step closer to being emulated.

Unlike most Gaelco games which used an evil Dallas protection device complete with suicide battery, SnowBoard Championship instead used a less complex device programmed to do some decryption tasks, and used as protection. The game was passing various things to the device, like text strings, sample numbers, and some directional direction used by the game, it expected correct data back in order for the game to run properly.

Previously in MAME the game would display corrupt text, hang during attract mode, play incorrect samples and have completely broken controls.

The operation of the device turned out to be simple, actually even less complex than I was first expecting. I’d already briefed Charles MacDonald (who purchased a PCB for running our tests) that the game writes 32-bits of data to an address, and reads 16-bits back from another address, and that it uses different pairs of addresses throughout execution, so naturally I was expecting the different addresses to use different encryption schemes, one of his first discoveries was that the address was completely irrelevant, done only to throw off anybody trying to understand it.

With this knowledge he made a few mods to the hardware and software running on the board to collect the 16-bit results for all possible 32-bit writes the game could make, resulting in an 8GB table.

I hooked this 8GB table up in MAME to verify the results and the game immediately started working.

We still need to reduce the 8GB table to actual equations, Olivier plans on looking at this, but rest assured the game is now very close to being playable in a public build of MAME. (RAR compression manages to reduce the table to a 180MB file, there are clear patterns all over the place, so I doubt even that is especially complex)

Here’s a video recorded from MAME, it’s recorded using the 2.1 parent set.

Both the 2.1 and 2.0 sets use the same encryption, so here are some screenshots from the 2.0 set for anybody not wanting to watch the video.

and for those wondering, yeah, I’ve still got more to add to the 0.169 article below, just this came up today, I’ve also got to at some point turn the yearly summary article into something publishable ;-)