I want to create HTML5 versions of some classic Atari 2600 games and was wondering if there's any possible way to rip all sound effects from a game's ROM file.

Until now, I've tried using Stella with Audacity, but I'm looking for a faster or automated solution.

  • 4
    I take you have checked the copyright restrictions on those sound clips.
    – Chenmunka
    Jan 18, 2018 at 14:52

6 Answers 6


Ignoring the copyright issues of such an endeavor, you're going to have a very hard time of ripping audio in a conventional sense. Old games don't store their sound effects and music as waveforms like modern PC and console games do. This is because both the audio hardware on old computers and consoles was much more limited, and because there wasn't enough RAM or ROM space available to hold the sounds as waveforms in the first place.

Most old computers with sound capability would have a certain number of sound channels with varying abilities to adjust the tone and frequency, making them primitive synthesizers and not devices suitable for general purpose audio playback. The Atari 2600 had two circuits with the ability to adjust frequency, waveform type, and volume. As part of a program's sound playback routines, the program adjusts the appropriate control registers to get the machine to make the sounds it wants.

This means that the only way to 'rip' such sounds is to do what you've been doing, i.e. record them from the output of an emulator (or original hardware), since that's how instructions to the synthesizer are turned into actual sound output.

  • In support of this answer: at least up to and including the Atari ST, two generations later, some of the music preservation file formats are essentially ripped game code for piping into a suitable simulator. So it was quite a while after the 2600 before hardware got complicated enough to make audio simple.
    – Tommy
    Jan 18, 2018 at 16:52
  • @Tommy: It wasn't more complicated hardware that made audio capture simple--instead it was the improvements in main-CPU horsepower that made it practical to have the output waveform generated entirely programmatically instead of in hardware.
    – supercat
    Jan 18, 2018 at 17:50
  • 2
    On emulators that can capture a log of executed instructions to disk (I know z26 could; I'm not sure about Stella) it would be possible to write a program that would read such a log, identify all actions that affect audio, and reproduce the output waveform somewhat more accurately than most emulators typically do. Emulators usually take some shortcuts with sound generation that don't usually affect the audio noticeably, but which in some games might have objectionable consequences.
    – supercat
    Jan 18, 2018 at 17:54
  • @supercat I feel like that's true only of the PC, where "CPU got fast enough to make up for lack of hardware" was once the recurring story. 'Gaming' computers went straight from generation to wavetable synthesis with the Amiga and consoles did the same thing as of the SNES. The CPU doing any sort of mixing as a matter of course is really only the one platform.
    – Tommy
    Jan 18, 2018 at 18:39
  • 1
    Also, offered for potential audio capture if there is any reason that the better emulators aren't doing audio well enough: for the Atari 2600 mine generates an internal stream at half the CPU clock rate, then applies a FIR low pass to get down to whatever your output device actually supports. You can find it via the Github account linked to my profile; I don't want to try to use this site to advertise beyond that. I really don't think it's worth your time unless you have an issue with Stella though.
    – Tommy
    Jan 18, 2018 at 18:46

I'm going to chance my arm that there's no automated solution because there's no [realistic] automated way to find and trigger all the possible sound effects. You're probably going to have to be a human who plays for long enough to figure out how to trigger all the sound effects, in which case you almost might as well have captured them when you play.

Given that Atari 2600 games generally don't have music (i.e. Pitfall 2 aside), I can imagine a tool that automatically separated sound effects from a long recording, but that would probably be more straightforward by post-processing whatever you captured.

Top tip though: the audio counters inside the TIA are clocked at 1/38th the rate of the CPU.

So in the NTSC Atari 2600 the CPU is clocked at a third the speed of the colour subcarrier, so approximately 1193181.8Hz, and the TIA can update its output level autonomously at only 1/38th of that = around 31399.5Hz.

On the PAL (and, I think, SECAM) Atari 2600 that's 1182298/38 ~= 31113.11Hz.

I don't think that CPU changes to things like volume are synchronised to that clock and Stella's a generally excellent emulator so it's not quite true to say that sampling at 31400 Hz will exactly capture all NTSC sounds, but I think for this purpose it's close enough to true.

  • 1
    You seem to be assuming chroma of 3.58416Hz, I don't think I've ever heard of that value. Normal NTSC chroma is exactly 455x525x15x(1000/1001)Hz, or 3,579,545.4545Hz.
    – supercat
    Jan 18, 2018 at 19:48
  • @supercat agreed on the implication and its improbability; will check my sources but mainly because I'm curious as to why I believe(d) otherwise. In any case, the essence of the point is valid, I think, that 33xxx Hz is likely to convey the full Atari feeling, in the context where you are capturing a fixed list of audio effects for use in a remake. No advocations beyond that.
    – Tommy
    Jan 18, 2018 at 20:02
  • What's important is that the audio rate is precisely CPU/38. A 0.1% deviation in frequency won't matter for anything except color decoding circuitry (where it might cause a slight color shift from one side of the screen to another). I think some of RCA's computers used weird clock frequency that was almost but not quite equal to chroma (3.53Mhz), (perhaps because the designers of the 1863 video chip found it convenient to have a multiple of eight clocks per scan line and thought chroma/224 would be acceptably close to standard horizontal sync, but then later decided it wasn't).
    – supercat
    Jan 18, 2018 at 20:45
  • I think the PAL 2600s' clock frequency is "unique" to those machines, being reached via somewhat similar process to the 3.53Mhz used by 1863-based computers (pick a crystal frequency that makes some existing divide ratio yield a necessary horizontal scan rate) but I don't think there's anything weird in the NTSC 2600.
    – supercat
    Jan 18, 2018 at 20:47
  • @supercat even amongst the documentation I have put into my own little collection, I'm at a loss for where the other number came from. So I've changed the answer. Your logic is compelling.
    – Tommy
    Jan 19, 2018 at 14:08

