I spent a lot of time on MAME project from around 1997-2004. For those that don’t know MAME is an open source emulation project for old arcade machine hardware and emulates almost all old arcade games. MAME was originally written in C though it has been refactored several times since 1997 and is currently C++.
The process of arcade emulation is a unique challenge – usually no instructions, documents or schematics were available so the emulation is based on reverse engineering and educated guesswork. Usually you start with just the raw ROM data which can be viewed in a hex editor. From this you identify what looks like code, what is graphics, what is sound, just from the hex patterns. Typically for code you would look for something identifiable – for example the 68000 CPU has a distinctive vector table at the start of memory map – from that you can guess reset and IRQ vectors. With that you could guess what those IRQ’s may be – a vertical blank (refresh) interrupt is the common one – around 60 times a second. When you have the CPU emulator executing that code you can see what it writes to and what it reads from – from this you can start to build a memory map of the target hardware. ‘Main’ memory is easy as usually the CPU stack is placed there – what can be more complex are the graphics co-processors. Now-a-days they would be called GPU’s and old arcade hardware would typically have several of these ‘GPU’ chips – 1 or 2 dedicated to sprites, and maybe 3 or 4 dedicated to each ‘layer’ of tilemap graphics. Like modern computers the CPU would write instructions or often simple ‘layouts’ for the GPU chips to generate the on-screen visuals. Each hardware platform would typically have it’s own graphic processors with their own unique input format. Emulation consists of mimicking what these processors do in order to produce the same pixel output within the emulated game.
Anyway, this page just acts as a list of the major things I worked on – feel free to contact me if interested in any of them! Sometimes I still get email from owners of the real arcade hardware asking for advice on repairs. Often understanding how the hardware translates to the software is useful for repairs (for example if sprites were the wrong colour you could trace this to the palette RAM chip, or to the sprite ROM data bus connection to the sprite processor).
The table is sorted by MAME driver filename as this usually shows a good split between hardware types.
|Act Fancer / Trio The Punch, Data East H6280 / M6502 hardware platform, actfancr.c
The 8 bit H6280 CPU was a bit under-powered by comparison to other games around 1989, certainly Data East had released M68000 games as early as 1987 – so this was probably intended as cheaper budget hardware.
|Time Soliders / Gang Wars / Sky Soliders, etc, Alpha Denshi M68000 / Z80 hardware platform, alpha68k.c
The graphics hardware is an early version of what would eventually become the NeoGeo.
|Battle Rangers / Bloody Wolf, Data East H6280 / M6502 hardware platform, battlera.c
This is an interesting anomaly in the Data East hardware line – the CPU and graphics are effectively a PC Engine console with double the VRAM, but the sound hardware is in line with regular Data East games of this era. The PC Engine audio is present on the CPU die but not used at all.
|Beast Busters / Mechanized Attack, SNK M68000 / Z80 hardware platform, bbusters.c
Fairly standard SNK hardware for the time.
|Bogey Manor, Technos M6502 hardware platform, bogeyman.c
Although published by Technos this actually used Data East hardware.
|Boogie Wings / Great Ragtime Show, Data East M68000 / H6280 hardware platform, boogwing.c
This was obviously a high budget project for Data East as the game is very long and packed full of high quality details! The programmers made great use of the tilemap hardware to simulate full screen rotation.
|Crude Buster / Two Crude, Data East 68000 / H6280 hardware platform, cbuster.c
Fairly standard Data East hardware for this era – similar to Dark Seal and vapor Trail – 4 tilemaps and sprite layer with variable priority.
|Caveman Ninja, Robocop 2, Edward Randy, Mutant Fighter, Data East M68000 / H6280 hardware platform, cninja.c
Caveman Ninja made massive use of a special copy-protection chip Data East had developed to stop piracy. There were hundreds of protection checks in the disassembly… but rather than doing anything underhand if the protection check failed the original programmer simply crashed the CPU with a jump to an invalid address. This made it easy to crack 95% of the protection by just patching all the jump addresses! The remaining 5% was easy to figure out as a pirate bootleg ROM set was available for comparison (Stone Age) – diffing the dumps though actually showed Stone Age had not been fully cracked and would crash on later levels though as a few protection checks had been missed!The programmers on the other games on similar hardware such as Edward Randy and Mutant Fighter learned from this mistake and they made very effective use of protection chip. I had to purchase the original PCB boards and run code on them to analyse the protection values so the game logic would run correctly.
|Zero Target / Counter Steer, Data East 2 * M6809 / M6502 hardware platform, cntsteer.c|
|Dark Seal / Gate Of Doom, Data East 68000 / H6280 hardware platform, darkseal.c
Fairly typical sprite / tilemap setup. The sprite shadow intersection with the tilemap wall is an interesting point in the screenshot to the left – sometimes things like these would be reported as emulation bugs, when in fact they are bugs in the original software, and the emulation is ‘correct’ in reproducing them.
|Desert Assault / Thunderzone, Data East 2 * 68000, H6280 hardware platform, dassault.c
This was quite a unique hardware design for Data East (Deco) – 4 tilemaps plus 2 sprite generators instead of the usual 1 and two 68000 CPUs to drive things instead of 1. Sprites could also be transparent (50% alpha blend in todays terms) – which was very rare in this era of coin-ops as transparency means you have to mix after the palette lookup and then send the result to the priority mixer.
|D-Con / SD Gundam, Seibu 68000 / Z80 hardware platform, dcon.c.
Pretty standard hardware for the time – graphics chips from Raiden bolted onto a 68000 CPU instead of V30.
|Bad Dudes / Robocop / Heavy Barrel / Hippodrome / Sly Spy / Midnight Resistance / Boulderdash / Birdy Try, Data East M68000 / 6502 hardware platform, dec0.c
Bad Dudes was the very first arcade game I emulated – I chose it because the romset was available and it ran on a 68000 CPU – something I knew from the Atari ST. The only other 68000 game in Mame at the time was Rastan so there wasn’t much reference material available. Luckily this hardware is fairly straightforward – logical tilemap arrays and a CPU mainly driven just by vblank interrupts. Bad Dudes does have an i8751 microcontroller for copy protection but it was fairly easy to patch. Robocop also had a bootleg ROM set available with the copy protection hacked out so I got that working fairly quickly also, but in fact it would be several years before I understood how the real protection worked on that game. There is an unmarked HuC6280 CPU on the Robocop game board and the 68000 actually writes the protection program to shared memory where the HuC6280 would execute it. A key detail was that there was a tiny 512 byte PROM also on the game board containing the interrupt vectors and bootstrap code for that CPU, and this wasn’t dumped until much later. Given the HuC6280 was not generally available in 1989 and it’s instruction set private this should have been a pretty strong protection.
|The Real Ghostbusters, Shackled, Last Mission, Oscar, Cobra Command, Gondomania, Captain Silver, Super Real Darwin, Data East M6809 / M6502 hardware platforms, dec8.c
Most of these games actually run on unique hardware but share common components – you can easily trace the development of these 8 bit Data East games to the 16 bit ones in terms of the graphics layouts and i8751 protection microcontrollers. Shackled & Oscar are particularly interesting CPU designs as they use dual M6809 cpus for game logic (plus M6502 for audio) – the cpus can signal each other via FIQ (fast IRQ) for task completion and use regular IRQ for vblank sync.
|Tattoo Assassins / Dragon Gun / Captain America / Lock N Load / Fighter’s History / Night Slashers, Data East ARM / H6280 hardware platform, deco32.c|
|Heavy Smash / World Cup Volleyball, Data East ARM / H6280 hardware platform, deco156.c
For a long time emulation of these games was held up by the encrypted CPU program. It was suspected the CPU itself was an ARM variant, same as Fighters History / Dragon Gun, etc, but the program was encrypted to the point of essentially appearing as static noise. If I remember right the catalyst to breaking this was a bootleg version of Pocket Gal Dx that was found – this allowed a comparison of unencrypted and encrypted and to work out exactly what occured on the CPU die to translate the incoming program to the clear version. Nicola Salmoria worked this out and to this day I’m still in awe of that work – just look at machine/deco156 and see if you can come up with that from the source material! Nicola also worked similar magic with the Deco56 encrypted tilemap chip.
|Skull Fang / Hoops 96 / Avengers In Galactic Storm / Stadium Hero 96, Data East SH2 / ARM / H6280 hardware platform, deco_mlc.c
This was Data East’s final coin-op platform, designed to shift a massive number of sprites around. The actual implementation definitely seems a little strange in the use of indirection – usually an arcade sprite chip reads instructions from ‘sprite ram’ and directly looks up graphics tiles from those instructions. The MLC hardware used that bank of sprite ram to look up a second bank of sprite ram that could either be in ROM or RAM. That second bank then pointed to a further table of sprite indices that could again be in ROM or RAM, and those final indices actually referenced the sprite data ROM chips. It certainly seems hard to see any advantage in this method as it must have used much more complex silicon and addressing.
|Diet Gogo, Data East M68000 / H6280 hardware platform, dietgogo.c
Essentially Data East’s ‘budget’ hardware of the era – 2 tilemaps & sprites.
|Dangerous Dungeons / Thunderstrike / Dark Tower, Technos M6809 hardware platform, ddragn.c
At one point I made contact with the original author of these 3 games – all were conversions for Double Dragon – or in other words new software to run on the Double Dragon hardware. Arcade operators could then upgrade a DD cabinet at cheaper cost than a full new game. This kind of upgrade was definitely not sanctioned by hardware manufacturer Technos however!
|Dynamite Duke / Double Dynamites, Seibu V30 * 2 / Z80 hardware platform, dynduke.c
Similar hardware to Raiden, triple CPU design with 2 main logic processors and dedicated audio CPU.
|Funky Jet, Data East M68000 / H6280 hardware platform, funkyjet.c
I believe this software was developed by Mitchell (Pang, etc) rather than Data East. The hardware is pretty similar to the Tumble Pop pcb.
|Ground Effects, Taito M68020 / M68000 hardware platform, groundfx.c
Like Under Fire, Super Chase and Gun Buster this hardware was a development from the ‘Taito Z’ system of pseudo 3d games (Chase HQ, etc), and shared components with the early F3 games – the 32 bit 68020 main CPU and the powerful 68000/Ensoniq audio system.
|Gun Buster, Taito M68020 / M68000 hardware platform, gunbustr.c
See Ground Effects.
|Haunted Castle, Konami, hcastle.c
This used the special Konami CPU – see Thunder Cross – I also obtained a Haunted Castle PCB to help on this emulation.
|Karnov / Chelnov / Wonder Planet, Data East 68000 / M6502 hardware, karnov.c
These group of games were all protected by an i8751 microcontroller – Karnov was easy to reverse engineer, Chelnov more difficult and Wonder Planet impossible due to the amount of game logic controlled by the protection. I had to buy an expensive original PCB to get the protection data – a pity the game turned out to be by far the worst of these three
|Killer Instinct, Rare R4600 MIPS hardware platform, kinst.c
My name is still in the source for this with a co-credit but I don’t remember much about it! I think I ported the initial version from the standalone U64 emulator to Mame and then Aaron improved it further much later on. The hardware on this game was not what I expected – essentially it’s just a single CPU writing to a pixel buffer – no hardware graphics assist at all – pure software rendering which works from the grunt of the RISC MIPS processor.
|Last Duel / Led Storm / Mad Gear, Capcom M68000 / Z80 hardware, lastduel.c
Pretty regular 68K based game for the time software wise, but it was more of a challenge for the ROM dumper – this was one of the first games to use surface mount mask ROMs for the graphics which cannot easily be removed and certainly no ROM reader adaptor exists. The dumper had to carefully solder each of the surface point pins into a custom loom to get a read.
|Lemmings, Data East M68000 / M6809 hardware, lemmings.c
This was an unreleased prototype arcade game! Although the hardware was from Data East in Japan, software development was at the main Lemmings developer in Dundee, Scotland. This romset made it’s way to MAME from the original programmer, who I met years later. The hardware was clearly hacked around by Deco quite a bit for this project as it uses a pixel framebuffer, quite unlike the usual sprite/tilemap arrangements.
|Boomer Rang ‘R / Yellow Cab / Liberation / Pro Sport, Data East M6502 hardware platform, liberate.c
These boards use an interesting CPU – it is stamped ‘Deco16′ and appears to be a custom CPU chip which is unusual for 1983-84. The CPU has some light encryption built in (bit swaps on data-bus) but the core is definitely based on the common M6502 CPU with the addition of some custom instructions, one of which syncs to the VBLANK signal. A couple of deprotected bootleg programs were available and by comparison you can see where a single instruction in the official program has been patched with a subroutine in the bootleg.
|Bomberman / Dynablaster / Atomic Punk / Risky Challenge, Irem V35 hardware platform, m90.c
This was Irems ‘budget’ hardware of the era – certainly less powerful and presumably cheaper than the M92 motherboard.
|Gun Force / In The Hunt / R-Type Leo / Blade Master / Lethal Thunder / Undercover Cops / Hook / Geostorm / Dream Soccer 94 / Etc, Irem V33 / V30 hardware platform, m92.c
The M92 motherboard was the successor to the M72 board (R-Type, etc) and used the NEC V33 processor – which was essentially a powerful Intel 80186, probably quite expensive for the time. The graphics hardware comprised of sprites and three scrolling tilemaps, but many games made use of ‘raster interrupts’ – so on a certain scanline the CPU would change the state of the graphics chip – perhaps altering the tilemap scroll register. Because there is no framebuffer in this hardware and it syncs directly with the output monitor the graphics already rendered up to that point in each frame do not change – only the graphics ahead of that scanline update (remember CRT monitors scan from top of screen to bottom). Of course this makes emulation more complex as you have to track graphics register changes within the frame – not just at frame end!
|Mad Motor, Data East M68000 hardware platform, madmotor.c
This seems to be a one off hardware design sharing elements from the other Deco games of this time, I believe it was licensed to Mitchell who developed the software.
|The Main Event / Devastators, Konami HD6309 / Z80 hardware platform, mainevt.c|
|Xenophobe, Bally M68000 hardware platform, mcr68k.c
My name is in the driver for this game but I have to give all the credit to Aaron Giles really, for improving my version so much! This was the 2nd system I looked at emulating after Bad Dudes and although I didn’t know it at the time it is one of the most complex CPU setups. A M6840 timer chip is attached to the 68K which is software programmed to fire interrupts at a certain rate. The software on the 68K then effectively implements pre-emptive multi-tasking – stopping and starting threaded game code tasks. This was extremely complex for the time (1987), and remember pre-emptive multi-tasking wasn’t introduced to Windows until Windows 95!
|Nemesis / Salamander, Konami M68000 hardware platform, nemesis.c
I must admit I don’t really remember much about working on this.
|NeoGeo, SNK M68000 / Z80 hardware platform, neogeo.c
I did some work in the original NeoGeo driver, but this system become a bit of flashpoint… Original games were still being made by SNK for this hardware, and some people were really more interesting in playing these pirate games rather than in any of the preservation aspects of MAME, so I bowed out of the driver around that time. For a while this driver and certain games were disabled in the official MAME releases – but third party versions just re-enabled them. That’s how open source projects go…
|Bioship Paladin / Thunder Dragon / Acrobat Mission / etc, NMK M68000 hardware platform, nmk16.c
Fairly standard sprite / tilemaps setup.
|Operation Wolf, Taito M68000 / Z80 hardware platform, opwolf.c
I didn’t emulate this originally, but later done a lot of work on cracking the C-Chip protection, at one point I think I had 3 original PCB’s in various states of broken!
|Pocket Gal, Data East M6502 hardware platform, pcktgal.c
A budget Data East board at the time, simple sprites & tilemap.
|Pipedream, Video System Co Z80 hardware platform, pipedrm.c
Pretty simple 8 bit hardware. Like many 8 bit systems it used bank switching to fit more than 65536 bytes of data into the 8 bit address space – think of like an 8K window looking onto a larger 256K area. Bank switching was rarely used on later 16 or 32 bit games as of course they had enough address space to map everything with room to spare.
|Pocket Gal Dx, Data East ARM hardware platform, pktgaldx.c
This used an encrypted ARM cpu (see Heavy Smash) – once decrypted the hardware is standard for the time.
|Prehistoric Isle, SNK M68000 / Z80 hardware platform, prehisle.c
Similar hardware to Beast Busters.
|Pushman, Comad M68000 / M68705 hardware platform, pushman.c
This used a M68705 microcontroller for protection.
|Raiden, Seibu V30 hardware platform, raiden.c
See notes on the V30 CPU emulator.
|Rohga Armour Attack, Data East M68000 hardware platform, rohga.c|
|POW, SNK M68000 hardware platform, snk68.c
I think POW was the first arcade board I owned… This SNK graphics hardware was certainly a little different from other manufacturers at the time – instead of tilemap hardware the ‘backgrounds’ were generated as sprite strips. You can trace the evolution of this hardware design from the early Alpha Denshi games through this through to the powerful NeoGeo hardware.
|Super Shanghai, Data East M68000 hardware platform, sshangai.c|
|Stadium Hero, Data East M68000 hardware platform, stadhero.c|
|Super Burger Time, Data East M68000 hardware platform, supbtime.c|
|Super Chase, Taito M68020 / M68000 hardware platform, superchs.c|
|Metal Black / Gunfront / etc, Taito M68000 / Z80 hardware platform, taito_f2.c|
|Puzzle Bobble 2 / Darius Gaiden / Bubble Symphony / Bubble Memories / Arkanoid Returns / Light Bringer / Grid Seeker / Pop n Pop / Rayforce / Kaiser Knuckle / etc, Taito M68020 / M68000, taito_f3.c
I wasn’t the first to emulate Taito F3 games on PC, that was the Raine emulator, but I did advance that emulator quite a lot in terms of properly emulating all the effects properly instead of game specific hacks – this hardware was very powerful for it’s time with progammable zooms/offsets/scrolls/palettes per scanline across all of its tilemap layers. Some games used this to great effect to emulate 3d using only 2d tilemaps, whereas others were more traditional. I still own the original Taito F3 system today that I done much of the reverse engineering on!
|Round Up 5, Cycle Warriors, Big Fight, Apache 3, Tatsumi, 68000, Z80, V20, V30, tatsumi.c
Incredibly complex hardware! Up to 4 CPU programs running in parallel, plus very advanced sprite hardware. The original games are quite hard to find, but eventually I located a Round Up 5 and an Apache 3 to run tests on.
|Super Contra / Thunder Cross, Konami, thunderx.c
This used a special Konami 8 bit CPU – it was essentially a M6809 but with the opcodes switched at die level – the opcode table was figured by looking for routines shared with other regular M6809 games from Konami around that time and building up estimates of what value made sense for what opcode.
|Tumble Pop, Data East M68000 hardware platform, tumblep.c|
|Under Fire, Taito M68020 / M68000 hardware platform, undrfire.c|
|Vapor Trail, Data East M68000 hardware platform, vaportra.c|
|Xain’d Sleena, Technos M6809 hardware platform, xain.c
I didn’t originally emulate this game but I’ll call it out here as I improved that emulation a lot from the original PCB schematics – they were quite interesting in the exact timing circuit that builds each scanline is exposed, so things such as vblank length and IRQ timing could be cycle accurate. This fed back into drivers such as Double Dragon and WWF Superstars – although schematics were not available for those games, it became clear the video circuits were almost identical.
|audio/k005289.c, audio/k051649.c||These two are custom Konami audio chips, I didn’t reverse engineer these – but ported them to MAME from a Japanese audio emulation project that I don’t quite remember. The source is still interesting as it shows how digital audio synthesis works at a very low level – running over square or triangle wave buffers at varying frequencies to generate the output.|
|cpu/arm.c, cpu/h6280.c, cpu/v30mz.c||The CPU cores are the engine room of any emulation. My motivation for the ARM core was to run the Deco32 games such as Captain America and Fighters History, motivation for the HuC6280 core was to run the sound program for many 16 bit Deco games and the NEC V20/V30/V33/V35 core was originally to emulate Raiden, though later that expanded to the Irem M92 games (R-Type Leo, etc) also.There was a reasonable amount of documentation to support the ARM chips, and the HuC6280 is of course the CPU in the PC-Engine so there were some reverse engineering documents on the internet about that. With both though the real time was spent in weird edge cases the docs didn’t cover in detail, such as exact stack frame ordering on IRQ’s or exceptions! The NEC V series chips are largely equivalent to the Intel 8088/8086 series though the V35 microcontroller has a great encryption feature where the opcodes are scrambled at the CPU die level!|
|mess/atarist.c, mess/electron.c||I don’t think my Atari ST or Acorn Electron machine emulations are in the head MESS branch anymore – both superceded by other more accurate drivers for those machines. Having spent some time disassembling the BBC Basic ROM I can say what the original authors achieved in only 16K was fantastic!|
|input.c||At one point I agreed to add special MAME support for a PC lightgun by a hardware manufacturer. I’m not sure it’s in the current source anymore, but said device was meant to work with DirectInput or by emulating Windows mouse click event messages. Unfortunately when the hardware turned up the DirectInput driver was horrendously buggy, and the mouse click input pretty inaccurate – maybe plus/minus 30 pixels on average. My apologies if you ever bought one of those devices! Not sure if later hardware revisions or driver updates fixed that.|