Atari Sound Format?

[TheAlmightyGuru]

SID, SAP, NSF... these are all wonderful formats that chiptune lovers know and love. My question is, has anyone made a format for housing Atari 2600/5200/7800 audio? I understand that the Atari home consoles were somewhat lacking in the audio department, but there are a few games with pretty catchy tunes, and it would be nice to be able to play them with the convenience of the other game music in my collection.

[TROGDOR]

Hi AlmightyGuru. I'm somewhat familiar with the SID chip, having done some programming for it with the Commodore many years ago. I also did a little wikipedia research on the SID file format.

 

I'm not aware of any atari 2600 sound file format, other than running a binary ROM in an atari emulator. It seems quite possible that atari music could be translated into midi format by replicating the unusual atari frequency tables and the various wave tables. But what you're really asking for here is a TIA (Television Interface Adapter) sound format, which is the chip responsible for producing the Atari's sound effects.

 

Atari music is dependent on the TIA chip and the ROM implementation that generates the TIA input stream. I would guess the easiest way to accurately capture the resulting music/sounds from a binary would be to add a TIA recording feature to an existing emulator such as Stella, and then write out the sound file in either midi format, or some new atari TIA format.

 

Of course, music can be saved today by capturing sound directly from an emulator application into a wav file. But an atari specific format, or midi, would be more concise.

Edited July 18, 2010 by TROGDOR

[raindog]

It probably wouldn't be too hard to patch Stella to print a dump of the TIA sound registers' values once per frame, redirect that to a file and write something to extract changed values and frame counts into some standardized format. That would take care of any game that doesn't hit the sound registers more than once per frame, basically everything that doesn't do digitized sound.

 

Or someone could add the option to log the debug console to a file and variables for current frame and scanline number, and just do it with some trap functions in the debugger. This should support pretty much every game that uses the TIA for sound. Not volunteering as of yet, just throwing out some options.

 

The output file could be MIDI, but that would be a pain because you'd have to have a virtual instrument that maps MIDI events back to TIA register changes (and handles microtuning), and that would be a pain. You could use the XML-based formats of free sequencers like Rosegarden or LMMS, but again, you need that virtual instrument.

 

So the easiest way to make a .TIA file format would be to make it a valid 2600 ROM that does nothing but hit the audio registers and NOP loop till it's time to hit them again. I guess you'd have to bankswitch if it got to be over 4k. Means the people writing the equivalent of SIDplay plugins would have to emulate at least a 6502 and TIA with no video plus bankswitching, but I gather that's the kind of thing some of them are doing already to handle other old chiptune formats. Such an emulator would also be capable of playing back any BIN files that didn't require user input to play their music.

 

Or just a "timestamp AUDF0 AUDC0 AUDV0 AUDF1 AUDC1 AUDV1" format would be fine too, so they could get away with emulating just the TIA. Lots of ways to do this.

[TheAlmightyGuru]

I've noticed some game audio formats to be lacking. For example, most SNES music is in SPC format which is just a dump of the SNES's audio memory. However, this creates problems because some games make dynamic changes to the audio memory preventing the music from being played back properly, or even at all.

 

I'm not entirely familiar with SID and NSF, but it seems like they take the more direct (and tedious) approach of actually ripping out the audio code from a ROM and emulating the Commodore/NES and necessary sound chips to have near-perfect playback.

 

How difficult do you think it would be to extract the audio code from Atari 2600 ROMs in a similar fashion? I'd hate to put work into setting up an audio format and later realizing that it wasn't capable of supporting a good portion of the game library.

[+SpiceWare]

Paul Slocum made one, Music Kit 2.0. It was released back in 2003. It's used for the title screen/easter egg music in Medieval Mayhem.

 

http://www.youtube.com/watch?v=S5huVcpYPzs

[supercat]

It probably wouldn't be too hard to patch Stella to print a dump of the TIA sound registers' values once per frame, redirect that to a file and write something to extract changed values and frame counts into some standardized format.

 

A lot of games hit the sound registers more than once per frame. I'd suggest storing the cycle count where each TIA sound write occurred. A good format might store each write as one byte indicating the register to write and the value thereof (5 bits), and 1-2 bytes for the number of cycles preceding it. Since there are slightly less than 128 meaningful register writes, one bit of the data could be used to select a one or two byte time value.

[B00daW]

There are enough good demos for such a format to be useful now. Liquid Candy by Noice/Trilobit is likely the best TIA music to date.

[Tjoppen]

