DarkPortrait Posted December 31, 2008 Share Posted December 31, 2008 ok how the hell do you do sound hacking on roms its really anoying seeing people do it and i dont know how can someone enlighten me on this matter please stuart Quote Link to comment Share on other sites More sharing options...
EarthQuake Posted January 1, 2009 Share Posted January 1, 2009 ok how the hell do you do sound hacking on roms its really anoying seeing people do it and i dont know how can someone enlighten me on this matter please stuart This is something where you need good knowledge of assembly. Most games have routines that store values to the sound-related hardware registers. Thing is, each game is different, so you not only need to know where these routine calls are in the binary, but how they work. Unless you get a hold of the disassembly and change the form of the sound effects to be generated, you probably won't be able to do much in regards to how the sound is structured, just by hacking the binary. There are three parameters to work with when dealing with sound: volume, frequency, and the noise type (IIRC). Different games do different things to put these parameters to use. My knowledge about sounds on the VCS are pretty limited, so I hope my answer was correct. Quote Link to comment Share on other sites More sharing options...
DarkPortrait Posted January 1, 2009 Author Share Posted January 1, 2009 ok how the hell do you do sound hacking on roms its really anoying seeing people do it and i dont know how can someone enlighten me on this matter please stuart This is something where you need good knowledge of assembly. Most games have routines that store values to the sound-related hardware registers. Thing is, each game is different, so you not only need to know where these routine calls are in the binary, but how they work. Unless you get a hold of the disassembly and change the form of the sound effects to be generated, you probably won't be able to do much in regards to how the sound is structured, just by hacking the binary. There are three parameters to work with when dealing with sound: volume, frequency, and the noise type (IIRC). Different games do different things to put these parameters to use. My knowledge about sounds on the VCS are pretty limited, so I hope my answer was correct. well thanks for the help all i know is to look throught the AUDxx and find were it is located but thats all Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 1, 2009 Share Posted January 1, 2009 AUDxx addresses are the registers. What you are looking for is the values stored to them. For example, this sets channel 0's volume to maximum... lda #$0F sta AUDV0 Undoubtedly, you won't find many instances of "hard-coded" routines like this in a program (because it wastes space having to load specific values whenever you want to update something). Usually, a ram location (or group of locations) hold variables to point at specific data...use those variables as offsets to read values from a data table or number of tables, then put those values in the approprite AUD registers. Here's a primitive example that uses 3 rom tables and 1 ram note counter: Sound_Subroutine: ldx Note_Counter;load a note counter from ram bne Do_Next_Sound;branch if notes remain stx AUDF0;kill sound stx AUDV0 stx AUDC0 rts;and exit Do_Next_Sound: dex;adjust counter to point at next values lda Frequency_Table,x;load current pitch from rom sta AUDF0;...and store lda Volume_Table,x;load current volume from rom sta AUDV0;...and store lda Distortion_Table,x;load current distortion from rom sta AUDC0;...and store stx Note_Counter;save note counter for next time rts;and exit That example can play up to 255 notes (tho it doesn't include the number of frames to sustain each one). You'll notice that X is used as the offset for each table, and A is used to pass the values. If the program you are looking at uses A to store the values (as in sta AUDF0), backtrack to see where it's value came from. The same is true for the 2 other registers X and Y. Quote Link to comment Share on other sites More sharing options...
DarkPortrait Posted January 1, 2009 Author Share Posted January 1, 2009 (edited) AUDxx addresses are the registers. What you are looking for is the values stored to them. For example, this sets channel 0's volume to maximum... lda #$0F sta AUDV0 Undoubtedly, you won't find many instances of "hard-coded" routines like this in a program (because it wastes space having to load specific values whenever you want to update something). Usually, a ram location (or group of locations) hold variables to point at specific data...use those variables as offsets to read values from a data table or number of tables, then put those values in the approprite AUD registers. Here's a primitive example that uses 3 rom tables and 1 ram note counter: Sound_Subroutine: ldx Note_Counter;load a note counter from ram bne Do_Next_Sound;branch if notes remain stx AUDF0;kill sound stx AUDV0 stx AUDC0 rts;and exit Do_Next_Sound: dex;adjust counter to point at next values lda Frequency_Table,x;load current pitch from rom sta AUDF0;...and store lda Volume_Table,x;load current volume from rom sta AUDV0;...and store lda Distortion_Table,x;load current distortion from rom sta AUDC0;...and store stx Note_Counter;save note counter for next time rts;and exit That example can play up to 255 notes (tho it doesn't include the number of frames to sustain each one). You'll notice that X is used as the offset for each table, and A is used to pass the values. If the program you are looking at uses A to store the values (as in sta AUDF0), backtrack to see where it's value came from. The same is true for the 2 other registers X and Y. wow thanks nukey ur like the god of rom hacking!!! can u hack nes roms???? cuz z i used to hack them all the time it was easy! Edited January 1, 2009 by DarkPortrait Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 1, 2009 Share Posted January 1, 2009 If you are interested in decyphering existing 2600 binaries, understanding 6502 machine language is a prerequisite. Working with reverse-engineered source codes makes it quite a lot easier. Otherwise...it's "look at the program, guess at what something does, alter it to test your guess, label/comment it if your guess was correct". Repeat a few thousand times. Quote Link to comment Share on other sites More sharing options...
DarkPortrait Posted January 1, 2009 Author Share Posted January 1, 2009 If you are interested in decyphering existing 2600 binaries, understanding 6502 machine language is a prerequisite. Working with reverse-engineered source codes makes it quite a lot easier. Otherwise...it's "look at the program, guess at what something does, alter it to test your guess, label/comment it if your guess was correct". Repeat a few thousand times. true, true its a pain in the ass though!! Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 1, 2009 Share Posted January 1, 2009 Perhaps the biggest mistake anybody can do is trying to understand a foreign language from a raw disassembly (which tells you nothing). Distella is able to pick out the hardware registers, but that's it. The rest...including code/data that Distella misses detecting...needs to be done by hand, figuring out the smallest things, labelling it, search/replace all occurances, then moving on to something different. Even if it's not what you were looking for, it's something eliminated from what's unknown. Stella's debugger can help here too, because you can break out of the program at any point and look at the values that currently exist in ram. Trying to look at a disassembly with no understanding of 6502 and no editing will leave you overwhelmed with no progress at all. If time is a factor, you might be more comfortable with something easier to grasp (like Basic programming, which does the difficult stuff for you). Quote Link to comment Share on other sites More sharing options...
DarkPortrait Posted January 2, 2009 Author Share Posted January 2, 2009 Perhaps the biggest mistake anybody can do is trying to understand a foreign language from a raw disassembly (which tells you nothing). Distella is able to pick out the hardware registers, but that's it. The rest...including code/data that Distella misses detecting...needs to be done by hand, figuring out the smallest things, labelling it, search/replace all occurances, then moving on to something different. Even if it's not what you were looking for, it's something eliminated from what's unknown. Stella's debugger can help here too, because you can break out of the program at any point and look at the values that currently exist in ram. Trying to look at a disassembly with no understanding of 6502 and no editing will leave you overwhelmed with no progress at all. If time is a factor, you might be more comfortable with something easier to grasp (like Basic programming, which does the difficult stuff for you). lol yeah pretty much time aint a consern just learning how is the hard part Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.