wraggster
June 26th, 2008, 22:11
Hi, along the release of the new 2.0 version of my EFS lib, I've decided to create a whole new post as the 10 pages old one has became quite hard to find information inside and because it now mostly contains outdated info.
What is the EFS Lib?
EFS (Embedded File System) is a new set of library / tools to manage files embedded within a NDS binary, like graphic / music / sound / config data, for example.
Basically, it’s an appended file system like the old GBFS, but it has many more features and less limitations. It's also more standard, as it makes use of the NitroFS, using ndstool.
What are the most important features of EFS Lib?
- It works on all slot-1 & 2 cards via DLDI patching, but also on GBA carts
- It also works on emulators without any changes in the code
- The NDS file path in the card is autodetected and stored within NDS, using unique ID generated by the EFS patcher. The file path is searched only on the first launch, and if the file has moved.
- Support reading & writing file support [writing only works using DLDI]. For writing, space must be already allocated.
- It has a complete devoptab integration, so it works the same way as libfat using standard C I/O functions.
- It's very fast, and opening a file is way faster than with libfat
How can the EFS Lib be useful for me?
- You can store all the data (gfx, sfx, music, texts, scripts..) used by your project inside one tidy .nds
- You can use way more than 4Mo of data in your program because the data stored inside the EFS is not loaded in RAM when your homebrew is loaded.
- You can use it to retrieve the current path of you NDS to avoid the root bloating problem, and write external data in a relative path.
- You can use it to test on emulators your existing programs that use libfat without changing anything and using complicated FCSR method, just init EFS as the default device, put your data in the efsroot folder and you're done
etc etc ;)
Can you tell me more about the retrieval of current path?
On compile time, space is allocated in your homebrew to store its current path, its unique ID and file size. File size and unique ID is filled by the EFS patcher, usually just after compilation in the makefile.
On the first launch, the file is quickly searched on whole card, for a match of the stored file size and ID. Once the file is found, its current path is written inside the file itself. The next time the homebrew is launched, this path is checked to verify if the file match ID & file size: if it's the case, to need to search for the file again, we're good, otherwise it means that the file has moved then we go through the search again.
Q: But as argv is already supported by DKA to provide the current path, isn't your search method obsolote?
A: Yes, but for now, no existing homebrew loader makes use of that feature. But fortunately, when this will be supported, you'll just have to provide this path as an argument on EFS init, and instead of searching the card, EFS will check the path provided. So you don't have to worry of future problems with using EFS lib, it's already future-proof :)
http://forum.gbadev.org/viewtopic.php?t=15726
What is the EFS Lib?
EFS (Embedded File System) is a new set of library / tools to manage files embedded within a NDS binary, like graphic / music / sound / config data, for example.
Basically, it’s an appended file system like the old GBFS, but it has many more features and less limitations. It's also more standard, as it makes use of the NitroFS, using ndstool.
What are the most important features of EFS Lib?
- It works on all slot-1 & 2 cards via DLDI patching, but also on GBA carts
- It also works on emulators without any changes in the code
- The NDS file path in the card is autodetected and stored within NDS, using unique ID generated by the EFS patcher. The file path is searched only on the first launch, and if the file has moved.
- Support reading & writing file support [writing only works using DLDI]. For writing, space must be already allocated.
- It has a complete devoptab integration, so it works the same way as libfat using standard C I/O functions.
- It's very fast, and opening a file is way faster than with libfat
How can the EFS Lib be useful for me?
- You can store all the data (gfx, sfx, music, texts, scripts..) used by your project inside one tidy .nds
- You can use way more than 4Mo of data in your program because the data stored inside the EFS is not loaded in RAM when your homebrew is loaded.
- You can use it to retrieve the current path of you NDS to avoid the root bloating problem, and write external data in a relative path.
- You can use it to test on emulators your existing programs that use libfat without changing anything and using complicated FCSR method, just init EFS as the default device, put your data in the efsroot folder and you're done
etc etc ;)
Can you tell me more about the retrieval of current path?
On compile time, space is allocated in your homebrew to store its current path, its unique ID and file size. File size and unique ID is filled by the EFS patcher, usually just after compilation in the makefile.
On the first launch, the file is quickly searched on whole card, for a match of the stored file size and ID. Once the file is found, its current path is written inside the file itself. The next time the homebrew is launched, this path is checked to verify if the file match ID & file size: if it's the case, to need to search for the file again, we're good, otherwise it means that the file has moved then we go through the search again.
Q: But as argv is already supported by DKA to provide the current path, isn't your search method obsolote?
A: Yes, but for now, no existing homebrew loader makes use of that feature. But fortunately, when this will be supported, you'll just have to provide this path as an argument on EFS init, and instead of searching the card, EFS will check the path provided. So you don't have to worry of future problems with using EFS lib, it's already future-proof :)
http://forum.gbadev.org/viewtopic.php?t=15726