• ▲ Gambling Junk-A-Thon

Plenty of gambling boards have surfaced. They're canadian built (Blitz System) and pretty much use the same blitter based hardware as last post's Funny Fruit, which now lives in blitz68k.cpp:

They use from one to three 68HC705C8 MCUs for protection, so none of the games work. But here's as far as I could get them to, by patching the ROMs..

The Hermit (Ver. 1.14):

Deuces Wild 2 - American Heritage (Ver. 2.02F):

Bank Robbery (two versions):

Mega Double Poker Jackpot (Ver. 1.26):

Mega Double Poker (Ver. 1.63 Espagnol):

Maxi Double Poker (Ver. 1.10):

Dual Games (prototype):

Thanks to ChrisQC, Smitdogg and The Dumping Union.

• ▲ Funny Fruit

I've added this video slot by Cadillac Jack to ilpag.cpp (written by David, Angelo & Tomasz):

The blitter is functionally identical (or very similar) to that in the other two supported games, but with a rather different memory layout. So the implementation is kept separate at the moment, while adding image flipping and support for consecutive blits.

Sound is missing since the DAC is handled by a 68HC705C8 MCU with 8KB of internal ROM (not dumped). Apart from complaining for the missing sound CPU handshake at boot, the game currently freezes while trying to print the redemption tickets.

Thanks to Smitdogg and The Dumping Union.

• ▲ Pac-Slot

This Pac-Man themed video slot is a medal game for kids running on cave.cpp hardware:

It was released in 1996 by Namco among a host of video and electromechanical games based on the pop icon.

Thanks to Bicycle Repair Man.

• ▲ Janputer Special

Another iteration of the Mahjong / Pachinko hybrid Janputer '96, added to royalmah.cpp:

Also added an earlier revision of Mahjong Neruton Haikujiradan to dynax.cpp.

Thanks to gamerfan, ranger_lennier, Smitdogg and The Dumping Union.

• ▲ IGS011/IGS012 Protection

I've improved igs011.cpp by emulating the protection in the IGS011 and IGS012 chips. No new games are working because of this, but the result is a more faithful emulation and understanding of how their hardware really works.

Initially I used ROM patches to completely bypass the protection checks, in order to concentrate on the rest of the hardware. So now I could remove around 150 of those patches (if you notice new bugs, as always, please report on MAME Testers).

These games are protected in several ways, to prevent bootlegging of the hardware or running new games on old hardware:

Encryption - A per-game address lines scrambling plus an address based XOR that affects the program ROMs and, in some games, the graphics ROMs too. This was already taken care of (mostly by other people, except for one game).

IGS011 - This is the graphics chip, but it has some built-in protection as well. The addresses where the protection is mapped change per game, but it turns out there's a register controlling the range to use. So in theory it's a dynamic thing, even though in practice the games set it once and for all at boot time, and thus use a fixed range. The protection involves an internal value that can be incremented or decremented by writing to the above address ranges. It can also be transformed through boolean functions, and the result goes to a second value, that can be then (or later) written back to the main protection value. The latter is read through a further boolean function, and is checked for correctness throughout the game code.

IGS011? - A second protection is present in nearly all games. It's almost identical to the above IGS011 protection, with the difference that: it uses a fixed address range (i.e. it can't change at run time, even though it changes per game); has no second value (the boolean functions affect the main protection value directly); the functions to transform and read the protection value are different for each game and revision (unfortunately).

IGS012 - This has no other purpose than protection, and it works similarly to the IGS011 protection. An internal value can be incremented, decremented and its bits can be transformed through boolean functions using a second value as buffer. A further boolean function of the protection value is then checked from time to time. The chip is mapped in memory at a fixed address range, but with mirroring. In addition, it's possible to toggle the address for the mapping between two ranges. It turns out that many games where these protection checks were patched out never actually run those checks, as the IGS012 chip is missing from their boards. For instance Dragon World version 1,3 and 4 are not protected while version 2 is, but they all contain the checks.

IGS003 - This is the chip used for i/o handling. It contains an 8255 programmable peripheral interface, plus a simple protection that returns a fixed string from some additional registers. In some games however, it also returns a parametric boolean function than I haven't bothered to understand yet. So ROM patches are still in places to bypass these checks in some games (lhb2, vbowl). Note that sometimes the chip is replaced by a plain 8255 (e.g. in lhb) and, indeed, no protection checks are run in those cases.

Note that it is possible to emulate this kind of protection devices by inspecting the game code and reproducing what the 68000 CPU does in a few lines of C code in MAME. This is unlike chips that independently perform complex tasks, such as part of the game logic. Those cases usually involve a microcontroller (MCU) with undumpable internal ROM. Those can't be easily reverse engineered (if at all) and that's when decapping is the only viable option.

Thanks to f205v for PCB infos and pictures.

• ▲ Alien Challenge

With the priority changes in lordgun.cpp, and the graphics roms dumped, Alien Challenge is now playable, also thanks to the protection patches sent by XingXing:

This was the first combat game by IGS. Screen shots are from the World version, even though most text is in Chinese anyway.

The Chinese version (currently in MAME as Huang Fei Hong) is partly dumped. It shares the sound program and samples roms, has an earlier revision of the program roms and lacks a dump of the graphics. By overlaying the upper part of the World version program roms, and by providing its own protection patches, it boots. The only difference I can see, using the graphics ROMs from the World version, is the program revision in test mode and the boot screen (it even shows the FBI logo). At any rate, I'll mark those program roms as bad dump (half size).

The game uses a multi-sprite mode that was previously unimplemented, and also shows that the sprite-list-end handling in the driver was wrong. The missing background music still needs fixing.

Thanks to XingXing, alexgizh, Smitdogg and The Dumping Union.

