Extracting Sounds With Acid And UV

Toaplan was a Japanese video game developer in the 80s and early 90s, most famous for Zero Wing, the source of the ancient ‘All Your Base’ meme. Memeology has come a long way since the Something Awful forums and a pre-Google Internet, but MAME hasn’t. Despite the completionist nature of MAME aficionados, there are still four Toaplan games with no sound in the current version of MAME.

The sound files for these games is something of a holy grail for connoisseurs of old arcade games, and efforts to extract these sounds have been fruitless for three decades. Now, finally, these sounds have been released with the help of sulfuric acid and microscopes.

The sounds for Fire SharkVimanaTeki Paki, and Ghox were stored on their respective arcade boards inside the ROM for a microcontroller, separate from the actual game ROM. Since the fuse bits of this microcontroller were set, the only way to extract the data was decapsulation. This messy and precise work was done by CAPS0ff, who melted away the epoxy coating of the chip, revealing the microcontroller core.

Even without a microscope, the quarry of this hunt was plainly visible, but there was still no way to read out the data. The built-in read prevention bit was set, and the only way to clear that was to un-set a fuse. This was done by masking everything on the chip except the suspected fuse, putting it under UV, and checking if the fuse switched itself to an unburnt state.

The data extraction worked, and now the MAME project has the sound data for games that would have otherwise been forgotten to time. A great success, even if the games are generic top-down shooters.

