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 > gbfs won't work on the hardware.

#130871 - BovineFury - Fri Jun 08, 2007 10:50 pm

I recently added gbfs support to my project. Everything works fine in the emulator, but all I get are white screens when running on the hardware. I tried reverting to a earlier project and used gbfs for one file. The results were exactly the same. No problems on the emulator but nothing runs on the hardware.

The steps I use to setup the file system are as follows:

gbfs filesystem.gbfs *.raw *.pal
padbin 256 game_code.nds
cat game_code.nds filesystem.gbfs >Voltz_DS.nds

Does anybody have an idea about what is happening?

#130872 - NeX - Fri Jun 08, 2007 10:55 pm

I can tell you now I have never had to do anything like that.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

#130876 - josath - Fri Jun 08, 2007 11:10 pm

Appended gbfs is incompatible with ALL slot-1 devices, as well as GBAMP and Supercard Rumble. You haven't told us what device you are using, but my guess is one of the unsupported ones. Either way, it's not recommended to use appended gbfs, because then many people cannot use your app (unless you provide two versions)

#130877 - NeX - Fri Jun 08, 2007 11:16 pm

Well, I have an EFA-Linker which I use embedded GBFS with. I find it hard to go over 4MB without sounds/music.
_________________
Strummer or Drummer?.
Or maybe you would rather play with sand? Sandscape is for you in that case.

#130878 - BovineFury - Fri Jun 08, 2007 11:24 pm

>> josath

That would be the problem. Thanks a lot.

#131474 - gyokimae - Sat Jun 16, 2007 1:22 am

I've been struggling with the same problem until reading this post. ( I use a R4)

For applications launched from slot1, are there any alternatives to GBFS for storing data out of the main 4MB RAM and yet have everything in a single file?

#131476 - tepples - Sat Jun 16, 2007 1:52 am

gyokimae wrote:
For applications launched from slot1, are there any alternatives to GBFS for storing data out of the main 4MB RAM and yet have everything in a single file?

No, not at least until devkitARM, libnds, and .nds loaders gain support for argv[0].
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131490 - felix123 - Sat Jun 16, 2007 4:38 am

gyokimae wrote:
For applications launched from slot1, are there any alternatives to GBFS for storing data out of the main 4MB RAM and yet have everything in a single file?

Can you do this with EFS Lib?
_________________
Nintendo DS homebrew on Wikipedia

#131506 - MrD - Sat Jun 16, 2007 2:35 pm

gyokimae wrote:
I've been struggling with the same problem until reading this post. ( I use a R4)

For applications launched from slot1, are there any alternatives to GBFS for storing data out of the main 4MB RAM and yet have everything in a single file?


Why would you want to do this?
_________________
Not active on this forum. For Lemmings DS help see its website.

#131510 - gyokimae - Sat Jun 16, 2007 4:38 pm

Quote:
Why would you want to do this?

My understanding is that unless you store data in the GBFS or FAT area of the .nds file, the binary must be less than 4MB which is the total size of main memory.

Please correct me if I am wrong.

#131515 - zeruda - Sat Jun 16, 2007 7:02 pm

GBFS works fine for me on my R4. Why do people say it's incompatile with slot-1 devices?

#131520 - tepples - Sat Jun 16, 2007 9:09 pm

zeruda wrote:
GBFS works fine for me on my R4. Why do people say it's incompatile with slot-1 devices?

Does appended GBFS work on SLOT-1 or GBAMP? Sure, you can load a GBFS file into RAM, or you can load objects from a GBFS, but then how does a program find its GBFS file?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131532 - gyokimae - Sat Jun 16, 2007 11:43 pm

Following tutorials, I've padded the original .nds file and
cat original.nds images.gbfs > final.nds
Is this what could be called appended GBFS?

Only from trying have I figured out that gbfs_get_obj() returns a file size of zero while all worked as I expected on NO$GBA.

#131534 - tepples - Sun Jun 17, 2007 12:16 am

gyokimae wrote:
Following tutorials, I've padded the original .nds file and
cat original.nds images.gbfs > final.nds
Is this what could be called appended GBFS?

Yes. It does not work on SLOT-1.

Quote:
Only from trying have I figured out that gbfs_get_obj() returns a file size of zero while all worked as I expected on NO$GBA.

How are you calling it?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131539 - gyokimae - Sun Jun 17, 2007 2:17 am

Quote:
How are you calling it?


I don't have the code on hand as I have been sandboxing with one .c file and not leaving prior versions.
However I do believe I wasn't doing anything obscure.

Running
gbfs_get_obj(targeToStore, "fileNameToLoad", sizeOfFile)

I would then iprintf() the sizeOfFile to console.

Under NO$GBA, the sizeOfFile is returned properly and
I have not trouble manipulating loaded data.

