gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > DS Data/Program Memory Space

#43525 - jmva16 - Tue May 24, 2005 4:13 am

Is it true that the DS only has 4MB of working memory space? And that this is shared (arm9 and arm7) and combined (program and data) memory, not including the 32KB of cache memory?

Thanks in advance

#43526 - Chetic - Tue May 24, 2005 4:17 am

I'm pretty damn sure it is..

#43528 - Darkain - Tue May 24, 2005 4:52 am

nothing is stopping you from loading data from a flashcart
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

#43531 - tepples - Tue May 24, 2005 5:55 am

Darkain wrote:
nothing is stopping you from loading data from a flashcart

Other than the fact that the ARM7 and ARM9 can't access the cart at the same time perhaps? That sort of complicates a direct port of, say, GBFS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#43534 - sajiimori - Tue May 24, 2005 6:04 am

I wonder if larger games will start feeling the pressure of having to put code in RAM, and switch to dynamically loadable code modules. When you have to immediately throw away over a meg for code, and over half of it is for non-speed-critical game logic, compact and dynamic bytecode representations can look mighty nice.

#43546 - jmva16 - Tue May 24, 2005 1:52 pm

Darkain wrote:
nothing is stopping you from loading data from a flashcart

I was considering this. Dovoto's tutorial mentions the shared combined memory space is 16 bits and operates at 12MHz. Anybody know at what speed the bus to the cart rom operates at?

#43576 - crossraleigh - Tue May 24, 2005 9:05 pm

Quote:
That sort of complicates a direct port of, say, GBFS.

I heard someone on IRC (Darkain even, I think) say that GBFS works on the DS without modifications. Right now, most people don't use the ARM7 anyway.

#43590 - tepples - Tue May 24, 2005 11:44 pm

jmva16 wrote:
Dovoto's tutorial mentions the shared combined memory space is 16 bits and operates at 12MHz. Anybody know at what speed the bus to the cart rom operates at?

I assume that by "12 MHz" you mean "11.17 MHz", which is one-third the speed of the ARM7, just as GBA EWRAM is one-third the speed of its ARM7. I'll also take an educated guess that for compatibility reasons (e.g. Feel The Magic unlockables), GBA carts run at roughly the same speed on the Nintendo DS as they do on the GBA: 4.2 MHz random, 8.4 MHz sequential, assuming 3/1 wait state settings.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#43595 - Abcd1234 - Wed May 25, 2005 12:31 am

sajiimori wrote:
I wonder if larger games will start feeling the pressure of having to put code in RAM, and switch to dynamically loadable code modules. When you have to immediately throw away over a meg for code, and over half of it is for non-speed-critical game logic, compact and dynamic bytecode representations can look mighty nice.


OTOH, I expect most of the space taken up by games is in artwork, sound, and other data. The actual kernel for most games is likely to be fairly small... certainly less than 4MB (which is a *ton* of code).

#43628 - jmva16 - Wed May 25, 2005 6:26 am

Here is the question then. How do you compile in a large amout of data to be accessed in the cart rom? With the templates provided, any resource files get concatenated onto the arm binary. The loader then tries to load the entire data into EWRAM. I would want to have data that the loader does not know about, but I would have a pointer to it, that is known at linker time.

Right now I am compiling the code, checking the size of the .ds.gba file, setting the pointer to 0x8000000 + the size of the .ds.gba, recompiling the code, double checking the size of the .ds.gba, then concatenating the .ds.gba and my binary data file.

#43657 - tepples - Wed May 25, 2005 2:09 pm

jmva16 wrote:
I would want to have data that the loader does not know about, but I would have a pointer to it, that is known at linker time.

Is knowing the pointer at runtime acceptable? Because that's what GBFS does. Pad your .gba to a 256 byte boundary (with the included 'incbin' utility), and then concatenate the GBFS file to the end.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#43681 - wintermute - Wed May 25, 2005 6:26 pm

jmva16 wrote:
Here is the question then. How do you compile in a large amout of data to be accessed in the cart rom? With the templates provided, any resource files get concatenated onto the arm binary. The loader then tries to load the entire data into EWRAM. I would want to have data that the loader does not know about, but I would have a pointer to it, that is known at linker time.

Right now I am compiling the code, checking the size of the .ds.gba file, setting the pointer to 0x8000000 + the size of the .ds.gba, recompiling the code, double checking the size of the .ds.gba, then concatenating the .ds.gba and my binary data file.


The nds format allows for a file system. Eventually we will provide code to access the files in the nds, hopefully via stdio drivers.

#43882 - jmva16 - Fri May 27, 2005 4:20 pm

