Jump to content
DarkPortrait

Sound Hacking how the hell?

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :(

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by DarkPortrait

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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!!

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...