• ▲ Lord Of... Priorities

I've figured out and implemented RAM based priorities in Lord of Gun. Before, sprites were drawn above all tilemaps, and tilemaps were incorrectly ordered with respect to each other (see previous post).

Here's a side by side comparison:

▼ Correct Priorities	Wrong Priorities ▼
▲ Correct Priorities	Wrong Priorities ▲

The way priorities work on this hardware, lordgun.cpp, i.e. how the order of the various layers of graphics is decided, is similar to that of the blitter based IGS games in igs011.cpp.

There are 64k of priority RAM. Each 16-bit word contains one of five values, that map to the five layers (4 tilemaps + sprites). For each screen pixel, the opacity of the layers and their priority are translated to an address in priority RAM, and the pixel of the layer specified by priority RAM at that address is sent to the screen.

This is the most flexible solution as it allows for rather funky priority schemes and masking effects. Also note that sprite-sprite priorities are decided according to the sprite list order, and are thus orthogonal to sprite-tile and tile-tile priorities, allowing for even more flexibility.

To form the priority RAM address, first the opacity of each layer is stored in one of the 5 low order bits (0 = opaque, 1 = transparent). Then, and this is where it gets more complicated than on the other hardware, three of the layers, and sprites, also specify a per tile priority level (0-7), thus contributing 3 additional bits * 4 layers, that go in the remaining high order bits of the priority RAM address.

Actually, that's too many address bits for 64k of RAM, so one of those layers is limited to only 1 bit of priority level instead of 3.

With this scheme in place, graphics are correct AFAICT, and some scrolling levels, like the jungle one above, exhibit a nice layered parallax effect now.

• ▲ One-Eyed Bandit

GeGeGe no Kitarou is a famous manga about a one-eyed boy born in a cemetery. It makes perfect sense (?!) to create a video slot based on its characters, aptly called GeGeGe no Kitarou Youkai Slot:

This game runs on previously unemulated hardware by Sigma with a Z80, YMZ280B for sound and zooming 16/256 color sprites.

Thanks to A. Hoekman, ranger_lennier, Smitdogg and The Dumping Union.

• ▲ Andamiro's Hammer

We got a nice redemption game by korean Andamiro, that goes by the laconic name of Hammer (2000):

Flyer from Arcade Flyers:

As you can see it's a whack-a-mole game that lets kids win tickets or prizes. It must be a popular genre, as I've done a few already (Animalandia Jr., Monkey Mole Panic, The First Funky Fighter).

This is the first in the series, with selectable English or Korean text. Andamiro then went on to produce Hammer DX and Hammer 2, which are not yet dumped.

Hardware-wise it runs on the same hardware as Live Quiz Show, i.e. a reengineered Neo-Geo clone called Midas (midas.cpp). The cabinet has a large touch screen, a plastic hammer and a shock sensor.

There is no PIC this time, but the top board hosts an AT89C52 microcontroller with 8KB of flash memory (undumped), probably to interface with the touch screen. But the game just reads the touch coordinates in the input ports, so it works regardless.

Thanks to Guru, Smitdogg and The Dumping Union.

• ▲ Jumpman

Thanks to The Dumping Union we have a medal game (gambling) by Namco. It's Tobikose! Jumpman (1999):

As you can see the game involves timing your jump to leapfrog increasingly difficult obstacles. It runs on cave.cpp hardware.

• ▲ Metro's Mouse Is Back

Nice little addition, a funny puzzle game by Metro named Mouse Shooter GoGo:

It's an earlier chapter in the Bang Bang Ball and Battle Bubble series, i.e. a Puzzle Bobble-like gameplay, with added dodging and a Reversi twist.

The game runs on the usual metro.cpp hardware. The only graphics glitch is some jerky scrolling on the title screen, due to a known limitation of the driver.

Thanks to Stefan Lindberg and The Dumping Union.

• ▲ Astro Corp. (part 2)

Here's another game running on astrocorp.cpp hardware (see also part 1). It's called Skill Drop Georgia:

Apart from having double the resolution, it uses the hardware in a slightly different way than Show Hand, revealing several features of the sprite chip that were either unemulated or incorrectly implemented. Namely wrap around, negative coordinates, end of sprite list and the need for a frame buffer.

Thanks to Smitdogg, Brian Troha and The Dumping Union.

• ▲ Permalinks

Small site update. I just implemented Permalinks. Posts can now be individually linked, their URLs don't change over year boundaries, and they're more search-engines friendly. You can get the permanent links from the titles of the posts or from the menu on the right.

• ▲ Ibara

Cave are world famous for their manic shooters (弾幕 danmaku, aka "bullet hell").

I have been experimenting with Cave's newest hardware platform, based on a currently unemulated Hitachi SH-3 CPU (having written cave.cpp for their older 68000 based system, some ten years ago).

The game in question is Ibara, a gorgeous shooter that bears more than a similarity to Raizing's Battle Garegga and Battle Bakraid. In fact they were all programmed by Shinobu Yagawa (his Recca, on the NES, being the grandfather of them all).

WIP screen shots of Ibara (2005) are below, but first...

The graphics chip is an FPGA, programmed at boot by the main CPU. It does high-color graphics blitting with support for several blending modes. The current implementation is probably reasonable, but some details are to be improved. I think colors are a bit off in shadows, for instance, although that may be caused by the low resolution I use to perform the mixing (5 bits). Graphics are stored in 128 MB of flash memory - the chips you can find in USB pen drives or in SSDs - and are loaded in RAM on demand (see the funky loading screen).

For more infos on the hardware and games see World-of-Arcades and System 16.

Thanks to Guru.

• ▲ Year 2009

Read posts from last year