Jambo51

I just tested out a few values for frame delay in Red. As it turns out, the lowest I could set frame delay was 3. Setting it to 0, 1, or 2 actually resulted in a ridiculous amount of frame delay, much higher than 15 ($F). So it seems as if 3 is the practical minimum for that.

I'll be testing a few more things in the near future, if you don't mind!

EDIT: I messed around with the pitch bending in the Pokémon Red title track. Here's what I found.

The "pitch bend" command has the pattern EB xx yz in R/G/B/Y. "y" is the ending octave of the pitch bend. "xx" and "z" seem to work together to determine both the base amount of pitch bending and the speed of pitch bending. I didn't spend enough time with it to determine the correlation.

Oh, you mean in making music for the GB(C), got it. Your rationalization and explanation makes everything make more sense now.

Now that I think about it, 192 would need to be the maximum note length for this music, if in fact the GB(C) uses the entire range of hex values for frame delay. Funny to think that this 8-bit device can handle more precise parameters than the GBA, whose max note length is 96!

Actually, that's not funny. That's sad. And a bit suspicious, how sure are we that frame delay can get to as low as 1?

Gen 1/2 ASM? Neat, what would you end up using it for? New tools? GB(C)-to-GBA conversion? Contributions to online disassemblies?

Putting octave right after the note played is a great choice, for obvious reasons. As for the rest, I guess you put it in a suitable order. By XSE format, I'm guessing that what you're saying is that notes would look like this:

note 0xC 0x4* 0xC 0x7 0x1

*0x3, if using GB(C) terminology

Well, if used in a program handled similarly to XSE, I guess that'd work. However, it seems a bit confusing for outsiders to jump into, even if understanding requires just memorization of what each value means. Certainly some sort of notifier or comment to help would make things a bit easier for reading, but that would come at the expense of size. We don't want a single note to take up a large amount of the screen, do we?

As for the note length/frame delay compromise, you'd need to make sure that "length" needs to be consistent regardless of frame delay. Otherwise, by keeping it relative to frame delay, people will just be confused as to what that length really means. Or maybe I'm not getting something right...would length vary from 1-96?

And thanks! I have a feeling that my profile pic is going to get increasingly "smug" over time, despite my nature being "Modest." :P

At least this guy doesn't really "get it," anyways...

A later date, as in...now? I've been poking into how noise instruments work in the GB(C) games. It seems like the format is entirely different between the 1st Gen and 2nd Gen games. The 2nd Gen games use a simpler format that appears a bit similar to how the other three waves work. Each different "drum strike" has a value set to it, followed by its duration. In other words, each note looks like

xy,

where "x" is the type of "drum strike," and "y" is the duration. I can't tell what values of "x" correspond to, or if they are directly compatible with corresponding notes used by the other waves. As there aren't any octave definitions, I'm not sure.

What dose confuse me, though, is what the first two bytes of each noise track mean. For the songs I checked out, each one started with the bytes E3 03. I don't know what they mean. Perhaps they just indicate that the following data is for a noise track?

The 1st Gen games, on the other hand, have a more complicated format. Every single note actually has a two byte pattern, rather than a single byte. It looks like

Bx yz.

"B" is a constant, followed by variable "x." This byte defines note length, with "x" corresponding to the same lengths as the three wave instruments. "y" can be either 0 or 1, but I'm not sure what it means or what determines it. "z" represents the type of "drum strike."

I have no idea what determines sample rate. Sorry if I bombarded you with notes you didn't want to see right now!

Well, from turning the location of the Wild Pokémon Battle song into a pointer, I found that its header is at 202D1. 202BE appears to be where the first header of this group begins. The reason you probably couldn't find it was because the first song in the region 22330-23F51 appears to be unused. Recreating it in Anvil Studio gave me an awful-sounding jingle.

The full range of these headers would be 202BE-202FC.

I can't say for sure, considering that all the tracks in the game don't use all the available values of it. But I guess that D1 - DF is a good assumption.

Oh yeah. Frame Delay works a bit differently in RGBY. It's actually determined by a single byte in the form of D?.

In other words, the number that fills in the "?" is the frame delay. Normally, this will be DC. In a song with different timing, such as Silph Co., this will turn into D6. Note volume and note decay follow right afterwards. In that instance, it would look like

D6 B3, which would mean

Delay 0x6 followed by Volume 0xB Decay 0x3.

I have no idea on what this "frame delay" is, unless it also occurs in Gen 1 and I'm missing something. As for E8, it always appears when there's nothing going on before the notes of a track begin. I don't know how long the game determines this state of "E8" lasts before track playback begins because, like you said, "It's just there."

And I'm kind of figuring that "y" isn't octave in pitch bending. The other two variables have to determine bend speed, bend duration, or bend depth. Perhaps there's some factor of pitch bending for the GB(C) that remains constant.

