Hi, I just recently got into trying to make my own rom hack for the NDS and I'm not sure how to repoint sseq files outside of the sdat file to another part of the rom; whenever I try to repoint it to where the new sseq file is then the music won't play. I do have experience with repointing songs on the GBA but thats just messing around with one pointer and not having to deal with file pointers or anything like that. Any help would be appreciated; I'm using Sonic Rush as my testing ground for this so I hope that helps a little bit as well and if anything comes up I will update this thread with what I've found.
ROM Hack How do you repoint an sseq file to another part of the DS rom?
- Thread starter biolizardshadow
- Start date
- Views 3,089
- Replies 24
Why do you want to go to another part of the ROM? Expand the SDAT file and shove it in there instead. SDAT files can be as big as you like (it is not like they load the whole thing in memory after all).
If you absolutely must and can't be bothered to hardcode a read into the ROM you could possibly shove the SDAT at the front of the ROM and work out a destination relative to it for the internal pointer to use.
If you absolutely must and can't be bothered to hardcode a read into the ROM you could possibly shove the SDAT at the front of the ROM and work out a destination relative to it for the internal pointer to use.
When I insert the sdat to another location I get this error in Tinke (Non-negative number required. Parameter name: count.)
and when I try to load the rom in an emulator anyway the sound doesn't play so I'm assuming that the error I got when I tried to load it in Tinke is what's causing the no sound issue, and I'm not sure how to fix it so if you have any potential solutions that might work then I'm all for it.
I forgot to mention that their isn't enough free space in the rom for the repointed sdat so I had to expand the rom to make enough room for it.
and when I try to load the rom in an emulator anyway the sound doesn't play so I'm assuming that the error I got when I tried to load it in Tinke is what's causing the no sound issue, and I'm not sure how to fix it so if you have any potential solutions that might work then I'm all for it.
I forgot to mention that their isn't enough free space in the rom for the repointed sdat so I had to expand the rom to make enough room for it.
Last edited by biolizardshadow,
If tinke's insertion is not working find a tool that rebuilds the ROM instead. ndstool (had frontends in tools like dsbuff and dslazy), crystaltile2 has some abilities here (though you will need to find the full unbuild and rebuild rather than trying to import things) and there is NitroExplorer 3 but I am less familiar with that.
hmm, It seems that it doesn't like when I expand the sdat file. Do you know how to expand the file size without causing any sort of overflow? I know that a person on this site was able to somehow repoint either the sseq or sdat files (I'm not sure which one exactly) to another part of the rom, but responding to that thread is kind of pointless since that happened back in 2016 and that person didn't specify how they did.
Last edited by biolizardshadow,
Expanding might involve more than just adding stuff on with a hex editor. You might have to change the size and allocation table. Before you go too far into that though are there no leftover tracks or anything you can use instead?
I am not aware of people repointing within SDAT to read another part of the ROM. They might have put the SDAT elsewhere in a ROM and they might have repointed a SSEQ within a SDAT (it is an easy way to change what song is played). Indeed I don't even know that it would do something; in theory if you know all the locations it might have done something, however there could be any number of checks that get in the way.
I have some examples of fiddling with SSEQ and SDAT in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ for some of that.
That said what happened when you tried ndstool or some other full rebuild method?
I am not aware of people repointing within SDAT to read another part of the ROM. They might have put the SDAT elsewhere in a ROM and they might have repointed a SSEQ within a SDAT (it is an easy way to change what song is played). Indeed I don't even know that it would do something; in theory if you know all the locations it might have done something, however there could be any number of checks that get in the way.
I have some examples of fiddling with SSEQ and SDAT in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ for some of that.
That said what happened when you tried ndstool or some other full rebuild method?
Wait I think I know what the problem is: I decided to load the problematic file into VG Music Studio to see what would happen and I got this error (Index was outside the bounds of the array) so basically before I can put in a new entry it looks like I have to update the array. The only problem is that I'm not sure where that's located exactly or how I'm supposed to update it but any advice would be very helpful. 
--------------------- MERGED ---------------------------
How would I change the size of the file or find the allocation table?
--------------------- MERGED ---------------------------
How would I change the size of the file or find the allocation table?
Specs for SDAT files and their internals
http://kiwi.ds.googlepages.com/sdat.html
http://www.romhacking.net/documents/[469]nds_formats.htm#SDAT
http://kiwi.ds.googlepages.com/sdat.html
http://www.romhacking.net/documents/[469]nds_formats.htm#SDAT
I definitely like the looks of the second link. What does SYMB stand for, I've seen it before in the hex editor but I don't know what it stands for and I'm not sure if I need to change the size of it or not?
Last edited by biolizardshadow,
Not sure what symb stands for, though symbols or symbolic is probably going to be it.
FAT size should always be there unless it is compressed, and audio is usually the one thing that is never compressed beyond what it does internally.
FAT size should always be there unless it is compressed, and audio is usually the one thing that is never compressed beyond what it does internally.
Are you sure that the table size is at 0x14, I keep changing it and nothing happens I'll post that part of the header here.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
00000000 53 44 41 54 FF FE 00 01 E0 20 42 01 40 00 04 00 |
00000010 40 00 00 00 [5A 5B 00] 00 48 15 00 00 24 09 00 00 |
00000020 6C 1E 00 00 BC 06 00 00 28 25 00 00 B8 FB 41 01 |
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
00000040 53 59 4D 42 08 15 00 00 40 00 00 00 D8 00 00 00 |
00000050 54 04 00 00 C4 04 00 00 30 05 00 00 4C 05 00 00 |
|
-------------------------------------------------------------------------------------------------------------------------------------------------------------
That should be it right, or is their something I'm doing wrong here?
Also the Expanded offset goes till 027FFFF0, I did notice that after Symb their is an array of pointers but I'm not sur as to what yet.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
00000000 53 44 41 54 FF FE 00 01 E0 20 42 01 40 00 04 00 |
00000010 40 00 00 00 [5A 5B 00] 00 48 15 00 00 24 09 00 00 |
00000020 6C 1E 00 00 BC 06 00 00 28 25 00 00 B8 FB 41 01 |
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
00000040 53 59 4D 42 08 15 00 00 40 00 00 00 D8 00 00 00 |
00000050 54 04 00 00 C4 04 00 00 30 05 00 00 4C 05 00 00 |
|
-------------------------------------------------------------------------------------------------------------------------------------------------------------
That should be it right, or is their something I'm doing wrong here?
Also the Expanded offset goes till 027FFFF0, I did notice that after Symb their is an array of pointers but I'm not sur as to what yet.
Last edited by biolizardshadow,
Also, do you know what bytes 0x20 and 0x21 might stand for (It's in in the table from my last post). Whenever I edit them I always get an index was out of range error, what's even more interesting is that I found something on the FAT that determines how many file it's going to load and whenever I change it I get that same error. In this hex image the FAT starts at bytes (46 41 54 20) and the interesting byte that I was fiddling around with is byte (FF) whenever I increase it nothing really happens but, when I decrease it I get the error message I stated before but so far the error I've been getting is the Arithmetic operation resulted in an overflow error but what found is somewhat interesting.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00001E60 6A 00 00 00 48 40 00 00 00 00 00 00 46 41 54 20
00001E70 BC 06 00 00 FF 00 00 00 40 25 00 00 F4 0E 00 00
-----------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00001E60 6A 00 00 00 48 40 00 00 00 00 00 00 46 41 54 20
00001E70 BC 06 00 00 FF 00 00 00 40 25 00 00 F4 0E 00 00
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Honestly I'm not sure what's wrong exactly because different programs are giving me different error messages
Tinke say's that the ( Arithmetic operation resulted in an overflow)
VG Music Studio says the (Index was outside the bounds of the array)
Nitro Studio gives the following error message (InvalidArgument=Value of "0" is not valid for SelectedIndex Parameter name: Selectedindex)
Most of these are saying something about an index but I'm not sure what or where it's located within the SDAT file.
Tinke say's that the ( Arithmetic operation resulted in an overflow)
VG Music Studio says the (Index was outside the bounds of the array)
Nitro Studio gives the following error message (InvalidArgument=Value of "0" is not valid for SelectedIndex Parameter name: Selectedindex)
Most of these are saying something about an index but I'm not sure what or where it's located within the SDAT file.
Last edited by biolizardshadow,
I think we probably need to investigate what you are doing and what you attempting to do. An array or index being off sounds like something edited something and it messed up the maths it did on it (if it is a value of 0 where it should be literally anything else then that can lead to all sorts of fun when dividing, subtracting, multiplying and whatever else).
So you have a game and want to edit some music. Just for fun right now but with an eye to being able to do it practically later in the day, which is perfectly fine.
You made a new song (mid2sseq or whatever giving you one, don't much care if it is an edit to the existing one, some random midi you found somewhere or one you wrote other than source of it might change how some of the conversion tools change things and some of the loop editing tools also have their downsides).
You now want to put it in the SDAT file.
I should have noted I do like to a SMAP file available when I am editing SDAT files just to have a reference I can easily read to hand, VGMtoolbox should generate one of these. Crystaltile2's SDAT viewer is an almost acceptable alternative as well.
For whatever reason you don't want to overwrite the existing one (if the new SSEQ is the same size or smaller than the old one do consider it as it saves a lot of hassle) so instead want to repoint to somewhere else. Initially you thought you might like to have it load a SSEQ from somewhere else in the ROM but that might not be practical, or at least would require a serious tweak to various file handlers.
Traditionally if there is nothing else to cannibalise (many games have tracks not used in the final game) you instead extend the file and put it at the end.
There are a few programs that will attempt to sort things (tinke, some sdat builders, maybe crystaltile2, don't know what happened to VGMtrans) but they are quite iffy really when all is said and done and usually cause more problems than they solve. You can try importing a SSEQ with those anyway (or rebuilding if it is one of those) but for the rest of it I will assume they have failed.
What any given game will want changed here will vary (sometimes a lot of the data in the header of various formats is pretty much redundant as far as the final game is concerned) but we will be good little hackers today and change everything that might bother it.
In the case of the SDAT format there are probably several layers of the format to wade through that might want changing here with each wanting their say.
The SDAT itself will note its own size. This might be redundant but until you can argue otherwise assume it is not.
After the "Generic Header Format" part common to many DS formats, which has a size value, will be the SDAT's initial categorisation of itself. I think we might have had a miscommunication there or you might have skipped over that part if you were going off the romhacking.net description as it downplays that part and you should have had to scroll back up. https://web.archive.org/web/20080324141531/http://kiwi.ds.googlepages.com/sdat.html does more for me here, though the C programming style description can be annoying to deal with if you have not dealt with such things before.
Size wise sticking in the description section of the SDAT itself you are pretty much only changing "Size of FILE Section" if you are adding on a replacement file. If you were adding whole new files into it (and not removing others) then other things would change as everything get shuffled forward to account for things. FILE being the last section helping with this one (if it was not then everything else would get shuffled, I imagine this is by design).
Assuming you are not changing the audio bank, volume or anything else then you can leave all that alone. Sometimes if you are injecting a new file, such as from another game (I have an example the hacking docs here about injecting phoenix wright games with audio from sequels/prequels, the track needing its corresponding bank), you might want to change the instruments (bank files) but skip that for now.
For editing purposes you will however be changing some data within the FAT section too as it notes where files ultimately live (FILE section mainly just housing files with FAT describing where they are, such things being easier on memory requirements as you are not randomly scanning through megabytes of stuff to get a few bytes). As this should be just values within the FAT section there should be no size change, just overwriting to reflect the new location and size of new file.
Finally we get to the FILE section itself which has a Section Size in it, change this to its new one.
That should be everything.
The earlier stuff where I pondered whether you could read from elsewhere the ROM by faking it out would possibly also come into play here if this was what was happening
The way this would work is the DS does not keep the ROM in memory like older systems. It has a command (B7 on http://problemkaputt.de/gbatek.htm#dscartridgeprotocol ) to read data from the ROM. What a given game will do here might vary but the idea of putting it somewhere else would hope that the ROM when running goes all the way down the line collecting locations within the FILE, then of FILE within the SDAT, then of SDAT within the ROM, adds the lot up and says this much data at this location. If you faked this out (and maybe the relevant values above as well in case it tries to be clever and checks it has a real value within the expected size range, though it would be acceptable to skip this for a first test as checking for legal values is not something you normally do in game programming -- it is called Read Only Memory for a reason, even on a PS4 you still don't want to be wasting resources, and you usually rely on people knowing what they are doing for the game you are about to spend potentially millions to publish) you could possibly get it to read outside the file and later into the ROM (the SSEQ wanting to appear at a point later in the ROM than the SDAT (theoretically you have 32 bits to note the location and that is gigabytes which is more than enough).
So you have a game and want to edit some music. Just for fun right now but with an eye to being able to do it practically later in the day, which is perfectly fine.
You made a new song (mid2sseq or whatever giving you one, don't much care if it is an edit to the existing one, some random midi you found somewhere or one you wrote other than source of it might change how some of the conversion tools change things and some of the loop editing tools also have their downsides).
You now want to put it in the SDAT file.
I should have noted I do like to a SMAP file available when I am editing SDAT files just to have a reference I can easily read to hand, VGMtoolbox should generate one of these. Crystaltile2's SDAT viewer is an almost acceptable alternative as well.
For whatever reason you don't want to overwrite the existing one (if the new SSEQ is the same size or smaller than the old one do consider it as it saves a lot of hassle) so instead want to repoint to somewhere else. Initially you thought you might like to have it load a SSEQ from somewhere else in the ROM but that might not be practical, or at least would require a serious tweak to various file handlers.
Traditionally if there is nothing else to cannibalise (many games have tracks not used in the final game) you instead extend the file and put it at the end.
There are a few programs that will attempt to sort things (tinke, some sdat builders, maybe crystaltile2, don't know what happened to VGMtrans) but they are quite iffy really when all is said and done and usually cause more problems than they solve. You can try importing a SSEQ with those anyway (or rebuilding if it is one of those) but for the rest of it I will assume they have failed.
What any given game will want changed here will vary (sometimes a lot of the data in the header of various formats is pretty much redundant as far as the final game is concerned) but we will be good little hackers today and change everything that might bother it.
In the case of the SDAT format there are probably several layers of the format to wade through that might want changing here with each wanting their say.
The SDAT itself will note its own size. This might be redundant but until you can argue otherwise assume it is not.
After the "Generic Header Format" part common to many DS formats, which has a size value, will be the SDAT's initial categorisation of itself. I think we might have had a miscommunication there or you might have skipped over that part if you were going off the romhacking.net description as it downplays that part and you should have had to scroll back up. https://web.archive.org/web/20080324141531/http://kiwi.ds.googlepages.com/sdat.html does more for me here, though the C programming style description can be annoying to deal with if you have not dealt with such things before.
Size wise sticking in the description section of the SDAT itself you are pretty much only changing "Size of FILE Section" if you are adding on a replacement file. If you were adding whole new files into it (and not removing others) then other things would change as everything get shuffled forward to account for things. FILE being the last section helping with this one (if it was not then everything else would get shuffled, I imagine this is by design).
Assuming you are not changing the audio bank, volume or anything else then you can leave all that alone. Sometimes if you are injecting a new file, such as from another game (I have an example the hacking docs here about injecting phoenix wright games with audio from sequels/prequels, the track needing its corresponding bank), you might want to change the instruments (bank files) but skip that for now.
For editing purposes you will however be changing some data within the FAT section too as it notes where files ultimately live (FILE section mainly just housing files with FAT describing where they are, such things being easier on memory requirements as you are not randomly scanning through megabytes of stuff to get a few bytes). As this should be just values within the FAT section there should be no size change, just overwriting to reflect the new location and size of new file.
Finally we get to the FILE section itself which has a Section Size in it, change this to its new one.
That should be everything.
The earlier stuff where I pondered whether you could read from elsewhere the ROM by faking it out would possibly also come into play here if this was what was happening
The way this would work is the DS does not keep the ROM in memory like older systems. It has a command (B7 on http://problemkaputt.de/gbatek.htm#dscartridgeprotocol ) to read data from the ROM. What a given game will do here might vary but the idea of putting it somewhere else would hope that the ROM when running goes all the way down the line collecting locations within the FILE, then of FILE within the SDAT, then of SDAT within the ROM, adds the lot up and says this much data at this location. If you faked this out (and maybe the relevant values above as well in case it tries to be clever and checks it has a real value within the expected size range, though it would be acceptable to skip this for a first test as checking for legal values is not something you normally do in game programming -- it is called Read Only Memory for a reason, even on a PS4 you still don't want to be wasting resources, and you usually rely on people knowing what they are doing for the game you are about to spend potentially millions to publish) you could possibly get it to read outside the file and later into the ROM (the SSEQ wanting to appear at a point later in the ROM than the SDAT (theoretically you have 32 bits to note the location and that is gigabytes which is more than enough).
I pretty much don't know what I'm doing here, I was going off of the knowledge I obtained from creating a rom hack on the GBA, and there it was relatively simple, all you had to do was change 4 bytes and bam your song would work. At first I thought the same thing here where all I had to do was change 4 bytes to reflect the new song location in the SDAT. I guess It's not as simple as I thought, either that or I changed the wrong bytes but the reason I did this is because I didn't want to be restricted by file size that's why I decided to go on this long journey of figuring out how to get sound to work here.
WAIT! I just realized I that nitro studio can insert additional SSEQ files XD. But theirs still one problem: whenever I rebuild the rom the SDAT doesn't play in game for some reason, is their a way to get it to work?
First if you can work with GBA pointers you can work with nice DS format level ones.
The whole SDAT does not work or just your new SSEQ does not play?
If you just stuck a new SSEQ in there by itself the game will not know to call it (it probably only knows the tracks it already has). You would then probably want to do the classic audio redirect tweak in that case (worked examples in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , do remember to change the bank if you want).
If the whole thing fails then whatever you used to insert it (can't say if I have even heard of Nitro Studio, definitely have not used it or seen it be used) probably broke something somewhere along the way. You then get to fix it (you have the file format descriptions, step through it all and make sure it is all valid or at least the differences between stock and modded make sense), or more likely say no thanks and go manual insertion.
It might also be your modded track is broken somewhere (various things to SSEQ convertors and exporters have hard time with some things, I tend not to play with them though so don't know what the current crop fails at).
The whole SDAT does not work or just your new SSEQ does not play?
If you just stuck a new SSEQ in there by itself the game will not know to call it (it probably only knows the tracks it already has). You would then probably want to do the classic audio redirect tweak in that case (worked examples in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ , do remember to change the bank if you want).
If the whole thing fails then whatever you used to insert it (can't say if I have even heard of Nitro Studio, definitely have not used it or seen it be used) probably broke something somewhere along the way. You then get to fix it (you have the file format descriptions, step through it all and make sure it is all valid or at least the differences between stock and modded make sense), or more likely say no thanks and go manual insertion.
It might also be your modded track is broken somewhere (various things to SSEQ convertors and exporters have hard time with some things, I tend not to play with them though so don't know what the current crop fails at).
If you say that the pointers between GBA and the DS are the same well that's weird cause that's what I was doing earlier, I did use crystal tile to see if what I was changing were the song pointers and it was but changing the song pointers some how broke it or maybe I didn't change something that I should have? I'm not really sure what happened but I was able to get the song working using nitro studio so at least I'm further ahead than I was a few day's ago. Finding good reliable information about how to properly insert songs especially manual insertion is hard, it seems that you have to know what you are doing to be able to get it to work properly. Something that I've been pondering is whether you can use GB sound channels on the DS especially channel 3. I know that Nintendo probably didn't want to keep the Gameboy sound hardware in the their next portable system (the 3DS) so I imagine they told game devs that they couldn't use those sound channels if they wanted their game on the DS I'm not entirely sure if that's truly the case since you can use a noise channel I'm not sure if that's from the original Gameboy especially (since it has so many more frequency's) and I'm not sure where these PSG's are coming from either but it is interesting. So far nitro studio has been working for me and you can do a lot with it so it might be worth a shot to try it out also to get the song to work all I had to do was rename it to sound_data.sdat for anyone who comes across this post in the future
Thank you for helping me, I know more now than I did when I started
Thank you for helping me, I know more now than I did when I started
Last edited by biolizardshadow,
On and DS pointers. If you can handle the whole 08000000 through 09FFFFFF + mirrors thing then DS pointers should not pose a problem.
Working in nitro studio if you made it there in the first place is nothing too unusual-- most programs will be able to eat their own dog food as it were. If they were build on a fundamental misconception (or have a bug that acts as though it was) then being able to play back what they made has no real bearing on what the hardware/game tries to do.
DS channel wise there are 16 fully leaded channels available at all points (no handful with only one doing any kind of wave like stuff any more)
http://problemkaputt.de/gbatek.htm#dssound
There are similarities between it all but the GBA (for others playing along at home I do usually suggest http://belogic.com/gba/ , navigation at the top of the page) was probably the last gasp of old school sound chip type design. Since then it has been largely software based really.
On editing pointers have you been able to edit something within an existing game? The stuff we do to change say Tetris to always play Tetris theme in vs mode.
Or follow along with some of the examples in the guide mentioned before? Though maybe not the exact same game and song combo but the same idea in another ROM.
Working in nitro studio if you made it there in the first place is nothing too unusual-- most programs will be able to eat their own dog food as it were. If they were build on a fundamental misconception (or have a bug that acts as though it was) then being able to play back what they made has no real bearing on what the hardware/game tries to do.
DS channel wise there are 16 fully leaded channels available at all points (no handful with only one doing any kind of wave like stuff any more)
http://problemkaputt.de/gbatek.htm#dssound
There are similarities between it all but the GBA (for others playing along at home I do usually suggest http://belogic.com/gba/ , navigation at the top of the page) was probably the last gasp of old school sound chip type design. Since then it has been largely software based really.
On editing pointers have you been able to edit something within an existing game? The stuff we do to change say Tetris to always play Tetris theme in vs mode.
Or follow along with some of the examples in the guide mentioned before? Though maybe not the exact same game and song combo but the same idea in another ROM.
Similar threads
-
-
-
-
-
-
-
@
Psionic Roshambo:
Broken condoms lead to broken hearts, won't someone think of the children!!! Lol+2 -
-
-
-
-
-
-
-
-
@
Xdqwerty:
@SylverReZ, @Psionic Roshambo something like each group of 3 does the exam (dunno how to explain it)+1 -
-
-
-
@
Xdqwerty:
@Psionic Roshambo, More or less those activities where two or more people do a exam instead of 1 (I still don't know how to explain)
-
-
-
-
-
I was gonna say that. lol