You could either strip down Stella or fork sidplay and hack TIA emulation into it. Then just play ROMs. No special file format required (except maybe indicating a stop time somehow).

 

For ROMs with multiple songs something like a separate index file with initial CPU/RAM state for each song could work.

 

Oh, and you'll want to run the sound generation at the full TIA rate (3.57 MHz), then downsample after low-pass filtering. This because there's even more advanced audio techniques possible that require better emulation, like dithering to get higher bitdepth.

Edited April 11, 2013 by Tjoppen

[enthusi]

SID files are indeed normal 6502 programs ripped from the original code. A SID player just emulates the CPU, the whole RAM and the Audio-relevant registers.

Same could be done for TIA, BUT most 2600-codes are even more size-optimized than C64 codes. On C64 most music was done with one of the few dozen/hundret composer-tools.

That sounds like quite some diversity, but yet they agreed on quite similar specifications concerning position in RAM and adresses to JSR to etc.

I doubt this could be done equally well for the 2600 with no such standard at all. You could automatically detect the batari-basic player or the different players from Slocum and then rip out the required data.

That would reach a VERY small amount of games though.

Emulating the whole thing using the compolete ROM image is probably the better approach. A 'stellla' without graphical output so to say.

That would also be the smallest solution but it would not help with 'press button' delays or 'tune at end of game'.

In the end I'd suggest to dump all TIA writes as propsed already with the corresponding frame+cycle = 24 or 32 bit (clock?)cycle-exact timing.

That COULD be done automatically for title-tunes/demos AND manually for in-game tunes you want to dump.

The resulting files would be much larger though.

6 registers once per frame at least.

That's 360 Bytes per second WITHOUT the timing. My guess would be around ~2K/s.

Half a megabyte for a 5 Minute tune/demo. That's still fine but more than an order of magnitude larger than ANY complete ROM image.

[raindog]

In the end I'd suggest to dump all TIA writes as propsed already with the corresponding frame+cycle = 24 or 32 bit (clock?)cycle-exact timing.

That COULD be done automatically for title-tunes/demos AND manually for in-game tunes you want to dump.

The resulting files would be much larger though.

6 registers once per frame at least.

That's 360 Bytes per second WITHOUT the timing. My guess would be around ~2K/s.

 

That's why I think supercat's suggestion (dump each register's state every time it changes, with cycle count) makes the most sense. It's essentially run-length encoding. No input issues, no lost data due to sampling too infrequently, even advanced stuff like DPC and sample playback should work, and if there were some human-readable intermediate format, you could even edit it down to just the tunes or sound effects you're trying to get. It could be transpiled into assembly source, depending on how long it was, or maybe the player could be written to emulate only the audio parts of TIA, "decompressing" the dump and feeding the registers as necessary on each cycle. Not having it be 65xx code would mean that if a single note is being held for 10 seconds, it can generate something like "sleep 11900000" instead of loops within loops to deal with 8-bit counters.

 

Yes, SID files contain 65xx code, but in practice they're not the actual game images the music was taken from, or there would have been no need for PSID64. I'm pretty sure you can't take ballblazer.prg, rename it to .sid and play it in sidplay or whatever. (And if you did, it would probably be different every time you played it, anyway.)

[enthusi]

No, SIDs contain just the player-code + data. Usually ripped manually by the HVSC team or provided by the composer himself.

But i.e. most/many players reside at $1000 in memory, are initialized via jsr $1000 and then the game/demo calls $1003 once per frame.

Its really quite often that standardized. Finding all of the corresponding data requires you to understand the player-code though.

 

Using the time-stamping above, sampled speech would become huge rather fast.

The big downside of that format, it will almost certainly not be possible to play them back on a real Atari 2600 due to their size.

Except for maybe some harmony-cart solutions etc.

 

Then again, how many real tunes are there even?

Its maybe the best after all to inspect and disect those and create stand-alone BINs out of that, which in most cases is even pointless since the tune runs from the original BIN anyway.

Edited April 11, 2013 by enthusi

[raindog]

Using the time-stamping above, sampled speech would become huge rather fast.

The big downside of that format, it will almost certainly not be possible to play them back on a real Atari 2600 due to their size.

Except for maybe some harmony-cart solutions etc.

 

I'm not aware of any actual songs on the 2600 that incorporate speech, even as demos (except for a couple of Atarivox demos, but emulating that is beyond the scope of Stella, let alone a VCS song player).

 

The Harmony cart seems like it could be a nice approach to writing an Atari 2600 chiptune jukebox, if there are enough memorable tunes to merit such a thing. Otherwise, there are always the original ROMs.