Yep. In RGBY the C note is hex value 0, whereas in GSC it is hex value 1. Good thing you got that sorted out. It's amazing the progress you've made with this tool!

I'm still trying to figure out how pitch bending works, but I just get more confused the more I look at it. One of the variables has to define how much the pitch bends, along with bend speed and direction. But what is it?

The format is probably one of the following, given that E0 is to be replaced by EB in RGBY:

E0 xx yy
E0 xx yz
E0 ll hh

ll and hh would refer to a particular location in the ROM.

I think that xx is bend delay. The fact that all instances I've seen have had this at 00 means that the pitch bending should begin immediately. The little information I have makes it seem as if the singular y indicates the octave the note bends to.

I figured as such. Do you have the location of those headers? I pointed those earlier in my thread.

Unfortunately, I don't think that many other games, if there are any others, use a either format for sound. Seeing as how the original Pokémon games were haphazardly put together, I can see how things aren't exactly organized neatly. I imagine this is actually the case for many GB games. Developers probably didn't care as much about creating a pristine set of code for a "dinky" system with extreme limitations, so they likely just stuffed whatever they had onto cartridges in a way that was functional.

Perhaps it would be best to just create a tool that has the potential to extract music from any GB(C) game out there. It would just require a lot of defining by others for each and every different ROM out there. Maybe you could make this some sort of pseudo-open-source tool that will allow anyone who wants to contribute new music table/storing structures for different games to do so, and update the tool as necessary to support them.

And what do you mean by a "VG"?

For that particular song, I set BENDR to 6. Doing so gave me the ability to bend a single note, from bend c_v-64 to bend c_v+63, an entire octave. Setting the value higher gave me more pitching potential. I'm not 100% certain of what the scaling for it is.

I changed the amount of the pitch bend by + or - 8 each ninety-sixths of a note (W01). It's a pain, but the result was perfect in my ears.

And I'll check out the noise instrument tracks again and tell you what I've found out. I imagine they're more of a pain in GSC because songs are more reliant on them and their variety.

EDIT: I think the BENDR value specifies how many notes on the octave you can bend a note in one direction. In other words, a BENDR of 6 would let you bend a note up to six notes higher or six notes lower. The value increases as BENDR does. I'm pretty sure the default value for BENDR is 2.

As for the bend values in the GB(C) games, I haven't seen xx be anything that isn't 00. For yy, it seems as if the second part of the byte specifies the speed of the pitch bend.

Wow, now the whole 1st page of visitor messages for you consist of ME!

Ok then, that mod exception makes sense to me.

Good luck with the distortion effect. If it helps you can also look into the main theme from Gen 1. I used pitch bends for it in my hack, and I think it sounds about perfect. It has patterns EB 00 42 and EB 00 32 for the two different pitch decreases. The only way I could bend the pitch that much was by using bend in conjunction with the BENDR command. I'll give you more info when I have the time.

I'll also look into the noise instruments a little if you still need information on that!

Oh. I always though that was if "z" was equal to 1. Sheesh, there are just so many exceptions and scalings that have to be made for the GBA! Not that I'm complaining...

I was gonna mention the Evolution jingle in there along with those. Looking back at the code, though, it seems as if there are actually TWO completely different things going on for the Evolution jingle and Jigglypuff's Song. In RGBY, the Evolution jingle's distortion command is EB. It follows pattern EB XX YY (NL). For that jingle, XX is 00 and YY is 49.

In Jigglypuff's Song, though, command FC is being used. It seems to use only one parameter to define its distortion, looking like FC XX. Note velocity is defined after that.

This might be a stupid question, but have you gotten the Evolution jingle sounding right?

It seems like the only way to get the volumes all right is through trial and error, unless logic can be used to reach the solution.

I figured it'd be too simple for modulation depth to be the same between the two. Rather than criticize the limitations of the GBA's music handlings, it'll be best just to deal with it and get these tracks sounding 100% accurate at all costs. All this will leave left is the noise instruments...and the weird distortion used in a few of the RGBY tracks.

Ugh...working with the Hypno's Lullaby theme is annoying.

Are you sure the Rocket Hideout music uses the same modulation throughout the song? What if it uses some sort of distortion that isn't really related to it? I remember that Jigglypuff's Song in the 1st gen did, and I was never able to figure out what was going on with it. If it is just modulation, though, then figuring out the exact scaling used with GBA playback will be the key to getting perfect modulation.

Wait, when you say volume, what do you mean? "Vol" volume, or "v???" volume? And are you talking specifically about the songs you're exporting that are quiet? Or are the songs in my hack exhibit just as quiet of triangle waves, too?

And I...guess that makes sense. Except for the fact that the pointer itself isn't in the game's code, which just makes things confusing. I'd be clueless on trying to find a music table myself. I hope there is one, but I guess things aren't looking too good right now.

