ROM Hack Making an SDAT?

[Kurausukun]

I want to make a custom, slightly modified SDAT of a game, but one of the SWARs is significantly larger than the original size. This isn't a problem for the SDAT itself--the format, as far as I know, has no real size limit. There is also plenty of space available in the ROM. The issue is that if I just try replacing the SWAR in question using Tinke, it doesn't work. I don't think it's a problem with the SWAR itself, but I have no way to test that--although it works when ripping 2sf or NCSF, so for the sake of my question, let's just assume it's not an issue.

Here's my question--are there any available tools that will let me take a filesystem and make it into a big ol' SDAT from scratch? I feel like this would work much better, or at least help diagnose the problem. Help is appreciated.

 

[FAST6191]

For this sort of thing I would probably manually edit. You will have several things to change so to make it easy I would stick it on the end and that just leaves the pointers, the sdat file size, the file section size and the SWAR itself.

Tools which can reliably take an unpacked SDAT and put it back together, you will want the smap files that the 2sf ripping does for this, are a bit thin on the ground and I try not to use them. Still kiwi.ds did a program called ndseditor I think it was which can do this, though it will want to do alphabetical order so you will have to have some fun with the names. http://kuribo64.net/board/thread.php?pid=33290#33290 has some discussion. There is probably a download on filetrip somewhere but http://hackromsacademy.forumcommunity.net/?t=51681896 has it otherwise.

How much larger is significantly larger though as a lot of the time it is not file size limits (32-31 bit pointers are common for the file sizes/section sizes) but memory limits if things are in memory, and even the emulation based stuff like 2sf might not be limited like that.

 

[Kurausukun]

The original SWAR was around 400KB, and my new one is around 1.1MB, so it's about 3 times as large. Pleonex also said it might be an issue with RAM, so now I'm worried. I was convinced that Tinke just wasn't writing the instrument offsets correctly, but that doesn't really sound right anymore.

I'll clarify just in case you happen to know anything specific--the particular game I'm working with is HGSS, and I'm trying to replace WAVE_ARC_BASIC. Just in case some more information helps, I'll give you a bit of an info dump of what I've tried, if you don't mind:

-I originally started this with Platinum, and I only replaced around three samples at that point, so it was only a few KB larger. It worked perfectly ingame except for one oddity--one of the songs, Giratina's battle theme, was completely silent. All sound effects and cries still played (I guess because they're in a different SWAR).
-I forget what I did to achieve this, but I have actually gotten the game to play some horrible-sounding static by manually hex editing something or another.

So if the issue is that the game forbids having that much data in RAM at one point, is there absolutely nothing I can do? It would be really cool if I could get this to work. Also, one last question--what exactly did you mean stick it on the end? The end of where? The SDAT file size and file section size are easy enough to edit, but I'm not sure exactly which pointers to edit, so I'd like a more detailed explanation, if you don't mind. I have a bit of an idea of how to manually hex edit parts of the SDAT/SWARs from this: http://www.feshrine.net/hacking/doc/nds-sdat.php, but some parts of it don't seem to line up with what I see in my hex editor, so I think I'm misinterpreting some stuff.

 

[FAST6191]

It is not so much the game forbidding as the system physically not having enough ( http://problemkaputt.de/gbatek.htm#dstechnicaldata -- you only have four megs and that has to include the binary and everything else which might be needed in memory, the pokemon franchise not known for small amounts of code either). You could work around some of this but for the most part most people just learn to be a bit less edit happy or otherwise work within the limitations of the game.

I recall once doing a worked example of editing SDAT without rebuilding, however it is not in my docs ( http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ ) so I guess I will be adding that when I return to fiddling with them. There were no major traps and if you work through a SDAT format spec it should be obvious (change anywhere that has a file size for the sections you are editing from the individual section sizes right on up to the main SDAT). By stick it on the end I mean just that -- put your edited file at the end of the SDAT and sort all the sizes as necessary. This spares you having to edit pointers for every song and sound effect otherwise in the game. If you have ever edited a GBA pokemon game and met the idea that people should just put it (it being whatever they are editing) in the blank space at the end of the ROM then same idea really.

I should probably also mention that some games do not like being rebuilt with certain tools, ndstool (which dsbuff and dslazy are frontends to) but tinke tends to handle things well so it is probably not that here.

 

[Kurausukun]

Wow, didn't know the DS had that little RAM. I guess it's looking more and more like it's just not possible with a file this big. In Gen V Pokemon games, I guess they avoided this by having smaller instrument banks for each song rather than having one big one for all of the songs to load. I would love to try that for HGSS as well, but I have no idea how to do multiple things I would need to do. I can think of a hacky way to make bank files for each new SWAR, but I would then need to edit each SSEQ to point to the proper bank. I also have no idea how to add a completely new file to the ROM, or make the banks point to the SWARs. I really haven't done any editing with banks or SSEQs, so I'm not confident I could accomplish it. This would also make the ROM considerably bigger due to instruments being included multiple times, and I'm not sure how to expand a DS ROM.

So I guess unless I really know what I'm doing, it would be impossible to make my 1MB file fit into the 4MB of RAM along with everything else the game has loaded. The whole point of my edit was making the instruments higher-quality, so if I tried to compress the size of the instruments, it would defeat the entire purpose. Unless there's some magical way of making SDATs smaller or using less RAM some other way, I don't think this is feasible anymore. Unless I'm overlooking something?