Does DeSmuME have any memory watch function that allows me to see how much RAM is currently not being used? I'm trying to see how much I can fit into my RAM before the game will refuse to load my file.
ROM Hack Check How Much RAM Is Free?
- Thread starter Kurausukun
- Start date
- Views 1,452
- Replies 12
- Likes 1
Not pure desmume but there is a build with a measure of support for such things.
http://gbatemp.net/threads/unofficial-desmume-build-unused-memory-finder-tool.349332/
Generally speaking though as the DS does not have an operating system the concept of free memory is a rather more hazy one.
In the case of homebrew the general sum will likely be 4 megabytes - size of ARM9.bin - any assets not in the ARM9.bin that you are also loading. Obviously you can do things like create large tables at run time but if you are stuffing the RAM it is probably not going to be the case. Likewise DLDI is built such that it allows for a measure of streaming or something like it so as to lessen the memory problem.
http://gbatemp.net/threads/unofficial-desmume-build-unused-memory-finder-tool.349332/
Generally speaking though as the DS does not have an operating system the concept of free memory is a rather more hazy one.
In the case of homebrew the general sum will likely be 4 megabytes - size of ARM9.bin - any assets not in the ARM9.bin that you are also loading. Obviously you can do things like create large tables at run time but if you are stuffing the RAM it is probably not going to be the case. Likewise DLDI is built such that it allows for a measure of streaming or something like it so as to lessen the memory problem.
Thanks for the build, I'll try it out. But I question your statement that the concept of "free memory" is hazy--either the memory is being used or it isn't. At some point, my file will become big enough that the game will not load it because it sees in the metadata that it is too big to fit into RAM. That's what I'm trying to find.
Sorry for the delay in getting back to you.
I have seen things in DS memory that I had not seen since the terminate and stay resident days of DOS, and assembly coding with fixed addresses was still a thing, not to mention various things which almost allocated a scratch space.
If you are doing pure C family code with properly sorted allocate and release (no leaks or anything) then yes free memory is a thing, likewise there are versions of Linux for the DS and they have memory management recognisable to the OS. The hardware and any underlying firmware have no real concept of individual/isolated programs or threads though. In commercial games there are any number of things which are used and may never be used again, or only used in extreme circumstances (full soft reboot say), or may be fixed and only used in a rarely seen part of the game (search a ARM9 binary of a web based game for ASCII strings and you will possibly find exotic types of network error codes in multiple languages).
If you are writing your own code you could probably include a simple counter that is changed every allocation and decreased for every release, if in commercial code then all bets are off.
I have seen things in DS memory that I had not seen since the terminate and stay resident days of DOS, and assembly coding with fixed addresses was still a thing, not to mention various things which almost allocated a scratch space.
If you are doing pure C family code with properly sorted allocate and release (no leaks or anything) then yes free memory is a thing, likewise there are versions of Linux for the DS and they have memory management recognisable to the OS. The hardware and any underlying firmware have no real concept of individual/isolated programs or threads though. In commercial games there are any number of things which are used and may never be used again, or only used in extreme circumstances (full soft reboot say), or may be fixed and only used in a rarely seen part of the game (search a ARM9 binary of a web based game for ASCII strings and you will possibly find exotic types of network error codes in multiple languages).
If you are writing your own code you could probably include a simple counter that is changed every allocation and decreased for every release, if in commercial code then all bets are off.
Thanks for even bothering to reply to this, don't worry about how long it took.
I see your point now, I only had a concept of memory as it applied to an OS. And no, I am not writing my code, nor do I feel confident that I could make modifications to the commercial code that would allow me to load things into RAM differently. I just wanted to know how much bigger I could make a file before it exceeded what the game was willing to load into RAM since I have learned that it will stop loading it after it gets too big, but I am not sure how big "too big" is, exactly. It would certainly be possible to find out with trial and error, but I'm working with SWARs, and it's annoying to remake, repack, and re-insert them into a ROM every single time I try a new size.
I see your point now, I only had a concept of memory as it applied to an OS. And no, I am not writing my code, nor do I feel confident that I could make modifications to the commercial code that would allow me to load things into RAM differently. I just wanted to know how much bigger I could make a file before it exceeded what the game was willing to load into RAM since I have learned that it will stop loading it after it gets too big, but I am not sure how big "too big" is, exactly. It would certainly be possible to find out with trial and error, but I'm working with SWARs, and it's annoying to remake, repack, and re-insert them into a ROM every single time I try a new size.
If it is audio then for New Super Mario Brothers dirbaio made some code to load wave files directly (the hardware has PCM and ADPCM support which is nice) into RAM and get them played.
https://gbatemp.net/threads/telling-the-game-to-play-a-strm-instead-of-sseq.340692/ has some more on that. It should be possible to adapt it as well.
https://gbatemp.net/threads/telling-the-game-to-play-a-strm-instead-of-sseq.340692/ has some more on that. It should be possible to adapt it as well.
That wasn't exactly my intent, and I don't think this will bypass my issue; The game I'm working with is HGSS, which at least uses the standard SDAT format, but I'm trying to hack in higher quality samples from the later games. It sounds great if you rip them to NCSF or 2SF, but the DS doesn't have enough RAM to load all of them at once, and it seems that you can only load entire SWAVs at once since you don't know which instruments would be used.
What I want to do is hack it so the game just uses a different SWAV for each song so I can have a bunch of files that only contain the necessary samples for a certain song. The problem with this is that I honestly don't know how the game decides which SWAV to load for a song, and I'd also have to rebuild the SYMB table in the SDAT, which I'm not sure I could do easily.
What I want to do is hack it so the game just uses a different SWAV for each song so I can have a bunch of files that only contain the necessary samples for a certain song. The problem with this is that I honestly don't know how the game decides which SWAV to load for a song, and I'd also have to rebuild the SYMB table in the SDAT, which I'm not sure I could do easily.
I have never seen it used for an end stage hack (proof of concept yes) and would not be ideal (would not do for the DSi for instance and hardware would require an additional flash cart) but the GBA cart (32 megs of fast memory, probably read only in most scenarios you will want to use) is memory mapped. That said if you are dealing with file level pointers rather than memory level that could get fun in a hurry.
I probably should look at a SDAT format listing for this rather than go from memory but is the swav library not picked from a bank? I have modded games to use different banks for given songs before and injected new instruments as part of it. That said I had spare banks I could overwrite from songs in the SDAT but not the final game which spared me (another) manual rebuild.
I probably should look at a SDAT format listing for this rather than go from memory but is the swav library not picked from a bank? I have modded games to use different banks for given songs before and injected new instruments as part of it. That said I had spare banks I could overwrite from songs in the SDAT but not the final game which spared me (another) manual rebuild.
I'm pretty sure the SWAR is determined by the SBNK, but I'm not sure exactly how the logic works because although I believe I know what I'm reading, the hex always seems to point to SWAR 0. There are around 500 SWARS with just a single SWAV in them for Pokemon cries that come before the instrument banks, but it doesn't start at 500 or anything, so I'm not sure what to make of that. All of my knowledge of these formats come from this specification description: http://www.feshrine.net/hacking/doc/nds-sdat.php. Generally what I find agrees with this specification, but I don't understand the indexing of the SWARs. Or does it not even matter? As long as the note is defined in a SBNK, does the game just figure out where it is somehow? I doubt it would be that easy. I might study some more SBNKs, but I remember looking through Black and White, which has a SBNK for every song, I seem to remember the SWAR index always being 0.
The fact that you can technically use the GBA slot for memory is interesting, though I highly doubt I have anywhere near the technical ability to figure that out. I'm hoping to be able to accomplish this just via file editing and replacing; if I have to modify code, I honestly think it will be beyond me to make it work. Thank you for helping me so far, though, you've given me some good information.
The fact that you can technically use the GBA slot for memory is interesting, though I highly doubt I have anywhere near the technical ability to figure that out. I'm hoping to be able to accomplish this just via file editing and replacing; if I have to modify code, I honestly think it will be beyond me to make it work. Thank you for helping me so far, though, you've given me some good information.
The SWAR is determined by the SBNK. When building a SDAT with Nitro Sound Maker, you are able to configure which SWAR the sequence uses.
About your issue though, it looks like the game refuses to take your modified files (I also have this issue) for some reason. What's causing it exactly, I'm not very sure. Maybe you could use some reverse engineering to figure it out, perhaps. But I doubt that this issue is caused by RAM.
Why do you doubt that? I tested it by making a custom file that was smaller than the original, and things played properly. This was by replacing the SWAR instead of adding a new one, though, but I think it pretty much confirms the fact that the issue was RAM (my new SWAR is around 1.1MB, up from the old one which was around 400KB). Is Nitro Sound Maker part of the DS/Nitro SDK, or is it available somewhere else? If it's part of the SDK, I think I'm pretty much out of luck there unless someone knows how it actually works in the files.
The main reason I doubt that it's a RAM issue is because of the fact that I made a small SWAR using Nitro Sound Maker (which is part of the NitroSDK) and a SBNK pair. I replaced some files in game with the ones that I made, and of course that caused the game to not play them. I think the main problem is the SDAT working in tandem with the game, as when you replace a SWAR with a bigger SWAR, it will cause some things to move around. Probably the same with SSEQ, SBNK, etc. Just speculation though, since the SDAT does work outside of the game.
I'd imagine stuff moves around when you make it smaller too. I'm honestly just taking it on good faith that Tinke is replacing files correctly, and it's worked so far. But when I add new SWARs and SBNKs, I'm going to need to use kiwi's editor to rebuild the ROM.
Similar threads
(