Poor translation? Wouldn't the modulation be my fault, then? The values I chose for mod delay and mod speed were to compensate for the GBA's different handling of them. As for the triangle waves, what values are you using to define their finer traits? If this is all the GBA's fault, then that's just bad. I'd think that a successor to a previous system would be able to do every basic thing the past one could just fine.

And let me correct myself on the amount of triangle waves present in the 1st Gen games. There are a total of six for the actual songs, but I don't know how many extra ones are used for sounds of attacks and the Pokémon themselves. It's not like it'd matter, though, as those sounds are played through DirectSound in the GBA games.

As I said before, I don't know what a music table would look like. Is it a "phenomenon" that was only introduced in more recent years? If it exists in the 1st Gen games, then great! If not, then defining songs through the .ini would be awfully wasteful. It would only work, presumably, for the international Red release (and possibly Blue). The Japanese versions and Yellow would need their own definitions entirely.

Huh. Limits don't really matter, we'll have more than enough room for whatever we, or anyone else, needs to do with GBA music hacking. I don't see why anyone would need more than 256 voices for anything.

As I said earlier, it seems as if the base scaling factor is the same as it was with the GB(C) games. The second value of a velocity change will specify what it should be. Just as 0-7 represent reciprocal note decays, 9-15 (9-F) represent varying fade-ins. The velocities of the tracks, though, will almost certainly need to be scaled differently.

By the way, RGBY have exactly 6 different triangle waves, meaning there's a maximum total of 16 between the two. I'm not sure if any repeat between the two generations, but I'm pretty sure they don't.

And I actually feel really hesitant when it comes to future music hacking. With the massive progress you're making with your tool, I think we'll soon reach a point where converting GB(C) songs for use in Sappy will be a simple process of finding the track in the GB(C) ROM and exporting it into the proper format with your tool. Hand-done songs will be no more, and efforts done by me, or anyone else, would be a waste of time. That is, considering someone will be able to find the music banks for the other games. Do you think you could find the one for Red given the info I gave you awhile back?

Finally, yes, hooray for you. Although why you feel special only now is kind of odd enough. Leave it to someone like you to figure out some monumental breakthrough in GBA hacking! :)

Seriously, Sappy is now in need of a serious re-write after this discovery.

Okay, new post because I don't want these two to get mixed up.

I just tested this out, and wow! Those values DO cause the proper rises in volume. I'm shocked that I never thought of trying this myself. After all, the same values for decay used in the GBA correspond to the same value for "velocity" signifiers in the GB(C) tracks!

A problem, though. I don't know what to specify for the velocity in the GBA songs themselves. Putting notes that use voices with these decay values at the same velocity as everything else makes them too loud. However, putting them too low causes the notes to cut out early. I'm not sure what the correct values should be, but, then again, I only checked this out for about 15 minutes.

Sappy needs a new update, stat! :P

Eh, I'm almost certain that my estimated values aren't 100% right. I just haven't ran into any considerable sound issues with them. Maybe I'll get into hardware structure and whatnot sometime in the future and see if I can figure something out on my own! Probably not, though...

Interesting information about the square waves and decay! If 9-15 do provide the necessary "rise" voices, then we should be all set! Too bad Sappy doesn't account for this; having "Dec" be higher than 7 still makes it think that the decay is still just getting slower, rather than changing function altogether.

If we assume that the difference between 25% and 75% is almost unnoticeable (thereby not having separate instruments for each), then that would mean that we'd need 15*(3*2) voices strictly for the two square waves. I'm pretty sure there's no more than 15 different triangle waves between the first two generations of Pokémon games, and even less for noises. So we'd still be able to do well with 128 voices regardless!

Of course, if we were making a voice table capable of containing all the triangle waves for every noteworthy GB(C) game ever released...we'd probably need a bigger boat. :laugh: Like you said, hooray for having more than 128 voices. Did you confirm that there could be unlimited voices, or is there still a limit (like 256)?

By the way, I'll be checking out these decay values sometime today. I probably won't implement any changes to the 8-bit tunes in my hack just for them, though, as they'd only lead to minimal sound differences.

Sorry for the late response, I haven't been around recently. Just listened to the exported GSC Kanto Trainer Battle music. It sounds great! Well, discounting the fact that I don't like how that song was structured in GSC to begin with...

I haven't touched music hacking at all since I last checked out the Pre-Alpha(ish) version of your tool. What I can say is that I still stick to my inclinations on the two music formats (the GB(C) and GBA ones, that is). This includes modulation. These numbers have provided for me what I feel are 100% accurate modulations. All the information is in my music hacking document in my hack, but I'll just copypaste the relevant stuff here and change as necessary:

As far as I can tell, there's no perceivable difference in how modulation is handled between the 1st Gen and 2nd Gen games. The "E1" is for GSC, while "EA" is for RGBY.

I don't have ANY documentation concerning Noise instruments at all. I didn't spend much time with them because the related code for it was too confusing for me at the time, as if the values didn't relate to anything I could think of. I could take another look at it, if you'd like!