46 thoughts on “Extracting Sounds With Acid And UV

      1. But why not have samples instead of no sound in the MAME files for so many years? If the recording was direct audio output to a digital recording device input it should be quite hard for the human ear to distinguish the difference. Especially since I’m sure these original sounds aren’t super high quality recordings.

          1. Anything the human ear can hear can be sampled, whether it’s FM or otherwise. I’m talking about taking the speaker output and connecting it to a digital recorder. Even if it wasn’t 100% it has to be better than nothing for 3 decades. Maybe there weren’t any working boards only ROMs and that’s why it wasn’t sampled.

        1. The sounds related to game play events in a complex way so you would need to take a sample of each distinct sound sequence and that may be impractical for some games where there may be tens of thousands of different sequences.

        2. The MAME people are an odd bunch. In this day and age they still insist on having ROM filenames in 8.3 format. Right now my ROM folder has 28,000 files and they are all individually zipped. The graphical interface has to read all 28,000 and then compile its own list.

          That said, congrats to the people who accomplished this.

          1. True, there was (is?) a lot of resistance to accepting original input for games like 720°. For years, the developers opted towards the “common denominator” mentality favoring keyboard/mouse I/O. Not sure exactly why that was though I have heard on argument addressed the intermediary USB.

            IIRC, a patch was available for a long time but was long considered a hack and not suitable for the main branch.

            But I digress, I’ve long suspected the 8.3 convention was due to this “common denominator.” Like using .zip files is?

          2. It does not read them all. It only reads the ones it needs. I know this because the past week or two I have been hip deep in trying to speed up the loading of those files so verify roms will go faster. Think I have it from 8 hours across a network down to 1ish.

            You can also use .7z files if you want some of your space back too. If you want to mass convert them you want a util called torrent7zip.

            The big one for 181 is the votrax. They have a pretty good grasp on how it works and what is needed. This removes the need for many of the sample files that have been in there since 2000ish. Like parts of wizard of war and qbert no longer need samples and fingers crossed gorf.

            i agree with the 8.3 bit. Internal is longer but the external is still 8.3. For the ‘mess’ side everything could be longer but they keep it short. The mess side chds most are longer names. It has at this point be warped out of control and they should let it go. My bet is once someone says ‘go for it’. They will rename everything.

          3. No we don’t, stop spreading FUD.

            First of all, you don’t understand the difference between a “ROM file” and a ZIP containing a bunch of ROM files, which is correctly called a “ROM set”. The individual ROM dumps within ZIPs can and have been longer than 8.3 for a long while now, and in the past year the project has removed the setname length restriction. We simply haven’t gone and done a mass rename on romsets, simply because of the chaos that that would cause for users, but there are quite a few clone sets that have setnames longer than 8 characters.

    1. Clearly not a gamer.

      I don’t recall if they sampled the audio for these games, but it’s likely they did at one point. Most of the games on MAME used samples until (I forget the version) a blanket policy was implemented to drop the samples and go for true audio emulation. This was accompanied by a drop in performance at the time so many people with low end machines stayed with the samples.

      Anyways, even if every sound byte is never mixed, you’re facing the very real problems of the recording hardware not sampling the audio correctly. A digital recorder is still affected by whatever analog circuitry is in front of those pins. Some audio capture cards (Windows…) will do a sort of auto ranging normalization. Annoying as fuck to deal with. Nevermind any post shaping or mixig the Arcade PCB is apt to do.

      Even if you manage to connect something stupid (ahem… Arduino) in a pure pin to pin data connection, you’re left with analyzing that data and, lets be frank, unless that bit of code is the coders baby, they’ll just cut between spikes and move on. Hardly anything close to accurate for another two or three years.

      Only by having the pure, unadulterated, data can you ever hope to meet the purported goal, “to preserve decades of software history.” Simply sampling the audio does not do this in any shape, way or form.

      1. If you take the raw electrical data going to the speaker it could be recorded with a digital recorder (not necessarily a digital audio recorder). Speakers are very simple devices, Apple II computers created sound by turning the speaker on and off quickly (not quick enough to make good quality audio mind you but it was what they had to work with at the time). These games and other audio output devices do the same just with more samples per second. Of course the data would have to be recorded and interpreted properly but it’s not rocket science.

        1. Alright Justin, I’ll tell you what I tell everyone else who says, “it’s not rocket science.” Feel free to grab any one of the featured games in the above article and do the work yourself. The real hardware, no cheating by running the game in MAME and sampling that. ;-P That means getting the damn thing working (ever fix a CRT?) and playing however many hours to get all the samples you need. Make sure it’s pin to pin recording, none of that pesky analog circuitry to get in the way. Pack those samples along with the required code to run them in MAME, then present the whole shebang to the public.

          Let me know when you’re done.

          1. As you said I’m not a die hard gamer so this doesn’t interest me enough to spend much effort to do anything in that regard. I have an electronics background and yes I have fixed CRT monitors. I own full size arcade games and multiple JAMMA and NAMCO boards but unfortunately not the ones in the article. I would attempt it my way before resorting to acid and microscopes. :)

        2. In practice, it is nearly impossible to get good, clean samples from many games because the game sound engine mixes several sources – like background music, enviromental sounds, explosions and whizzing bullets – before sending the audio to one or two output channels.

    2. Wouldn’t you have to isolate each individual sound the game could generate? That sounds like a huge pain in the ass if there’s music or multiple effects going on simultaneously.

  1. MAME ‘s goal is near exact emulation of exact ROMsets dumped from original hardware. A sound capture wouldn’t meet the requirements :)
    MAME guys do try to do their share of video game preservation, hence all those efforts : making exact dumps.
    In fact you can resuscitate old arcade PCBs by burning ROMs from MAME on brand new EPROMs.

    “Generic top down shooters” well, that’s a tad reducing. Some arcade shoot’em ups are so depth full that they haven’t yet revealed all their secrets even to gamers playin them for decades. Battle Garegga anyone ?

  2. The game code has to be able to read the sound data, so why not make a ‘lobotomized’ version of the ROM that does nothing but access the sound data in the same way as the regular game code? Then it could cycle through it all and dump it to binary files.

    1. In this case there was no way to ‘lobotomize’ the thing externally. The sound came out on the pins from the chip. So what he did was cover the rom UV the thing and then dump it. The link to CAPS0ff in the summary has a description how he did it. Basically the chip was external to the cpu and memory bus. They blasted commands at it but had no idea what the program rom was. They know the CPU inside that chip but not the program data. No way to get at it other than basically what they did because of the protection bit in there. The process he is doing allows them to remove that protection and do exactly what you said.

      1. The sound data was stored separately than the game data. The sound data was protected by a physical circuit “fuse” built into the chip. He basically remanufactured the “fuse” by blasting it with UV light much the same way the entire chip was manufactured in the first place. Since he had to expose so much of the chip in the process of removing the top of the chip, he had to mask off the rest of the data and exposed circuit so nothing else but the “fuse” was modified with the UV blast.

    2. I think the ROM is actually embedded inside the CPU chip and protection fuses were set so the CPU won’t run code from external memory and an external programmer can’t read the ROM. If you go to the CAPS0ff blog, they decapped the CPU, masked off everything except the protection fuses using some kind of UV-filtering liquid, and exposed the fuses to UV to reset them allow the internal PROM to be read out. The blog makes it sound routine but to me that’s an awe-inspiring “experts only” feat of skill.

    3. In this case the game doesn’t read the sound code. If I’ve understood this right, and I think I have (it’s a not-uncommon problem with emulating arcade machines)…

      The sound chip in question is not the main CPU. It’s a separate microcontroller, like an Arduino or Atmel or PIC chip. The main CPU sends it command bytes, and the microcontroller produces sound through one of it’s pins. So it’s a chip that takes commands in, sounds out.

      It’s a black box. It’s a standard microcontroller with it’s own onboard ROM. As you probably know, most microcontrollers have a code-protection fuse. This means you can use it in your commercial product, without your competitors being able to buy that product, copy your chip’s ROM, and manufacture millions of their own. The chip reads it’s ROM but won’t share it with the outside world.

      So to get at it’s ROM you have to do what the super-smart chip hackers do, and get the acid out. In the case of mask ROM you can read the bits with a microscope, since they’re formed by connections on the physical chip. In the case of EEPROM or PROM, you can’t, because 1s and 0s look the same, since they’re just static charges, invisible.

      So what you do is you physically locate the code-protection fuse, on the die, and reset it. In this case with UV, same way you erase EPROMs with UV. Then you use the chip’s inbuilt ROM-dumping function, which is used during production testing to check you’ve programmed it right, that is when it’s not disabled by the fuse of course. Then you’ve got your ROM.

      When you’ve got the ROM you can emulate the microcontroller in MAME, with your newly-recovered code. The emulated game’s main CPU can send it’s emulated commands, and your emulated micro sends the requisite beeps. MAME pays attention and sends it through the sound card.

      Getting code out of ROMs in embedded chips is also a skill the guy who hacked pay TV used. It’s another HAD article today. It’s an amazing skill. The people who make secure microcontrollers have to protect against it, and there are methods involving special wires in the chip’s packaging that detect if they’re broken, onboard backup batteries, as well as light sensitive elements that detect if the packaging’s removed. But they cost more, and aren’t always practical to use.

      1. Actually just to add (always think of something after I press post)…

        It might be the micro doesn’t produce the beeps itself. It might be that it takes in commands (“play sound x001, start playing music x005”) from the main CPU, and then controls a synth chip, sending the right notes as needed to play the music etc. The Sega Mega Drive / Genesis did the same, it’s 68000 did the main processing, and a separate Z80 chip, with it’s own bit of RAM, controlled the synth chip.

        Actually you didn’t have to do it that way on the Mega Drive, but it’s the way Sega intended.

        In the case of this article, it’s a single-chip microcontroller rather than a Z80, but same principle applies.

        1. Didn’t the Mega Drive / Genesis have that Z80 to be able to run Master System games? And since it was already a requirement to add that Z80, SEGA decided to let it run the audio for the Mega Drive / Genesis games?

      2. Sorry for multi-post but… I’ve been to both sites, and yes, that’s it… A controller which actually IS a Z80 (-based clone) controls a synth chip. The code in question is all on EPROM, onboard it. Though the EPROM isn’t usually erasable because there’s no window in the package. Of course with the packaging removed, it becomes erasable, so it needs protecting from UV, hence the red stuff.

      3. hm if PROM can’t be read under a microscope, that’s bad news. I have (don’t own it but still) a rare Model Racing Super Shot from 1980. The machine works, its owner says it’s the last one on earth, MAME does not have sound. I’m currently fixing the sound module, most sounds work now, but there are two 74LS188 PROMs with 32 bytes each. One contains a sample waveform that is fed into a resistor ladder DAC. The chip sadly has the electrical characteristics of a wooden doorknob. The other ROM still works. I mean, ok, maybe the matrix is still intact and decapping the chip and probing it with VERY fine needles might get me the ones and zeroes stored in there. Until then I’ll probably susbstitute it with one cycle of a sine wave.
        Anyone want to try his/her luck at that chip? The machine is located near Hanau, Germany.

          1. Basically, I’m at the Arcade and Pinball machine museum Seligenstadt (Flipper und Arcademuseum/For Amusement Only) almost every weekend. Found and replaced two more defective chips on the soundboard, now all sounds work except the Place Sound for glasses and bottles sounds like it’s not supposed to sound like that (loud crack) and when you get extended play, the game pauses and appears to try to play a melody but nothing comes out but a few quiet cracks. Speaking of rare machines with unemulated extra features (ie. Sound), we have Sega’s N-Sub in perfectly working condition.

        1. As far as PROM goes, it depends, there are two types. The original type used tiny fusible links, little actual fuses, that you’d blow to program it. Then when EPROM was invented, everyone realised that an EPROM with no window to erase it, is pretty much a PROM, and better than the fuse type too, so they switched to that.

          EPROM uses a static charge to store bits, but the 74LS188 is older and uses fusible links (so Google tells me). That involves a physical change, actually fusing them. So mmmmmmmaybe a microscope could see the difference between fused and unfused?

          1. What is the risk to inadvertantly blowing the fuse during the acid process?

            I’m sure some one has it worked out but I don’t recall anything other than EPROM and ROM mask chips getting the acid treatment.

          2. If an utter guess is acceptable, I think not much chance of acid blowing the fuses. Since they’re polysilicon, used in most ICs, so not reactive with the acids used in decapping (or else decapping would destroy the chip, of course). The fuses are blown through heat, from the voltage / current flowing through them during programming.

  3. I don’t know jack about samples versus the original, but I feel it must be possible to guesstimate the original bit patterns from a (large) collection of recordings. Think machine learning…

    1. Actually, as a MAME dev, this article doesn’t do a particularly great job at explaining what this chip did. In fact it absolutely botches it.

      The chip in question is a Z(1)80 microcontroller with 16 kilobytes of ROM on-die, as well as its own RAM and its own peripheral chips. Anyone who reads Hackaday should be familiar with this concept, it’s the same as your Atmel AVR, just a different architecture.

      This chip did not, in fact, produce sounds. What it DID do was run its own internal program code which did the following:
      – Polled inputs (joysticks, DIP switches, coin slots) and passed them to the main CPU
      – Played music tracks by reading tracker-like data from its internal ROM, similar to processing a MIDI sequence, and issued the correct register updates to a separate Yamaha FM synthesis chip and a sample-player chip.
      – Played sound effects, driven by code running on its internal ROM, by issuing the correct register updates to the aforementioned FM synth and sampler chips.

      The chip played absolutely no role in *generating* the sound. It played the entire role in *coordinating* the sound chips, and accepting raw commands (‘play music track #N”) from the main CPU.

        1. The graphics encryption has long since been solved. The main issue with Raiden II, and possibly Raiden DX, is the fact that they had a whole hell of a lot of copy protection in the form of a separate gate array chip, the Seibu COP, which handles things like collision detection and enemy pathing. As far as I know, the COP isn’t 100% emulated, but it is emulated well enough that Raiden II is playable.

    1. Funny thing is, that was the article that I originally sent in to the HaD tipline. They posted this one instead, despite that one being waaaaaay more in line with the hacker ethos. Go figure.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.