Catching Fire

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

first copy in ROM
3822: 73 ld (hl),e
3823: 23 inc hl
3824: 72 ld (hl),d
...
3879: CD 00 3E call $3E00

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.

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