tepples wrote:
Is knowing the pointer at runtime acceptable? Because that's what GBFS does. Pad your .gba to a 256 byte boundary (with the included 'incbin' utility), and then concatenate the GBFS file to the end.

Thank you to everybody for their help. I have added GBFS to my project. It was easy and effective. If anybody else is trying the same thing, I would suggest the GBFS route.

#48375 - spunky - Tue Jul 19, 2005 5:31 pm

about gbfs.. I just dont get it running..

Code:


WAIT_CR &= ~0x80;
GBFS_FILE const* gbfs_file =
      find_first_gbfs_file((void*)0x8000000);


and gbfs_file is already null and thus all following functions dont work.
I checked the binary of the nds.gba and it contained the filesystem at the end so it should be in there.. : (
any help? do I have to using incbin at all?
I looked at the filesystem example from double.co.nz and did it the same way, no luck yet. Sigh

#48376 - tonysavon - Tue Jul 19, 2005 5:51 pm

have you padded the nds file before appending the gbfs filesystem to it?
you should add something like
padbin 0x100 program.nds
to your makefile before the cat command takes place.
when I switched to devkitarm 14, the GBFS stuff (including the double.co.cz programs) stopped working. It worked again with the padding (as if devkitarm 13 produced already padded bins)

#48379 - spunky - Tue Jul 19, 2005 6:18 pm

thanks man, just now I wrote my own padbin exe, cause I couldnt fint it : ( and now it works :D
Yihaaa so awesome!

#48380 - wintermute - Tue Jul 19, 2005 6:20 pm

tonysavon wrote:
have you padded the nds file before appending the gbfs filesystem to it?
you should add something like
padbin 0x100 program.nds
to your makefile before the cat command takes place.
when I switched to devkitarm 14, the GBFS stuff (including the double.co.cz programs) stopped working. It worked again with the padding (as if devkitarm 13 produced already padded bins)


hmm, this one is going to be slightly problematic.

Since so many people were having trouble with uninitialised data being placed in dtcm the linkscripts with r14 now place bss in ewram. In order to use GBFS in memory (as you would need for a wifi app) you're going to have to pad the binary by the size of the bss segment. It should also be noted that malloc will return addresses which overlap the file system in this case.

The only thing I can think of doing is to provide a hook in the crt0 which would allow a function to be called before bss is cleared which would move the filesystem to the end of the bss segment and reset the base of the heap to the end of the filesystem.

Anyone got any better ideas?

#48423 - Sausage Boy - Tue Jul 19, 2005 10:38 pm

Has anyone successfully used gbfs with WMB, and, in that case, how did you do?

I've padded and objdumped and whatever for a while now, but it doesn't seem to work.
The gbfs pointer always ends up as NULL. I pad arm9.bin with the dumped bss value, append
the filesystem to arm9.bin with "cat arm9.bin fs/airstrike.gbfs>arm9fs.bin",
and then look for the filesystem at 0x02000000. Do I need to do something to
be able to read the arm9 stuff? Am I looking at the right place?

I'd be thankful for any kind of information.
_________________
"no offense, but this is the gayest game ever"

#48437 - tepples - Tue Jul 19, 2005 11:33 pm

Try this:
Code:
bin2s data.gbfs > data.s
arm-elf-gcc -Wall -mthumb-interwork data.s -o data.o

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#48534 - Sausage Boy - Wed Jul 20, 2005 5:21 pm

That would make the compilator link the .o just like it does with individual files without a filesystem, right? And I would still search at 0x02000000?

Just out of curiosity, why not use bin2o?
_________________
"no offense, but this is the gayest game ever"

#48553 - tepples - Wed Jul 20, 2005 7:26 pm

When you add a GBFS file using the bin2s method, you wouldn't have to search for anything. Just put this in a header file:
Code:
extern const GBFS_FILE data_gbfs;

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#48560 - Sausage Boy - Wed Jul 20, 2005 7:53 pm

Oh. Thanks :D

Darn, there goes my beautiful sed | awk command for extracting the bss and using it with padbin...
_________________
"no offense, but this is the gayest game ever"

#49717 - xflash - Mon Aug 01, 2005 11:31 pm

tepples wrote:
When you add a GBFS file using the bin2s method, you wouldn't have to search for anything. Just put this in a header file:
Code:
extern const GBFS_FILE data_gbfs;


I've got a 6MBytes GBFS file to include, and with the bin2s method, it overlaps on the EWRAM...
So the bin2s method is great for little GBFS file, but what for big ressources to include ?

Thanks four great job here guys ! :)

xf

#49730 - tepples - Tue Aug 02, 2005 2:12 am

If you have a 6 MB .gbfs file, you will not be able to use FlashMe+WMB or *Me+GBAMP; you'll need a GBA flash card. Run padbin on your .nds file and then concatenate the loader + .nds file + .gbfs file to make a .ds.gba ROM. The .bss thing won't be an issue if the .ds.gba file is in GBA ROM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#49758 - xflash - Tue Aug 02, 2005 8:09 am

Ok, thanks for the answer. But what about emulators? Does anyone know why dualis or Dsemu crash when I attempt to access the find_first_file() function on a GamePak addressing range ?

xf

#49828 - tepples - Tue Aug 02, 2005 9:06 pm

xflash wrote:
Ok, thanks for the answer. But what about emulators? Does anyone know why dualis or Dsemu crash when I attempt to access the find_first_file() function on a GamePak addressing range ?

I'd imagine that some of the Nintendo DS emulators don't know about GBA ROM, that they can run standalone programs (*.nds) but not PassMe images (*ds.gba). Right now, in terms of emulation accuracy, publicly available Nintendo DS emulators aren't even up to the level of Nesticle.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#49851 - doublec - Tue Aug 02, 2005 11:41 pm

dsemu should work for gbfs filesystems appended to the .nds file. It runs the space invaders game which does exactly that.

Tepples is right in that dsemu won't run the nds.gba file. It needs the .nds.

#49855 - xflash - Wed Aug 03, 2005 12:34 am

I didn't succeed in running any .NDS rom on any emulators with some GBFS use. For example, your gbfs_demo built with devkitARM r14 doesn't work woth either DSemu 0.4.2 or Dualis 10 ... :(
I know GBFS for a while, I greatly use it in some GBA code, but with the NDS, it's not as easy to use this simple but great piece of code :)
So, does anyone succeed with it ?

xf

PS: Yes, I've thought to padbin the .nds file... ;)

#49856 - tepples - Wed Aug 03, 2005 12:38 am

If you want to use emulators that accept only .nds files, use the bin2s method or the objcopy method. Appending currently does not work with .nds files.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#49861 - doublec - Wed Aug 03, 2005 1:24 am

xflash, use dsemu 0.4.5. It definitely works with gbfs appended to an nds file. This is how I got the screenshot of space invaders on the dsemu page.

#49866 - tepples - Wed Aug 03, 2005 2:12 am

Was space invaders compiled with devkitARM r14? The link script changed between older devkitARM and newer devkitARM such that now the ARM9 .bss section overwrites the appended GBFS file.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#49868 - doublec - Wed Aug 03, 2005 2:52 am

The gbfs is appended to the nds which is located in cartridge ROM space so it works fine. If I had appended it to the arm9 binary then there would definitely be problems.

I confess I didn't recompile space invaders with r14 but I did redo the filesystems tutorial for r14 and it worked fine. They use the same technique.

#49869 - tepples - Wed Aug 03, 2005 2:58 am

doublec wrote:
The gbfs is appended to the nds which is located in cartridge ROM space so it works fine.

Then it's not really a *.nds file but just a piece of a *ds.gba file. For instance, if you WMB'd it to a DS with FlashMe, it wouldn't work, right?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#49875 - cory1492 - Wed Aug 03, 2005 4:21 am

I'm beginning to think there is something really messed up with something in DKarm R14/4.01 editions, should I actually be looking for a workaround for my problem with pallette getting messed up instead of seeking the cause of the change and adjustments I could make? So confusing as it still compiles and works great under R13 (even with additional padding).

Problem being: even once the nds is padded and the file loads in DualiS (and on hardware) the pallette under bins compiled with R14 does not seem to be correct anymore (blue/pink instead of black/white), is it possible that the const char array is being overwrittern somewhere along the way?

edit:/ ( a link to the unmodded code I am having problems with (from josath) can be found here. once compiled under R14, and padding is added, it runs but it seems like the pallette is no longer correct - under DualiS you must hit right before you will see anything if you are on a CRT. From the source a "padbin 256 build/subPixelFont.bin" must be added just before the first cat command in the buildROM.sh or it will just crash)

Last edited by cory1492 on Wed Aug 03, 2005 4:31 am; edited 1 time in total

#49877 - doublec - Wed Aug 03, 2005 4:30 am

tepples, correct the approach of appending to the nds file does not work when it is not stored on a flash cartridge. WMB only sends the ARM7 and ARM9 binaries, not the entire NDS.

For WMB support, as long as the appended data is less than 4MB (plus the size of the ARM9 of course) it is better to link the data in using objcopy to convert it, bin2s or something similar.