On the real machine, printing sizeOfFile shows zero and
accessing the loaded data gives me a black screen which
I guess is an internal crash.


I hope this response is not too obvious to tepples.
Maybe this is all cheese cake to those who know the background
enough to understand the deal about certain loaders being able
to access argv[0]. I am not yet fluent with the architecture
and which parts of the library are more likely "workarounds"
designed by unofficial developpers.

#131555 - tepples - Sun Jun 17, 2007 8:18 am

gyokimae wrote:
On the real machine, printing sizeOfFile shows zero and
accessing the loaded data gives me a black screen which
I guess is an internal crash.

What is the return value from find_first_gbfs_file() ? Are you making sure to red-screen if it returns 0? It's possible that NO$GBA emulates a SLOT-2 card, not a SLOT-1 card.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131571 - Lick - Sun Jun 17, 2007 2:11 pm

gyokimae wrote:
Quote:
Why would you want to do this?

My understanding is that unless you store data in the GBFS or FAT area of the .nds file, the binary must be less than 4MB which is the total size of main memory.

Please correct me if I am wrong.

That doesn't mean you have to store everything in ONE file. Just use FAT and drop archiving.
_________________
http://licklick.wordpress.com

#131575 - tepples - Sun Jun 17, 2007 2:52 pm

Lick wrote:
Just use FAT and drop archiving.

And watch internal fragmentation bloat your assets by an order of magnitude when a unit with 16x16 pixel 4-bit sprite cels and 16 frames of animation (16*16*4/8*16 = 2048 bytes) takes 16384 bytes on a 1 GB card due to FAT's lack of tail packing and the SuperCard menu's limit of 65,500-some clusters per volume.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131581 - Lick - Sun Jun 17, 2007 3:16 pm

tepples wrote:
Lick wrote:
Just use FAT and drop archiving.

And watch internal fragmentation bloat your assets by an order of magnitude when a unit with 16x16 pixel 4-bit sprite cels and 16 frames of animation (16*16*4/8*16 = 2048 bytes) takes 16384 bytes on a 1 GB card due to FAT's lack of tail packing and the SuperCard menu's limit of 65,500-some clusters per volume.

Just use FAT and drop archiving.
_________________
http://licklick.wordpress.com

#131583 - tepples - Sun Jun 17, 2007 3:20 pm

Lick wrote:
tepples wrote:
Lick wrote:
Just use FAT and drop archiving.

And watch internal fragmentation bloat your assets by an order of magnitude when a unit with 16x16 pixel 4-bit sprite cels and 16 frames of animation (16*16*4/8*16 = 2048 bytes) takes 16384 bytes on a 1 GB card due to FAT's lack of tail packing and the SuperCard menu's limit of 65,500-some clusters per volume.

Just use FAT and drop archiving.

You said that already. What did you mean by repeating it?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131616 - gyokimae - Sun Jun 17, 2007 11:26 pm

FAT will probably work just fine for games&apps I write for myself.

Again, please correct me if I am wrong...

In order to access external files, different methods must be applied depending on the card you use... correct?

And in order to overcome this, either I must provide multiple binaries supporting different cards, or else I the user needs to apply a DLDI patch on their end after downloading... correct? (I currently understand that that is the whole purpose of the DLDI libraries)

Since the data I want to use is static, it would be a lot niftier if I could have them download a single file that contained all data.

#131618 - tepples - Mon Jun 18, 2007 1:34 am

gyokimae wrote:
please correct me if I am wrong...

In order to access external files, different methods must be applied depending on the card you use... correct?

Yes, but DLDI hides this all.

Quote:
And in order to overcome this, either I must provide multiple binaries supporting different cards, or else I the user needs to apply a DLDI patch on their end after downloading... correct?

Right, and with the DLDI Right Click shell extension for Windows, the majority of users can just copy the .nds to the card and patch it.

Quote:
Since the data I want to use is static, it would be a lot niftier if I could have them download a single file that contained all data.

Lick would want you to have the user download a single file in PKZIP format and then unzip it to the card first.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#131619 - chuckstudios - Mon Jun 18, 2007 2:03 am

Why can't you just use EFS? It's pretty much the logical evolution of GBFS, which seems to be your ideal method.

#131673 - gyokimae - Tue Jun 19, 2007 12:16 am

chuckstudios,

Thanks for the advise.

This is probably all good for practicle use.

I guess my interest was partially on the technical aspect rather than practical, on how close the current homebrew development technology was to the designs of official roms.

Reading the code of EFS, I did get the impression that it yet relies on attaining the name of the currently launched .nds file by iterating files and directories in order to find the starting address of stored data.

For future reference, I am interested in learning if EFS is yet another method which my become deprecated or require additions when future changes are made to the flash cards.