#49570 - Extreme Coder - Sun Jul 31, 2005 12:53 pm
Hi. As most of you know, ndslib was deleted and the one to continue being updated is libnds, as said on www.drunkencoders.com.
I was using the ndsdev 2.4.0 setup(Devkitarm r12 +ndslib) and it was working fine with gbfs. Lately I deleted ndsdev, and made the environment on my own, using devkitarm r14 and the latest libnds from cvs. I used the same code I was using on the old setup to load gbfs file, but it didn't work. I finished every aspect in the program, I need to fix this before the neoflash compo deadline! If you could please solve my problem, I would be grateful.
If you need the gbfs file loading code, I could show it. But its the same as the one in doublec gbfs tutorial.
Thanks in advance,
Extreme Coder
#49595 - tepples - Sun Jul 31, 2005 7:40 pm
In one of the more recent devkitARM revisions, the ARM9's .bss segment (used for uninitialized variables) was moved to EWRAM. If you have appended a GBFS file to the ARM9 binary, .bss will overwrite the GBFS file, causing find_first_gbfs_file() to fail. Use bin2s to turn your GBFS file into a .s file that you can compile into your project.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49598 - dovoto - Sun Jul 31, 2005 7:53 pm
Or just drop the file into your 'data' directory and it will get automagicaly imported into your project (assuming you are using one of the more common template makfiles for libnds)
_________________
www.drunkencoders.com
#49653 - Extreme Coder - Mon Aug 01, 2005 8:24 am
But what if I want to append the file to the .nds/.ds.gba binary after compiling it?
#49674 - wintermute - Mon Aug 01, 2005 4:13 pm
| Extreme Coder wrote: |
| But what if I want to append the file to the .nds/.ds.gba binary after compiling it? |
Then everything should be working fine.
Bear in mind that appending a gbfs in this way will not work when using wmb and currently you'll need to find some way of determining where your gbfs file is when using a multiloader.
#49697 - Extreme Coder - Mon Aug 01, 2005 7:55 pm
| wintermute wrote: |
| Extreme Coder wrote: | | But what if I want to append the file to the .nds/.ds.gba binary after compiling it? |
Then everything should be working fine.
Bear in mind that appending a gbfs in this way will not work when using wmb and currently you'll need to find some way of determining where your gbfs file is when using a multiloader. |
That's the problem I spoke of in the beginning of this thread. In my project, I used to append the file after compiling the .nds/.ds.gba binary.
It worked using the ndsdev setup, but now using the new setup, it doesn't read the appended gbfs file.
This is what the problem is all about. If you can, can you provide me with an example that WORKS with devkitarm r14 and the latest libnds.
Thanks,
Extreme Coder
#49698 - josath - Mon Aug 01, 2005 8:06 pm
Maybe you need to pad the .nds or .ds.gba before you append the gbfs? Sometimes they expect it to be a multiple of 256 bytes or something, to speed up searching for it.
#49716 - doublec - Mon Aug 01, 2005 11:30 pm
Josath has it right. In devkitpro r14 you definitely need to padbin the binary:
| Code: |
gbfs_demo1.nds: arm7.bin arm9.bin sounds.gbfs
ndstool -c gbfs_demo1.nds -9 arm9.bin -7 arm7.bin
padbin 256 gbfs_demo1.nds
|
(from http://www.double.co.nz/nintendo_ds/nds_develop6.html)
#49721 - cory1492 - Tue Aug 02, 2005 12:07 am
Josath: have you tried to compile your ebook sample on R14? when padded it works, but very, very strangely... none of the text seems to be the correct color (yes, I know this is not gbfs, but still, a similar method of searching for a root entry, and the ebook txt is appeneded at the end of the nds)
I have tried everything I was able to think of (even the 4.01 toolchain, which nets the same results with ultra tiny binaries) aside from moving on to gbfs to get it to work out proper, I havent been able to reason out what the change was that is causing it (the pallette data, I'm assuming, since changing the 6th member of the first array is the only change that seems to make any difference ) to work differently now (especially since subpixel font still works fine).
file padding should fix your FS right up E.Coder, all I was able to get was crashes without it on mine. (just so everyone knows padbin appears to be included with devkitARM )
#49931 - Sausage Boy - Wed Aug 03, 2005 7:53 pm
I've struggled with gbfs for a week or something now, and no worky.
I'm converting data.gbfs to data.s with bin2s, and putting data.s in gfx so it gets compiled in (It echo's the filename when I make).
I figure there must be something wrong with my code, but I can't figure out what it is... :(
| Code: |
extern const GBFS_FILE *data_gbfs;
u32 desert_size = 0;
u8* desert = (u8*)gbfs_get_obj(data_gbfs, "desert.txt", &desert_size);
consolePrintf("\n\n\tHello DS devers\n");
consolePrintf("\twww.drunkencoders.com\n\n\n");
consolePrintf("%x\n\n", desert_size);
u32 curpos=0;
while(curpos!=desert_size)
{
consolePrintf("%c", desert[curpos]);
curpos++;
}
|
That's obviously not the whole thing, but I figured the rest wasn't important.
Anyways, it's supposed to print the contents of desert.txt, but it only prints the Drunken Coders stuff.
Please, help!
_________________
"no offense, but this is the gayest game ever"
#49934 - tepples - Wed Aug 03, 2005 8:17 pm
Does it print the size? If so, try printing the address so that I can help you further. If it does not print the size, then there is likely a bug in consolePrintf().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#49935 - Sausage Boy - Wed Aug 03, 2005 8:20 pm
It doesn't print the size.
Do you have any better ideas for debugging it?
_________________
"no offense, but this is the gayest game ever"
#49937 - jmva16 - Wed Aug 03, 2005 8:23 pm
When you check to see if it is printing the size, make sure you do something like %08X in your printf. This will force it to print at least 8 characters. Otherwise, if the size is zero, it will not print anything.
#49942 - Sausage Boy - Wed Aug 03, 2005 8:32 pm
The size does indeed seem to be 0...
Must be because it's not opening the file properly.
Update:
It seems to find the filesystem, but not the file...
When I print the address to data_gbfs, I get some value that looks good.
The other pointer points to 0.
lsgbfs gives me
17 desert.txt
_________________
"no offense, but this is the gayest game ever"
#49955 - doublec - Wed Aug 03, 2005 11:35 pm
Try printing the 'desert' address. It's possible that it's zero and therefore not finding the file you are looking for.
#49962 - GPFerror - Thu Aug 04, 2005 12:13 am
check your Makefile - I just finally got gbfs working, problem for me was in my Makefile
I had
ARCH := -mthumb -mthumb-interwork
I changed it to
ARCH := -mthumb-interwork
and I can now add roms to my neopop port at least its working withing DSemu
Troy
here is my code
| Code: |
WAIT_CR &= ~0x80;
GBFS_FILE const* gbfs_file =
find_first_gbfs_file((void*)0x08000000);
// int n=gbfs_count_objs(gbfs_file);
unsigned int length = 0;
strcpy( (char *)rom.filename, "Snake.npc" );
//char* name;
// NP_rom_file* file = TheRom;
// printdbg(file->filename);
//uint8* ROM=*rom.data;
rom.data = (uint8*)gbfs_get_obj(gbfs_file, (char *)rom.filename, &length);
rom.length=length;
//rom.data = (_u8 *)calloc(rom.length, 1);
sprintf(tmp,"%s - %d\n",rom.filename,rom.length);
consolePrintf(tmp);
WAIT_CR |= 0x80; |
command line to build my gbfs
| Code: |
| /c/devkitPro/devkitARM/bin/gbfs rom.gbfs rom/Snake.npc |
and here is my CreateROM.sh file
| Code: |
padbin 256 NdsPop.nds
cat NdsPop.nds rom.gbfs >NdsNeoPop.nds
cat ndsmall.bin NdsNeoPop.nds > NdsNeoPop.nds.gba |
#49971 - wintermute - Thu Aug 04, 2005 2:06 am
the architecture should have no effect on appended data.
#49998 - Sausage Boy - Thu Aug 04, 2005 1:03 pm
It seems like printing data_gbfs gives me the first 4 bytes of the gbfs header, PinE.
Is it supposed to be that way? Isn't it supposed to print the address to those? I tried calling gbfs_get_obj with &data_gbfs, but that gave me a compiler error.
I've also viewed the .nds in a hex editor, and the filesystem is in there.
Ok, I made it work, here's how I did it:
I used bin2s on the filesystem, and put that in the data directory, so it's included.
I then used this little piece of code:
| Code: |
extern const GBFS_FILE *data_gbfs;
const GBFS_FILE *data;
data = (GBFS_FILE*)&data_gbfs;
|
For some reason, data_gbfs contained the filesystem or something, and I needed a pointer, so I made another pointer. It works, anyways. :P
Note that this is for WiFi and not for cartridges.
I didn't need the arch change GPFerror posted.
_________________
"no offense, but this is the gayest game ever"
#50015 - tepples - Thu Aug 04, 2005 4:07 pm
| Sausage Boy wrote: |
It seems like printing data_gbfs gives me the first 4 bytes of the gbfs header, PinE.
Is it supposed to be that way? |
No.
| Quote: |
I then used this little piece of code:
| Code: |
extern const GBFS_FILE *data_gbfs;
|
|
There's your problem. Change it to this:
| Code: |
extern const GBFS_FILE data_gbfs;
|
Take the star out, and the rest should work.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#50017 - Sausage Boy - Thu Aug 04, 2005 4:19 pm
Thanks tepples. That was a slightly less complicated solution. :D
I also needed to change
desert = (char*)gbfs_get_obj(data_gbfs, "desert.txt", &desert_size);
to
desert = (char*)gbfs_get_obj(&data_gbfs, "desert.txt", &desert_size);
Sweet.
_________________
"no offense, but this is the gayest game ever"
#50023 - GPFerror - Thu Aug 04, 2005 4:54 pm
yeah Im guessing I just had to make the arch change to get it to work in dsemu.
The resulting file doesnt seem to work over wmb though, I think the issue with the toolkit r14 globals and mallocs overwriting the gbfs is my problem on hardware, maybe it would work from a flashcart?
For personal use I can use the bin2s method, but it would require others to have a dev setup to use my ported emulator to add roms, so they could run bin2s on their roms and rebuild, not exactly the easiest solution right now :)
Kind of in a catch-22 situation, I can't build the code with earlier toolkits and gbfs doesnt work the way I need it to for users adding there own roms.
Is there a work around, how does the snes emulator work for users adding there own roms?
thanks
#50028 - tepples - Thu Aug 04, 2005 6:05 pm
| GPFerror wrote: |
| The resulting file doesnt seem to work over wmb though, I think the issue with the toolkit r14 globals and mallocs overwriting the gbfs is my problem on hardware, maybe it would work from a flashcart? |
It probably would.
| Quote: |
| For personal use I can use the bin2s method, but it would require others to have a dev setup to use my ported emulator to add roms, so they could run bin2s on their roms and rebuild, not exactly the easiest solution right now :) |
They'd have to have bin2s and binutils, but not gcc.
| Quote: |
| Is there a work around, how does the snes emulator work for users adding there own roms? |
You could make a 2 MB empty GBFS file, bin2s that into your game, and then have your injector copy the user's GBFS file on top of that byte region in your file.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#50073 - wintermute - Fri Aug 05, 2005 12:37 am
the latest libnds now contains gbfs, there is also an example of embedding a filesystem.
http://devkitpro.sourceforge.net
I'll probably work up an example of an appended filesystem later. Bear in mind that data appended to the nds file will only work from cart and not over wifi. As Tepples just mentioned the best way to handle that case is probably to embed a dummy filesystem & write some code to overwrite it.
#50131 - ChronoDK - Fri Aug 05, 2005 7:11 pm
An example of that last case (filesystem for wifi) would be nice too.
#50143 - GPFerror - Fri Aug 05, 2005 11:23 pm
| tepples wrote: |
| You could make a 2 MB empty GBFS file, bin2s that into your game, and then have your injector copy the user's GBFS file on top of that byte region in your file. |
thanks, that worked great.
I couldnt find an injector anywhere so I wrote a quickone.
It includes a windows commandline tool and the sourcecode.
get it from my site http://gpf.dcemu.co.uk
its called gbfsinject.rar under utilities on the left menu.
for some reason the direct link is not working right now
http://gpf.dcemu.co.uk/files/pc/gbfsinject.rar
usage:
gbfsinject Ndsfile.nds Gbfsfile.gbfs Out.nds
Simple utility that looks for the string "PinEightGBFS" and injects the Gbfsfile.gbfs from that location, so make sure the the new gbfs file is not larger than the existing embedded gbfs.
Troy Davis(GPF)
http://gpf.dcemu.co.uk
#50160 - tepples - Sat Aug 06, 2005 2:57 am
| GPFerror wrote: |
usage:
gbfsinject Ndsfile.nds Gbfsfile.gbfs Out.nds
Simple utility that looks for the string "PinEightGBFS" and injects the Gbfsfile.gbfs from that location, so make sure the the new gbfs file is not larger than the existing embedded gbfs. |
Does your program check to see that the file being replaced (empty.gbfs inside Ndsfile.nds) is at least as large as the file you're replacing it with (Gbfsfile.gbfs)? That should be easy, given that GBFS files store their length in a part of the structure for use with skip_gbfs_file().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#50177 - GPFerror - Sat Aug 06, 2005 6:40 am
| tepples wrote: |
| Does your program check to see that the file being replaced (empty.gbfs inside Ndsfile.nds) is at least as large as the file you're replacing it with (Gbfsfile.gbfs)? That should be easy, given that GBFS files store their length in a part of the structure for use with skip_gbfs_file(). |
Not in this version, it was just a quick hack, so I could test it would work for my application. Hence the caveat. "make sure the the new gbfs file is not larger than the existing embedded gbfs." :)
But based on your comments, I started actually looking through the gbfs's code :) So maybe if I get a chance Ill hack something new up later.
Troy