[23:03] I was just going to describe the format from the ground up [23:03] all right [23:03] N-SPC is a tracker type of music driver [23:04] Used in lots of first party Nintendo Super Nintendo games [23:04] If you learn how to use it [23:04] you can potentially import music and instruments from other games that use the N-SPC driver [23:04] e.g. you could take music from Super Mario All Stars and implant it into Kirby Super Star [23:04] [DSO] Is there a quick way to find where that data is stored? [23:04] DSO: yes [23:05] That requires a general understanding of how the SPC <---> SNES communication works [23:05] If i'm looking at a new game [23:05] I want to know where the SPC driver is at [23:05] Now, the catch is that the N-SPC drivers for each game are not *identical* [23:05] but they're pretty close [23:06] Hold on [23:07] Since most people here are metroid hackers [23:07] I'm going to use Brinstar1.spc as an example [23:07] It's the green brinstar theme [23:07] (pink too) [23:07] SPC drivers almost always look like this: [23:08] two hex bytes [23:08] 20 CD [23:08] that's the start of the one in Super Metroid [23:08] Since that's the start of the driver [23:08] we can easily search for that in the rom itself [23:09] But you will likely find more than one instance of "20 CD" [23:09] in the rom [23:09] So what you do is take a few more bytes [23:09] in this case [23:09] 20 CD CF BD E8 00 5D AF [23:09] Should be sufficient for super metroid... [23:09] *checks* [23:10] Yeah [23:10] in a hex editor, that sequence of bytes only shows up once [23:10] Let me back up a second and say taht the "driver" is a term that refers to code that runs on the SPC-700 [23:10] The SPC-700 is a CPU separate from the SNES's main CPU [23:11] So if we find this data, we have only found the code that the SPC-700 runs [23:11] However, in most N-SPC games, the SPC related data is all lumped together [23:11] you find the driver, you find the rest of the music data [23:11] This is true of Link to the Past and Super Metroid, at the very least [23:11] I imagine it's the same for Super Mario Kart, etc [23:13] Generally speaking the 20 CD will be aligned on a page boundary, like 0x100, 0x200, 0x300, ... etc [23:13] In Super Metroid's case, it ends up being at 0x1600 in the SPC's memory (The SPC has 64K of its own RAM) [23:13] I'm trying not to go over everyone's heads [23:13] If you have a question don't be afraid to interrupt but keep in mind I won't spend forever on it [23:14] Small correction: SPC files have a 0x100 byte header at the beginning so it's technically 0x1500 for Super Metroid, as far as the SPC RAM goes [23:14] moving on [23:14] Using Geiger's SNES9x debugger, one can then use read breakpoints to isolate all the music data [23:15] I would hope by now someone would have written out what all the offsets were for Super Metroid [23:15] I take it that's not the case? [23:15] If not we can go through it manually [23:17] The nice thing about N-SPC data from nintendo [23:17] is that it's easy to break apart [23:17] at least on the ROM side [23:18] I might have to take this a little slow [23:18] But it's still fairly easy [23:18] so... starting [23:18] The location of the driver in the ROM is 0x278108 [23:18] agreed? [23:18] (no header) [23:19] This process should be fairly repeatable on other games [23:19] Since the driver is a logical unit [23:19] that is, a "chunk" [23:19] the start of it is just that, the start of a chunk [23:19] so in the ROM, we look to the left of that 20 CD [23:19] and what do we spy but a sequence like this [23:19] E2 41 00 15 [23:20] This is two 16-bit numbers [23:20] that tells us important information [23:20] 1. The length of the chunk is 0x41E2 bytes [23:20] 2. The location in the SPC's RAM that it will be transmitted to is 0x1500 [23:21] For the mathematically inept, 64K of RAM ranges from 0x0000 to 0xFFFF, and that's it [23:21] anyways, this chunk will be written to 0x1500 and will stop at 0x56E1 [23:22] The length of the "driver" "chunk" varies from game to game, as does its contents [23:22] But the music data is all basically the same format [23:22] the drivers usually differ in how they do sound effects, not music [23:22] Super Metroid has an unusually long driver chunk for an N-SPC game [23:22] To me, that tells me that it has a very complex sound effects system [23:23] Which makes sense, given its late release date and how cool most of the game sounds [23:23] Sound effect wise [23:23] Kejardon would probably have more info on that [23:23] Anyways [23:23] [DSO] He mentions some stuff on that in http://jathys.zophar.net/supermetroid/kejardon/SPCRamMap.txt I think [23:23] Well if you can locate it in that document [23:23] please share [23:24] i don't have time at the moment to go through it [23:24] In your hex editor... [23:24] we want to skip 0x41e2 bytes forward [23:24] there we will find the next chunk [23:25] These chunks are usually consecutively laid out in the ROM [23:25] That will bring us to ROM address 0x27C2EA [23:26] You should see the following bytes at that location [23:26] 93 0C 20 58 0E 53 .... [23:26] speak up if yours is not the same [23:26] I don't want to get off on an incorrect tangent [23:26] so far so good [23:26] What this would tell us [23:27] [DSO] 93 0c 20 58 means it's $0C93 bytes long and going in $5820? [23:27] ^ what he said [23:27] length is 0c93, goes to --yeah [23:27] show off [23:27] The real issue, is that we don't know what this data is [23:27] But we should make a note that it exists [23:27] it's clearly relevant [23:27] So we continue moving on [23:28] someone should compile a data sheet from this [23:28] so other hackers can use it [23:28] So from the 0E byte [23:28] we jump 0x0C93 bytes forward [23:28] And arrive at location 0x27CF81 [23:29] This next chunk is 0x00A0 bytes long, and gets stored to 0x6D00 [23:29] [DSO] um [23:29] yes? [23:29] [DSO] Isn't 27C2EA + C93 27CF7D? [23:30] you're right it is [23:30] but we need to jump from the start of the previous chunk [23:30] which would be 4 bytes after 27C2EA [23:30] the length and SPC addresses don't count as part of the chunk [23:30] b/c they're not going to be written into the SPC RAM [23:31] Ｍake sense [23:31] yeah [23:32] What it's saying is 0x0C93 bytes get written to location 0x5820, and after that are our 0x0C93 bytes to write [23:32] so we need to jump from the start of the actual chunk [23:32] not the .... "header" data [23:32] Anyways [23:32] right [23:32] We're going to jump again [23:32] this time from 0x27CF85 in the rom [23:33] (note again I incremented by 4 bytes from 0x27CF81), which is what confused DSO [23:33] so we jump ahead 0xA0 bytes [23:33] arrive at 0x27D025 [23:34] At this point, this is probably getting boring [23:34] but it will pay off [23:34] will anyone volunteer to compile the results later? [23:34] I'm going to skip to my documentation of the Super Metroid driver [23:34] the specifics of the driver tell you what each chunk does [23:35] [DSO] Question [23:35] k [23:35] [DSO] Some enemy sound effects change when you change the song in Super Metroid, does this mean that these songs are in a different chunk? [23:36] Well... when you say the sound effects change [23:36] I'm not really sure what you mean [23:36] you mean the types of sound effects? [23:36] Or the samples used to play them? [23:36] DSO, I don't think we're there yet [23:36] In any case [23:37] Songs and sound effect data don't have to be in the same chunk [23:37] when the game changes songs, it loads different instrument samples, sometimes enemies use those samples [23:37] [DSO] Samples probably [23:37] But if it loads a new song [23:37] chances are it's loading new ADPCM samples [23:37] which will in turn affect the sound effects [23:37] taht's something you guys will have to figure out [23:37] but yeah, we're not there yet [23:37] This is mostly a tutorial on how to locate music data and change it [23:38] Not sound effects [23:38] I know how to do that for LTTP [23:38] but I'd be lost in Super Metroid (sfx) [23:38] Anyways [23:38] Where were we [23:39] I'm at 0x27D025 [23:39] This gives us a header with the following data: [23:39] 0x91E0 bytes long, written to address 0x6E00 in the SPC [23:39] So like good little boys we skip ahead over this again [23:40] To 0x286209 [23:40] Now here's where the buck stops [23:40] We've hit a block with length 0x0000 [23:40] This is how the SNES CPU knows to stop transmitting data to the SPC [23:40] so we've covered quite a lot of terrain in the ROM [23:41] nearly two 32K banks of data [23:41] So I'll bust out my Super Metroid documentation [23:41] to see if it has info on these chunks [23:42] Okay, I don't [23:42] but I have a decent memory [23:42] so I'll just say what they are if I remember [23:42] [DSO] Kej has a bit of stuff on it it looks like [23:42] [DSO] 1500 - 56E1 is the main SPC engine. Copied from ROM at CF:8108 (278108). Some sections may be changed [23:42] [DSO] 1B62 - 1B9F is a jump table of sorts; Song data is interpreted with this. Not changed. [23:42] [DSO] 1E1D - 1E31 is panning volume multipliers. Not changed AFAIK. [23:42] [DSO] 1E32 - 1E51 is FIR coefficients. 4 groups of 8 bytes. Seems like it'd be changable, but not changed AFAIK [23:42] [DSO] 1E66 - 1E7F is the pitch table. (085F 08DE 0965 09F4 0A8C 0B2C 0BD6 0C8B 0D4A 0E14 0EEA 0FCD 10BE) [23:42] [DSO] 5800 - 5807 Note Sound Length percents [23:42] [DSO] 5808 - 5817 Note Volume percents? [23:42] [DSO] 581E - 5??? Song start addresses for 40. Maximum possible is 80, but usually only 6-8 are used. [23:42] [DSO] 5??? - ???? Song note data is stuck here, right after the end of the song start addresses. [23:42] [DSO] 6C00 - 6CE9 (Not certain about end address) 6 byte entries for 18F9. Voice Source #, ADSR1, ADSR2, Gain, and then two bytes stuck in 0220+x (x = 2*channel). Seems to have 1 entry per source #. [23:42] [DSO] 6CEA - 6CFF Unused? [23:42] [DSO] 6D00 - 6DFF is the sample table. Seems to stop at 6D96 (though 6C00 suggests 6D9C). *Must* stop by 6DA8 - that's all the table at 6C00 can support. [23:42] [DSO] ???? - F??? Instrument sample data. Pointed to by 6D00 sample table. [23:43] Okay, hold on a sec [23:44] The last chunk was really large [23:44] 0x91E0 bytes, to be exact [23:44] usually a chunk that big will be your sample (ADPCM) data [23:44] that's what most of you would refer to as "instruments" [23:44] It's sound data that has been prerecorded before being inserted into the game [23:45] and it's manipulated to product sound effects, music, etc [23:45] *produce [23:45] This meshes with Kej's data [23:45] because he says that the sample table is at 6D00-6DFF [23:45] The sample usually is right before the sample data, but not necessarily [23:46] *the sample table [23:46] *the sample table usually is right... [23:47] Now, Kejardon is not the word of God, so some of his notes don't really mesh with what I know, but I'll take his word for most of them [23:47] let's go to the previous chunk [23:48] That was 0x00A0 bytes, written to 0x6D00 [23:48] well... there's your chunk that describes the sample table [23:48] 6D00 - 6DFF is the sample table. Seems to stop at 6D96 (though 6C00 suggests 6D9C). *Must* stop by 6DA8 - that's all the table at 6C00 can support. [23:49] I don't really want to get into an indepth discussion of the sample table [23:49] but let's look at some of the data in it just to make sense of it [23:49] The sample table is a table of "pointers" to the ADPCM samples in the SPC RAM [23:49] Each entry is 4 bytes [23:49] the first two bytes specify the starting point of the sample [23:49] the second two bytes specify the loop point of the sample [23:50] Let's look at the first two entries in the sample table [23:50] at 0x27CF85 you'll see 00 6E C4 73 C4 73 88 79 [23:51] So the first four bytes correspond to "instrument" 1 [23:51] erm. "instrument" 0 [23:51] The sample starts at 0x6E00 and loops at 0x73C4 [23:51] My intuition tells me that this sample doesn't loop at all as its end point is the same as the start of the next sample [23:52] "instrument" 1 starts at 0x73C4 and loops at 0x7988 [23:52] I don't really follow the logic there, but if you say that's what it means, then okay [23:52] (about loop point = next sample, so must not loop) [23:52] Looped samples are something I don't want to get into at the moment [23:52] np [23:52] b/c well be dealing with the DSP at that point [23:53] a basic description would go as follows [23:53] [DSO] Does it mean instrument 0 and 1 play together? [23:53] The sample is a waveform [23:53] which can be very short or very long [23:53] DSO: no [23:53] let's say that instrument 0 is a piano [23:53] or rather, a recording of a piano key, either real, or synthed [23:53] when you hit a piano key [23:53] It makes a percussive noise when your finger first strikes it [23:54] but the sound it makes when you hold it down, is different from the sound it makes when you hit it, yes? [23:54] [ [hit] [held sound] ] [23:55] ^ let's say that the hit portion lasts 0.1 seconds [23:55] and the held sound part lasts 0.5 seconds [23:55] when you input your instrument data, you'd want to make this sample table up in a way that tells it what byte the held sound starts at [23:56] otherwise if you loop the sample, it will sound like someone hittting a piano key over and over and over again [23:56] rather tahn the sound of someone holding a piano key [23:56] does that not make sense to anyone? [23:58] that makes sense actually [23:59] some samples in the game don't actually ever get used long enough to play "held" notes and the programmers didn't give them that data [23:59] right [23:59] some samples are one offs [23:59] they aren't meant to loop [23:59] so if you tinker with the sound engine and try to make it use one, it sounds like the "hitting over and over again" [23:59] so the loop position is just set to the end of the sample [23:59] yeah, and now I know why, neato [23:59] basically, yeah [23:59] does this mean that any note would repeat if you let it play long enough? [23:59] if you set the base address to the same address as the loop address [00:00] you really will be doing the whole sample over and over again [00:00] e.g. 0x6E00 then 0x6E00 in this case [00:00] ah, ok [00:00] acheron: that's more getting into ADSR settings [00:00] i don't want to get into that right now [00:00] but if it loops, it's told at some point to jump into the sample at an appropriate point [00:00] sorry, carry on [00:00] you can make a sample play forever with aDSR [00:00] *ADSR [00:00] but it won't do that by default [00:01] read anomie's DSP guide if you want to know how that stuff works [00:01] it's very thorough [00:01] but at times hard to understand [00:01] anyways [00:01] so we know what that chunk did [00:01] moving backwards again [00:02] 0x27C2EE [00:02] which is the chunk that will be written to 0x5820 [00:03] according to Kej [00:03] this is the song note data [00:03] what he means, is that this is the tracker data [00:03] this is the song data! [00:03] It consists of commands to play musical notes, to change volume, and a shitload of other things [00:03] this is the stuff we're interested in [00:04] Now, as far as we know, this is only one set of song data [00:04] there's probably others in the ROM nearby to the chunks we're aware of [00:04] But! [00:04] We now know where the song data is read from in the SPC RAM [00:04] So someone pick a super metroid song [00:04] [DSO] Maridia1 [00:04] Is one your hear after blowing up the tube? [00:05] [DSO] Yeah, the one you hear when you first get into Maridia [00:05] well [00:05] in my set it's Maridia2.spc [00:05] If you know where the tube you blow up is [00:05] just go two screens up from that [00:05] load the spc file that corresponds to that in your hex editor [00:06] (in mind Maridia1.spc is not the one you're thinking of) [00:06] *in my set [00:06] [DSO] I said 1 simply because it's the first one you hear [00:06] I'm just clarifying [00:06] so we're all in the same file [00:07] to be totally clear, it's not the music you'll head in the room right before draygon [00:07] I've opened up my file in my hex editor [00:07] for convenience sake i'm going to chop off the 0x100 byte header [00:07] and save it as a different file name [00:07] like Maridia_test.spc [00:07] [DSO] Where did you get the spc file? [00:07] Probably zophar.net [00:07] ages ago [00:08] so I do some checking [00:08] and I look for 20 CD [00:08] to make sure the driver's at 0x1500 [00:08] low and behold, it is! [00:08] did I miss something? how do we know where maridia2.spc is? [00:08] Acheron: you'd have to have the spc set [00:08] I assumed you had it [00:08] snesmusic.org/v2/ [00:08] if you don't [00:09] oh [00:09] I'll wait but please hurry [00:09] go on for now, I can catch up later [00:09] I'm logging this [00:09] Anyway, the point of chopping off the header was to make sure that the 0x0000 in the file was the same as 0x0000 in SPC RAM [00:09] that's what SPC files are, they're dumps of the SPC's RAM [00:10] along with the DSP (digital sound processor) variables [00:10] from that an SPC player can begin playing the music [00:10] * Acheron can't connect to snesmusic.org, site seems to be down [00:10] zophar.net works too [00:10] anyways [00:10] [DSO] So I could just dump the SPC with SNES9x? [00:10] If you go to 0x5820 in the SPC file [00:11] You should see the following [00:11] 0E 53 6E 54 69 55 97 56 ... [00:11] what we want to do is see if we can locate this data in the ROM [00:12] If not, we'll have to be slightly more clever [00:12] [DSO] 27C2EE? [00:13] headers for spc always = 0x0100? [00:13] hehe [00:13] that works [00:13] that happens to match the chunk we were looking at in the ROM earlier! [00:13] no surprise there [00:13] One thing to keep in mind is that N-SPC can store more than one song in RAM at a time [00:14] In Super Metroid, it usually only keeps 5 songs in RAM at a time (SPC RAM) [00:14] But a game like Zelda LTTP keeps like... 10-14 songs in RAM at a time [00:14] It's just a different way of utilizing the engine [00:14] LTTP emphasizes the ability to change the song on the fly [00:14] whereas Super Metroid probably uses higher quality, larger samples to produce better music [00:14] But since the sequence data and the sample data have to be in RAM at the same time [00:15] there's always a trade off [00:15] A game like Chrono Trigger only keeps *1* song in SPC memory at a time [00:15] and afaik, doesn't keep any sound effects in RAM [00:15] as in, it streams them [00:15] But CT is pretty advanced [00:15] pushes the system pretty hard to its limit [00:18] Anyways [00:18] It's kind of hard with most spc players to change the song [00:18] I was going to try to show youse guys how to do that [00:18] gimme a minute or two [00:19] The problem is that they don't simulate input from the SNES CPU to the SPC [00:19] or rather they do... [00:19] but I gotta remember where to do it [00:24] I guess I cant' change it, not with my plugin anyways [00:26] The point is that a SNES side variable will control which song is currently playing [00:26] I look at the Maridia spc file to find out the number of the song that was playing [00:26] that's 06 [00:27] where can you find that? [00:27] At locations 0x0000, 0x0004, and 0x0008 in RAM in the SPC file [00:29] bah [00:29] I'm suffering from a lack of good Super Metroid roms / savestates at the moment [00:29] collateral damage from Redesign I guess [00:29] anyways [00:29] Since it's song 6 [00:30] We look at the bytes at 0x5820 [00:30] and we skip over 6 times 2 bytes [00:30] b/c these are all pointers to the data for each song [00:30] (pointers are two bytes) [00:30] We should end up at 0x582C in the SPC file [00:31] the data there is 5A 58 [00:31] this means we need to go to 0x585A [00:31] to get to the rest of the song data [00:31] If you haven't noticed yet, the SPC-700 is also little endian, so you have to reverse the bytes to figure out the pointers [00:32] So we go to 0x585A [00:32] We see 7D 5F, which is yet another pointer to 0x5F7D [00:32] Note that this data is called "part" data [00:32] some songs have multiple parts [00:33] Which are organizational in nature [00:33] how do we know where the pointing ends? [00:33] They handle looping, mainly [00:33] we'll get there [00:33] hold on [00:33] okies [00:33] [DSO] I remember hearing something about this [00:33] go to 0x5F7D [00:35] hrm... I might be confusing myself a tad bit [00:35] hold on [00:38] anyways [00:38] If you follow this data [00:38] At 0x5F7D [00:38] you should find the following bytes [00:38] FA 27 E7 0C E5 B4 .... etc [00:38] is that what you all find? [00:39] yeah [00:40] okay [00:40] This to me, looks like what I call track data [00:41] It goes "song data", which is a pointer to "part data" which could have more than one pointer, and then each part points to "track data" [00:41] this might not have been the best example as I can only find one track [00:41] but I'll explain anyway [00:41] observe [00:41] Command_Jump_Table: [00:41] 0EEA: dw $0C66 ; command E0(1) (instrument) [00:41] 0EEC: dw $0CBF ; command E1(1) (pan) [00:41] 0EEE: dw $0CCD ; command E2(2) (pan slide) [00:41] 0EF0: dw $0CE6 ; command E3(3) (vibrato) [00:41] 0EF2: dw $0CF2 ; command E4(0) (vibrato off) [00:41] 0EF4: dw $0D0D ; command E5(1) (global volume) [00:41] 0EF6: dw $0D1C ; command E6(2) (global volume slide) [00:41] 0EF8: dw $0D2E ; command E7(1) (tempo) [00:41] 0EFA: dw $0D33 ; command E8(2) (temp slide) [00:41] 0EFC: dw $0D45 ; command E9(1) (global transpose) [00:41] 0EFE: dw $0D48 ; command EA(1) (tranpose) [00:42] 0F00: dw $0D4C ; command EB(3) (tremelo) [00:42] 0F02: dw $0D58 ; command EC(0) (tremelo off) [00:42] 0F04: dw $0D79 ; command ED(1) (channel volume) [00:42] 0F06: dw $0D82 ; command EE(2) (volume slide) [00:42] 0F08: dw $0D9F ; command EF(3) (call loop) [00:42] 0F0A: dw $0CFD ; command F0(1) (vibratostep (????????) [00:42] 0F0C: dw $0D5B ; command F1(1) (pitch slide to) [00:42] 0F0E: dw $0D5F ; command F2(1) (pitch slide from) [00:42] 0F10: dw $0D75 ; command F3(0) (pitch slide stop) [00:42] 0F12: dw $0D9B ; command F4(1) (fine tune) [00:42] 0F14: dw $0DC2 ; command F5(3) (echo control) [EON, EVOLL, EVOLR] [00:42] 0F16: dw $0DF9 ; command F6(0) (echo silence) [EDL = 0, EVOLL = 0, EVOLR = 0] [00:42] 0F18: dw $0E00 ; command F7(3) (Echo and Filters) [sets EDL, ESA, EFB, VxFIR] [00:42] 0F1A: dw $0DD8 ; command F8(3) (echo volume slide) [00:42] 0F1C: dw $0E9B ; command F9(3) (pitch slide) [00:42] 0F1E: dw $0E68 ; command FA(1) (percussion offset) [00:42] ; Num_Parameters_For_Commands: [00:42]