Hacking the SNES ROM

[David]

Argh, I confused myself. I meant the 11 bytes that describe the Amazon's voice. Like the instruments, there's 11 bytes below the sound effects written space, but I couldn't find the Amazon; I even did an attempt where I erased all 11 bytes and pretty much every sound effect bar the Amazon was muted though I attempted it today and now it is muted...huh.

The description of sound effect "instruments" start at 0xED3A3, and the Amazon's voice uses instrument 43 (@43), so the offset is:
0xED3A3 + 43 * 11 = 0xED57C
(The original bytes are: 13 7F F2 00 00 00 00 00 00 00 00)



Just to clear up some possible confusions, there are *three* kinds of IDs related to sound effects:
(Parts of the following are a rephrase of the SNES format documentation.)

#1: IDs of sound effects.
This is what the game logic uses to select which sound effect to play.
That is, these numbers appear in the disassembly after LDA before "play sound" calls.
The list in my previous post is about these IDs.
When I wrote "yy is the ID of the sound effect or music to play", that too refers to this kind of ID.
This ID selects which (3-byte) element to use from the table at offsets 0xECE02-0xECE8E.

In case of the Amazon's voice this ID is 0x24, which is used at offset 0xCF08.
(The relevant line in the disassembly is: 01:CF07: a9 24 LDA #$24)
From this ID the command string is found in the following way:
At offset 0xECE02 + 3 * 0x24 = 0xECE6E are the bytes 0x05 0x9A 0x04, from which 0x049A is the (relative) offset to the command string.
At offset 0xECDE8 + 0x049A = 0xED282 you can find the command string for the Amazon's voice: T64V15@43O4D2P12#D5-BP0+C2C

#2: IDs of sound effect "instruments".
These are the numbers found after "@" in the command strings at offsets 0xECE97-0xED3A1.
This ID selects which (11-byte) element to use from the table at offsets 0xED3A3-0xED591.

In case of the Amazon's voice this ID is 43. (Or 0x2B, but numbers in command strings are always decimal.)
Therefore, the offset to the 11-byte description is 0xED3A3 + 43 * 11 = 0xED57C, as I wrote above.

#3: IDs of sound effect samples.
These are the numbers you find in the first byte of the 11-byte units which describe the instruments, at offsets 0xED3A3-0xED591.

In case of the Amazon's voice this ID is 0x13.

This really helps as I tried to document them all, but I did it by replacing a sample on a music cue, and I couldn't identify them all.

When you write "replacing a sample", exactly what were you replacing? My guess would be #3 above.

However, please note that music cues use a different set of samples than the sound effects, so you can't hear sound effect samples by changing which sample is referenced by a music cue.
Furthermore, sound samples (#3 above) are different from sound effects (#1 above).

[Shauing]

Spoiler: show

The description of sound effect "instruments" start at 0xED3A3, and the Amazon's voice uses instrument 43 (@43), so the offset is:
0xED3A3 + 43 * 11 = 0xED57C
(The original bytes are: 13 7F F2 00 00 00 00 00 00 00 00)



Just to clear up some possible confusions, there are *three* kinds of IDs related to sound effects:
(Parts of the following are a rephrase of the SNES format documentation.)

#1: IDs of sound effects.
This is what the game logic uses to select which sound effect to play.
That is, these numbers appear in the disassembly after LDA before "play sound" calls.
The list in my previous post is about these IDs.
When I wrote "yy is the ID of the sound effect or music to play", that too refers to this kind of ID.
This ID selects which (3-byte) element to use from the table at offsets 0xECE02-0xECE8E.

In case of the Amazon's voice this ID is 0x24, which is used at offset 0xCF08.
(The relevant line in the disassembly is: 01:CF07: a9 24 LDA #$24)
From this ID the command string is found in the following way:
At offset 0xECE02 + 3 * 0x24 = 0xECE6E are the bytes 0x05 0x9A 0x04, from which 0x049A is the (relative) offset to the command string.
At offset 0xECDE8 + 0x049A = 0xED282 you can find the command string for the Amazon's voice: T64V15@43O4D2P12#D5-BP0+C2C

#2: IDs of sound effect "instruments".
These are the numbers found after "@" in the command strings at offsets 0xECE97-0xED3A1.
This ID selects which (11-byte) element to use from the table at offsets 0xED3A3-0xED591.

In case of the Amazon's voice this ID is 43. (Or 0x2B, but numbers in command strings are always decimal.)
Therefore, the offset to the 11-byte description is 0xED3A3 + 43 * 11 = 0xED57C, as I wrote above.

#3: IDs of sound effect samples.
These are the numbers you find in the first byte of the 11-byte units which describe the instruments, at offsets 0xED3A3-0xED591.

In case of the Amazon's voice this ID is 0x13.

I figured some of this information when I was testing samples by blanking the 11-byte units describing the instruments, and I made a list to identify these, though I couldn't write down a few of these, as I couldn't find what triggered it in-game; perhaps some went unused. In hindsight, I could have waited for this reply, but still, it fills me in on the offsets and dissassembly parts.

Spoiler: show

This really helps as I tried to document them all, but I did it by replacing a sample on a music cue, and I couldn't identify them all.

Spoiler: show

When you write "replacing a sample", exactly what were you replacing? My guess would be #3 above.

However, please note that music cues use a different set of samples than the sound effects, so you can't hear sound effect samples by changing which sample is referenced by a music cue.
Furthermore, sound samples (#3 above) are different from sound effects (#1 above).

Yes, it was number #3, and though it is true that music cues use different samples , you can find the sound effect samples on the range 40-54. That's how I initially did the screaming tests.

This leads me to something I have been theorizing:
I imagine new data for either custom music and samples can be written in free space on the ROM and then commands can be changed like the ones for the sound effects above to redirect to these new locations.

I was a bit unconvinced with the scream despite my efforts; I even tried to imitate a GoldenEye N64 scream sample but couldn't figure out a slower pitch bend up nor even find a pitch bend down only/first command. It just swoops too fast to the next note even on the lowest setting.
Norbert said though, that it was better to have it like that than nothing at alI, plus there's very few places where the scream can be heard in full.
Nevertheless, I went my way to investigate how to import samples. I did find how and I realized how much space they can take and understood why several of these are so short.
But I feel there's enough free space for one long sample, though perhaps not the GoldenEye one, as that one sounds too overlydramatic.

[Shauing]

A quick question David; where it would be safe to insert new gfx data? In other words, if I were to further edit the levels, where is the new level data placed in order to avoid writing the new gfx data there?

[David]

A quick question David; where it would be safe to insert new gfx data? In other words, if I were to further edit the levels, where is the new level data placed in order to avoid writing the new gfx data there?

So, is that graphics editor tool ready enough to use?

Pr1SnesLevEd uses two areas in the ROM:
0x20000..0x77FFF: The main data area. The original game uses only this.
0xE0A00..0xE7FFF: Second area, after the sprites.

In the ROM you sent me in December, 0xE0A00 contains the last resource, even though it would fit into the main area.
I think my editor doesn't trim the zeroes from the last resource when deciding whether it fits into the main area...

By the way, what kind of new gfx data will you insert?

[Shauing]

So, is that graphics editor tool ready enough to use?

Kind of. The tool has not been worked on since last June due to Slidelljohn (the guy who created the tool) having some real-life occupations, but as it stands now it edits pixels of character sprites only (0000-1248), displaying the Prince palette only (it cannot display the other character palettes but the editor uses the correspondent palette for each sprite).
After editing, by clicking on 'save as', it saves the data to a .bin file, one sprite at a time. From there, via hex-editing, this data has to be copied to empty space in the ROM (as the resulting data is at times larger than the original) and the pointer has to be changed to this new data's location.
The tool in its final intended state was to do all this later process automatically and only to character sprites but he was going to give the source code once it was finished as well, but as I said, he got busy and though he estimated that by the new year he might be back, has not returned yet. But it works. I could share with you the tool plus some documentation and other files and explanations he wrote and sent me, if you want to take a look at it.

Pr1SnesLevEd uses two areas in the ROM:
0x20000..0x77FFF: The main data area. The original game uses only this.
0xE0A00..0xE7FFF: Second area, after the sprites.

In the ROM you sent me in December, 0xE0A00 contains the last resource, even though it would fit into the main area.
I think my editor doesn't trim the zeroes from the last resource when deciding whether it fits into the main area...

By the way, what kind of new gfx data will you insert?

It seems that I'll have to use the 1C5C0-1FFF0 and FDF40-100000 areas then, as those are the ones with bigger free space and left untouched by Pr1SnesLevEd. When I originally tested the tool for a still-unfinished 2.2/3.0 'The Queen Of Light', I put some data on the 77000 area that had nothing written at that point, but after doing some level modifications it corrupted some of the gfx, as it seems it wrote new level data on that same area.

[Shauing]

Another big question regarding adding new data to free space. As the 'scream' sound using the amazon sample hasn't fully convinced me, I searched for a more convincing 'falling' sample, and after finding one and making adjustments such as speeding and pitch tuning it up to make it a smaller size, I converted it to BRR format and wanted to insert it on the sound effects samples table (E8000-ECDE5). But, the sample is still a little too big and I cannot replace it over an unused one(s).
So it occurred to me to place the sample data on some empty space (let's say on the FDF50 area onwards). But now, how can I call this new sample up?
I cannot find how the three sound effects IDs mentioned above can play this new sample if the data for it is outside the E8000-ECDE5 sound effects samples table.
Also, not sure how PoP loops samples, and looking into the SNES format document doesn't really give me an idea.

[David]

So it occurred to me to place the sample data on some empty space (let's say on the FDF50 area onwards). But now, how can I call this new sample up?

Unfortunately the game expects all the samples to be in one block, one after the other.
The header of the sample area contains only lengths but not offsets. (The offsets in the third resource table point only to the beginning of the sample area, not to each sample.)

It seems the only way to add a longer sample is to move the everything after the samples to higher addresses, and adjust the pointers accordingly.
Or perhaps, to move the whole samples block into an empty area, but I don't see any empty area which is big enough for that.

Also, not sure how PoP loops samples, and looking into the SNES format document doesn't really give me an idea.

As the SNES format doc says, each sample is split into two parts, and the length of the parts are given separately.
The first part will be played once, and then the second part will be looped.

And, according to the SPC docs, the last BRR block also has a loop flagbit.
It must be set to 1 for the sample to be looped.

[Shauing]

Unfortunately the game expects all the samples to be in one block, one after the other.
The header of the sample area contains only lengths but not offsets. (The offsets in the third resource table point only to the beginning of the sample area, not to each sample.)

It seems the only way to add a longer sample is to move the everything after the samples to higher addresses, and adjust the pointers accordingly.
Or perhaps, to move the whole samples block into an empty area, but I don't see any empty area which is big enough for that.

As the SNES format doc says, each sample is split into two parts, and the length of the parts are given separately.
The first part will be played once, and then the second part will be looped.

And, according to the SPC docs, the last BRR block also has a loop flagbit.
It must be set to 1 for the sample to be looped.

Dang. Well, if moving everything after samples is going to be a hassle, I might shorten the sample even further and try to fit it on one of the unused ones. At least I think it will sound better than the attempted amazon one.

I imagine that for the music, the game also expects it to be all on one block as well. Right?

[David]

I imagine that for the music, the game also expects it to be all on one block as well. Right?

No, music is different: Each music has a separate pointer, and each could be moved separately anywhere if you adjust its pointer accordingly.
Sound samples for music have the same rules as sound samples for sound effects, though.

[Shauing]

No, music is different: Each music has a separate pointer, and each could be moved separately anywhere if you adjust its pointer accordingly.
Sound samples for music have the same rules as sound samples for sound effects, though.

Which one is the pointer? The one that tells the length data?

[David]

Which one is the pointer? The one that tells the length data?

No, the pointers are found in the third resource table which begins at 0xE8000 and ends at 0xE806E.

[Shauing]

No, the pointers are found in the third resource table which begins at 0xE8000 and ends at 0xE806E.

Oh? I thought that portion was part of the sound samples. I actually thought the music pointers were located after the three kinds of IDs of sound effects.

[Shauing]

Then, what are the E806F-E80CC and ED592-ED5DF areas for and how do they work?

[David]

Then, what are the E806F-E80CC and ED592-ED5DF areas for and how do they work?

At 0xE806F-0xE80C3 and 0xED592-0xED5D6 are the headers of the sound sample sets.
The first is about the samples used for the sound effects, the second is about the samples used for music.
Their format is documented here: https://www.princed.org/wiki/SNES_format#Sound_samples

For example, the header starting at 0xE806F contains these bytes:
15 -- This set contains 0x15 = 21 samples.
C6 00 9A 02 -- The first sample is 0x00C6 + 0x029A bytes long, of which the last 0x029A bytes are looped.
1B 00 13 02 -- The second sample is 0x001B + 0x0213 bytes long, of which the last 0x0213 bytes are looped.
And so on until you reach the lengths of the 21st sample (at 0xE80C0):
93 06 09 00 -- This sample is 0x0693 + 0x0009 bytes long, of which the last 0x0009 bytes are looped.
(By the way, all lengths are divisible by 9, because BRR samples are structured into blocks of 9 bytes.)

Then, at 0xE80C4 the first sample starts.
The second sample starts at 0xE80C4 + the length of the first sample (0x00C6 + 0x029A) = 0xE8424.
And so on.

(By the way, it seems that most samples start with 02 followed by 8×00, and they end with 9×FF.)

The mostly-zero areas at 0xE80C4-0xE80CC and 0xED5D7-0xED5DF are the beginning of the first sample in each set, and not part of the headers.

[Shauing]

Had been on a slowdown lately due to other commitments, but I hope to release this no later than April 3rd (by that point it would be a 7-month on-and-off work).
I have a couple of questions not for this mod exactly.
Is it possible to play the demo after the last training level?
For what I experimented, if in the Hacks tab Training 5 is not the last training level, the game softlocks after beating it.