Using Stella and Audacity is probably best after the next release of Stella. We are currently working on cycle-exact audio emulation, and already we have it to a point where certain games are working perfectly.

Games like E.T. (where the ship landing sound shouldn't be so harsh) and Ms. Pac-man (where the sound channels interfere with each other and generate some weird effects) are working perfectly with the latest beta code.

  • 4
    My 2600 emulator has had "cycle-accurate" audio emulation for almost three years so I would question the research behind your "never sounded right in any emulator" claim. Which did you test? Cf. github.com/TomHarte/CLK/blob/master/Machines/Atari2600/… — it's always possible that it's not accurate due to an implementation error, of course, but it is a genuine attempt with good results that applies the proper cycle-by-cycle logic to a high-frequency wave that is filtered down to your host system's output frequency.
    – Tommy
    May 27, 2018 at 0:54
  • 1
    Welcome to Retrocomputing Stack Exchange. Please read the tour. This sounds a little like marketing speak; please replace "any emulator" with a list of the emulators that you have tested etc. (Tommy's emulator is really good, so I wouldn't be surprised if his claim is correct, but I'd never heard of it until I spotted it in one of his comments.) Also, it would be a good idea if you made it more explicit that you are a developer for Stella; currently it's only two pronouns that give that away.
    – wizzwizz4
    May 27, 2018 at 9:00
  • Sorry for adding a comment, to be honest. It was not my intent to be confrontational, and I have no desire to continue a conversation in such a manner. I have never heard of your emulator before, nor did I realize you were working on one. I have tested Stella, z26, Javatari, MESS, Emu7800 and BizHawk. From that POV, yes, the code we've added to Stella plays sounds correctly that none of those other emulators do. Good luck with your work on your emulator; I will not bother commenting again.
    – user8714
    May 27, 2018 at 22:52
  • 2
    @user8714 it's not a great 2600 emulator otherwise; everything is implemented at the cycle level but the TIA is imperfect — it could run Meltdown properly before Stella could, but still has errors with relatively simple things like California Games. It does much better at being other machines. But audio is straightforward so I'm more confident about that. The rules aren't very complicated and it's sampled at a high rate then subjected to a windowing low-pass filter. This definitely wasn't worth leaving the site over! There'll be lots of technical 2600 questions you could have answered!
    – Tommy
    May 28, 2018 at 20:39

Many old systems don't have sounds in the way you think of them. Instead, the game has several pre-recorded notes (recorded as in written by hand, probably not more than a byte or three), which the game or program can use in succession.

To get these notes, I suggest using TheSoundsResource.

Keep in mind that what you're doing may have copyright issues, as others have commented.

  • 3
    There are no pre-recorded notes on old systems. They're just programmable oscillators so nothing is recorded as the sounds are generated on the fly. The Amiga was the first mainstream computer to play back samples, along with the Apple 2GS. The Atari 2600 has 2 very simple oscillators with absolutely nothing pre-recorded so this answer is misleading.
    – Thomas
    Oct 29, 2018 at 14:45

As others suggested, by ripping sounds, graphics, etc. from games you are hitting some legal issues. Similarly like using emulators with ROM files. Anyway there are more options to do this...

  1. specific file format

I am not familiar with Atari but on Z80 + AY-8912 based sounds there is the:

Which contains sounds related stuff (both Z80 sound routines and sound data). There where some tools for sound extracting to an AY files. Here first hit in google I found just now:

May be on Atari there is something similar. I would start with searching for sound chip / circuitry ID and relevant file format for it. If found then its just a matter of google search...

  1. sound engine

If no such Atari related file format found then you need to either identify sound program with what the sound was created. Back in the days there where common known sound engines that where widely used so usually by identifying the type of sound or number of channels or specific effects you already know the music routine...

As the sounds where usually a mix of polyphony synthetizer (usually 3 channels) and PCM effects (1 or 2 bits) and PCM Noise it can be sometimes converted to:

  • MIDI
  • MOD or STM wavetable based formats

so WAV/MP3 is not the only option here. But without a proper tools for your platform it would need big effort to do such thing...

If you know the sound program then you can more easily locate the sound data and subroutines for playback easing up the extraction (by automating it).

  1. Record the sound from emulator or real HW

For arbitrary sound you need to play the game/program record everything and hope you did not miss too much sounds.

  1. Open source

In some cases some games have been open sourced over the years in such case its easier to download the source code with data and use that than extracting the stuff from binaries...


was wondering if there's any possible way to rip all sound effects from a game's ROM file.

The Atari generates sound by the CPU manipulating registers on the TIA "in realtime" with the rest of the code driving the display and running the game.

It does not give a separately running sub-CPU a "sound #" and order a sub-CPU to play samples like Genesis, SNES, many arcade platforms and others.

The sound generator portion the TIA does use periodic square wave combinations, which can be computed or sampled,, but each game will modulate frequency, volume, and selected waveform differently in code. Some games modulate parameters according to game events and "playing sounds back" might not even make sense apart from the actual game.

So there's no "ripping" unless you want to do this:

  • Reverse engineer the ROM (or find a disassembly) and find the code that modulates the TIA registers
  • Extract this code and modify it to make it work without the rest of the code.
  • Develop or integrate a 6502 emulator and enough of a TIA emulator to emulate the sound. (FWIW There are Emscripten-based JS Atari emulators).
  • This emulator would have to run at 1Mhz in the background to produce accurate sound.
  • Develop an interface for an external program to talk to the code being executed by the virtual 6502 from an external interface, such as a Javascript function call or other event, so you can trigger sound effects by index number.

The .NSF format is exactly this for NES music. I'm unaware of existing efforts for Atari 2600 ROMs.

Until now, I've tried using Stella with Audacity, but I'm looking for a faster or automated solution.

Fastest you can do for now unless you are a 6502 assembly wizard.

  • What you are describing is pretty much what people do for C64 music as well Oct 26, 2021 at 20:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .