00
For the record, the S1 sound driver in a proper S1 rom beings at offset $72E7C and is $1760 bytes long. You'll notice in Hivebrain's disassembly that the z80 driver is split into two parts, with 5 bytes defined in between them (look at label Kos_Z80). This is because the Sega sound's location and length is stored in the sound driver, so this allows the Sega sound to be easily relocated without having to mess with the sound driver itself. I digress, but I do bring out that if you plan on changing the sound driver and reinputting it into the rom, you'll either have to put it in as one piece, or split it up again, remove the 5 bytes defining the sega sound's attributes, and arrange it the same way as Hivebrain did. This isn't about that, so I'll leave that aspect up to your own devices.
Anyway, this is about the DAC drum samples in Sonic 1. The reason I told you about extracting the S1 sound driver is simply because the PCM samples used for the drums is actually located in the sound driver itself! however, it isn't raw PCM data. The z80 ram area wouldn't have enough space to do that properly. Instead, they are in a lossy (I believe) compressed form, and are actually decompressed in real-time by the z80. How does this work?
First, open a decompressed sound driver (I'll provide one here http://www.cgi101.co...hole_decomp.bin , but if you were able to get the compressed data from the S1 rom, you could easily decompress it using the Koszinski format). You'll notice lots of hex values and crap. What's interesting is that the actual code is actually very small. Less than $100 bytes small actually. The rest of the sound driver is the compressed data. Look at byte $D6. What we have here is a table that's $18 (24) bytes long. Each entry is 8 bytes long, so this table describes exactly 3 DAC drum samples as used by Sonic 1. The format is:
bytes 1/2 - The location in Z80 memory of the DAC compressed data (little endian)
bytes 3/4 - The size in bytes of the compressed data (little endian)
bytes 5 - pitch/sample size
bytes 6-8 - unused
As for how the data is compressed, lemme explain that real quick: First, it is a lossy compression. So if you recompress a PCM sample this way, you will lose precision in data. Anyway, what happens is that each compressed data is seperated into nybbles (1 4-bit section of a byte). This first nybble of data is read, and used as an index to a table containing the following data: 0,1,2,4,8,$10,$20,$40,$80,$FF,$FE,$FC,$F8,$F0,$E0,$C0. So if the nybble were equal to F, it'd extract $C0 from the tale. If it were 8, it would extract $80 from the table. Etc. etc. Anyway, there is also another byte of data that we'll call 'd'. At the start of decompression, d is $80. What happens is that d is then added to the data extracted from the table using the nybble. So if the nybble were 4, the 8 would be extracted from the table, then added to d, which is $80, resulting in $88. This result is then put bank into d, then fed into the YM2612 for processing. Then the next nybble is read, the data is extracted from the table, then is added to d (remember, d is now changed because of the previous operation), then is put bank into d, then is fed into the YM2612. This process is repeated until the number of bytes as defined in the table above are read and decompressed.
So basically, to add your own samples, you'd have to decompress the sound driver, find the table, input your own compressed PCM samples into the driver (you can't use the last few bytes of memory, but you do have about 1KB worth of extra space to use), change the tables to reflect the locations, length, and pitch of the new samples, then somehow recompress the driver and input it back into the rom. And remember, you can change the tables in the z80 using the 68k. in fact, Sonic 1 does this quite a bit when it plays the third drum sample, in order to change the sample/rate pitch.
For reference, I've uploaded the decompressed raw PCM samples, as well as three wav files of the drum files that are closely approximated in sound to the real thing
http://www.cgi101.co...n2050/dac1d.bin
http://www.cgi101.co...n2050/dac1d.wav
http://www.cgi101.co...n2050/dac2d.bin
http://www.cgi101.co...n2050/dac2d.wav
http://www.cgi101.co...n2050/dac3d.bin
http://www.cgi101.co...n2050/dac3d.wav
I hope this information will help fellow S1 music hackers in their quest to make awesome sounding music
EDIT - And for the record, I'm working on a decompressor and compressor for this, but if anyone else can do it faster than me, be my guest
Anyway, this is about the DAC drum samples in Sonic 1. The reason I told you about extracting the S1 sound driver is simply because the PCM samples used for the drums is actually located in the sound driver itself! however, it isn't raw PCM data. The z80 ram area wouldn't have enough space to do that properly. Instead, they are in a lossy (I believe) compressed form, and are actually decompressed in real-time by the z80. How does this work?
First, open a decompressed sound driver (I'll provide one here http://www.cgi101.co...hole_decomp.bin , but if you were able to get the compressed data from the S1 rom, you could easily decompress it using the Koszinski format). You'll notice lots of hex values and crap. What's interesting is that the actual code is actually very small. Less than $100 bytes small actually. The rest of the sound driver is the compressed data. Look at byte $D6. What we have here is a table that's $18 (24) bytes long. Each entry is 8 bytes long, so this table describes exactly 3 DAC drum samples as used by Sonic 1. The format is:
bytes 1/2 - The location in Z80 memory of the DAC compressed data (little endian)
bytes 3/4 - The size in bytes of the compressed data (little endian)
bytes 5 - pitch/sample size
bytes 6-8 - unused
As for how the data is compressed, lemme explain that real quick: First, it is a lossy compression. So if you recompress a PCM sample this way, you will lose precision in data. Anyway, what happens is that each compressed data is seperated into nybbles (1 4-bit section of a byte). This first nybble of data is read, and used as an index to a table containing the following data: 0,1,2,4,8,$10,$20,$40,$80,$FF,$FE,$FC,$F8,$F0,$E0,$C0. So if the nybble were equal to F, it'd extract $C0 from the tale. If it were 8, it would extract $80 from the table. Etc. etc. Anyway, there is also another byte of data that we'll call 'd'. At the start of decompression, d is $80. What happens is that d is then added to the data extracted from the table using the nybble. So if the nybble were 4, the 8 would be extracted from the table, then added to d, which is $80, resulting in $88. This result is then put bank into d, then fed into the YM2612 for processing. Then the next nybble is read, the data is extracted from the table, then is added to d (remember, d is now changed because of the previous operation), then is put bank into d, then is fed into the YM2612. This process is repeated until the number of bytes as defined in the table above are read and decompressed.
So basically, to add your own samples, you'd have to decompress the sound driver, find the table, input your own compressed PCM samples into the driver (you can't use the last few bytes of memory, but you do have about 1KB worth of extra space to use), change the tables to reflect the locations, length, and pitch of the new samples, then somehow recompress the driver and input it back into the rom. And remember, you can change the tables in the z80 using the 68k. in fact, Sonic 1 does this quite a bit when it plays the third drum sample, in order to change the sample/rate pitch.
For reference, I've uploaded the decompressed raw PCM samples, as well as three wav files of the drum files that are closely approximated in sound to the real thing
http://www.cgi101.co...n2050/dac1d.bin
http://www.cgi101.co...n2050/dac1d.wav
http://www.cgi101.co...n2050/dac2d.bin
http://www.cgi101.co...n2050/dac2d.wav
http://www.cgi101.co...n2050/dac3d.bin
http://www.cgi101.co...n2050/dac3d.wav
I hope this information will help fellow S1 music hackers in their quest to make awesome sounding music
EDIT - And for the record, I'm working on a decompressor and compressor for this, but if anyone else can do it faster than me, be my guest
This post has been edited by jman2050: 25 April 2006 - 01:40 PM
