I thought it might be a good idea to dis-assemble a rom for the purpose of studying it's code, particularly it's code as it applies to the sound registers.
Could anyone recommend a good (relatively simple) rom for this?
Also, what could I use the dis-assemble?
Thanks again,
T
I guess Capcom games always have sound at a fixed adress, like $c000 or something, and their sound engines are really good, so you'd want to look at them.
I just remembered that I looked at the sound code of Dragon Warrior one day, and it was easy to figure out, and give me one idea or two. That's the only sound code I've looked at before doing my own, and anyway most idea aren't from it anyway.
Bad idea. Commercial games have optimized sound engines, and all you get are uncommented, unlabeled disassemblies. Try one of the homebrew sound engines.
I see... Which homebrew sound engine would be good?
Thanks again,
T
NerdTracker II comes with source code for its playback engine.
You can get FamiTracker's too, at their website. Problem is that there is a lot of programming logic involved in this type of engine (or any engine, for that matter), and you'll find much more data manipulation than actual interation with the sound hardware, I think. So if you're not pretty comfortable with 6502 logic, you won't get very far.
I think Duck Hunt is relatively simple if you want a commercial software...
On the other hand, studying a commercial sound engine that has already been disassembled and documented can be pretty useful.
I started disassembling Megaman's sound engine over 5 years ago but never completed it. But just recently I was positively surprised to learn that someone has continued and completed my work.
You can find both this disassembly and an almost identical disassembly for Megaman2 on
http://bisqwit.iki.fi/jutut/megamansource/.
And for the record, I would have to say that Megaman is a prime example of a badly optimized sound engine. :)
Quote:
On the other hand, studying a commercial sound engine that has already been disassembled and documented can be pretty useful.
That's
my case too
As I've said, I couldn't complete my Battle City disassembly because of sound engine only! So, If you could get rid of that beast, that would be GREAT!
If you want to study a sound engine, check out Friday the 13th. I haven't been on in it much lately, but it's easy enough to find the notes, how long they last... basically how the songs are written. I stopped trying to figure out exactly HOW they make their instruments, how they employ them, etc... but the songs themselves are easy enough to find and understand what they're doing.
I find that it's best to have a "command" byte then data following that. The command byte would hold 8 flags indicating what you want done. For example:
7 - Go to $xxxx
6 - Change Tempo
5 - Change Note
4 - Change Volume
3 - Change Length
2 - Repeat Note
1 - Change Instrument
0 - Silence Channel
SquareWave1:
.db $28,Bflat,QuarterNote
That would define a B flat Quarter Note, because bits 3 and 5 of the command byte are set. You would probably want some different options, but that's the basic idea behind my sound engine. I actually have 2 command bytes, because I want more options. I have bit 0 of the first command byte indicate whether I'll be using the second command byte for anything. If it's not set, it saves me a byte.
Here:
http://sm2.beneficii.net/
http://sm2.beneficii.net/sm2main_.asm
http://sm2.beneficii.net/sm2data3.asm
Near the bottom of each of the 2 last files is the disassembly of the sound systems for SMB2 (J). The first file has the standard music system, similar to SMB1, and the second file has the music system for the victory music at the end of the game.
Bananmos wrote:
And for the record, I would have to say that Megaman is a prime example of a badly optimized sound engine.
but the music is great!!
Celius wrote:
I find that it's best to have a "command" byte then data following that. The command byte would hold 8 flags indicating what you want done. For example:
7 - Go to $xxxx
6 - Change Tempo
5 - Change Note
4 - Change Volume
3 - Change Length
2 - Repeat Note
1 - Change Instrument
0 - Silence Channel
SquareWave1:
.db $28,Bflat,QuarterNote
That would define a B flat Quarter Note, because bits 3 and 5 of the command byte are set. You would probably want some different options, but that's the basic idea behind my sound engine. I actually have 2 command bytes, because I want more options. I have bit 0 of the first command byte indicate whether I'll be using the second command byte for anything. If it's not set, it saves me a byte.
Hey, I don't know if anyone would find this interesting, its primary target not being NES, but here it is:
http://docs.google.com/Doc?id=dr7tkg5_43fbhvcwdm.
I thought about a sound engine relatively small for small devices like Microchip PIC or any 8-bit MCU with a small address bus (16 bit or less). However I thougth it the way it will allow compression of music/sound data with possibility of repetitions and "calling" sub-data for patterns/instruments... see the examples in the link. Just to clarify: the stack mentionned in the doc is a software stack (that you create in your code), not the one the CPU uses. Moreover, the simple bit assignation for actions associated to "opcodes" make decoding easy, and it's useful when running at the same time, on the same channel, some sound effects (that needs a separate stack and a separate wait byte unfortunately).