#159186 - Noda - Thu Jun 26, 2008 5:04 pm
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 your 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, no 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 obsolete?
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 :)
Download
EFS Library + example
EFS Patcher v1.0 + source code
Last edited by Noda on Mon Jun 30, 2008 11:18 am; edited 2 times in total
#159209 - tondopie - Fri Jun 27, 2008 12:12 am
thank you Noda!
_________________
Development Blog: http://teendev.org
Homebrew Podcast: http://homebrewcast.net
Web Design: http://xtendesign.net
#159269 - hewenxie - Sat Jun 28, 2008 1:29 pm
thanks very much! Noda.
I meet the problem,
I success load the example .nds on emulator, but failed loading on R4 and M3R. Is there need modify something?
#159290 - melw - Sat Jun 28, 2008 7:41 pm
Great stuff! Feature set includes pretty much everything one could hope for - I guess it's time for me to give EFS lib a try.
#159303 - silent_code - Sat Jun 28, 2008 11:41 pm
Noda, could you anwser this "question"?
| Quote: |
I don't know how (EFS2.0) handle(s) external files, which is important for development, as you don't want to write a big ROM file to your card every time you need to test a new version. This is even more true when sending the .nds over WiFi.
|
Do I need to write more?
Having writen that, I can only add, that I'll test EFS2.0 as soon as I get the chance to. Good job. :^)
(I hope eris isn't too upset about it. ;^) )
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159305 - kusma - Sun Jun 29, 2008 12:00 am
| silent_code wrote: |
Noda, could you anwser this "question"?
| Quote: | I don't know how (EFS2.0) handle(s) external files, which is important for development, as you don't want to write a big ROM file to your card every time you need to test a new version. This is even more true when sending the .nds over WiFi.
|
|
I know I'm not Noda, but if I've understood the lib correctly; it doesn't. If you want some more abstraction-features, you can add that yourself in your application during development-time (i.e attempting to load from efs: only if not found in fat: or something). What you're requesting isn't really a low-level file-system feature.
#159379 - SiW - Sun Jun 29, 2008 10:53 pm
If I'm not mistaken, the devoptab integration means opening files via libfat is transparently supported, yes?
#159399 - Noda - Mon Jun 30, 2008 7:49 am
SiW> yes, you open files with EFS just like you do with libfat.
silent_code> Simply switch from EFS to libfat, by using neutral path, ie:
"/data/mydata.txt"
then to use EFS or libfat, do at the beginning of your code chdir("efs:/"); or chdir("fat:/");
#159404 - silent_code - Mon Jun 30, 2008 10:06 am
@ Noda: That's exactly what I expected. Thanks. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159439 - silent_code - Mon Jun 30, 2008 10:44 pm
Sorry for the double post!
Do you know what size footprint EFS2.0 has compared to pure libfat?
Also, are there any known path length problems?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159449 - Noda - Tue Jul 01, 2008 8:07 am
I guess the EFS footprint is <size of libfat> + a few kb (I'm not behind my own pc so I can't quickly check, I'll tell you later).
For the limitations (most are NitroFS limitations)
- filename lenght: 127 chars
- full path lenght: 255 chars
- num of files: 61440
- num of dirs: 4096
#159450 - silent_code - Tue Jul 01, 2008 10:39 am
Thank you very much. :^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159613 - SiW - Thu Jul 03, 2008 12:58 am
| silent_code wrote: |
| @ Noda: That's exactly what I expected. |
Ditto, and thanks from me also. If I ever have time to get back to my projects I'll make full use of this :)
#159916 - oldschoolgamr - Tue Jul 08, 2008 6:22 am
I managed to get EFS V1 working - but want to move to V2 so my project will work on emulators...
How do I do the following with the new version??? Thanks for any help in advance - long live the homebrew!
FIRST - I initiate EFS (emu's return "FAT failed to load" or freeze)
| Code: |
while (efsload==0) {
if(fatInitDefault()) {
if(EFS_Init()) {
PA_OutputText(1,0,0, "Loaded File System. ");
efsload=1;
}
else {
PA_OutputText(1,0,0, "EFS failed to load");
efsload=2;
}
}
else {
PA_OutputText(1,0,0, "FAT failed to load");
efsload=2;
}
} |
THEN - I read the gfx files from EFS and set up a buffer to use
| Code: |
//Opens a file and returns a pointer to its location in memory
char* open(char* location){
EFS_FILE* file = EFS_fopen(location);
char* buffer = (char*)malloc(EFS_GetFileSize(file));
EFS_fread(buffer,1,EFS_GetFileSize(file),file);
EFS_fclose(file);
PA_WaitForVBL();
return buffer;
}
char* buffer_info; //= open("/Large_Info.bin");
char* buffer_map; //= open("/Large_Map.bin");
char* buffer_tiles; //= open("/Large_Tiles.bin");
char* buffer_pal; //= open("/Large_Pal.bin"); |
Then I can fill the buffer and load any image:
| Code: |
buffer_info = open("/imageX_Info.bin");
buffer_map = open("/imageX_Map.bin");
buffer_tiles = open("/imageX_Tiles.bin");
buffer_pal = open("/imageX_Pal.bin");
tilesizenum=28032;
mapsizenum=768;
PA_EasyBgLoadEx(1,//screen
3,//bg number
(u32 *)buffer_info,//info
buffer_tiles,//tiles
(u32) tilesizenum,//tile size (this is found in all_gfx.c)
buffer_map,//map
(u32) mapsizenum,//map size (this is found in all_gfx.c)
buffer_pal);//palette |
Thanks again - hopefully someone can hold by hand through this...!
Last edited by oldschoolgamr on Tue Jul 08, 2008 1:42 pm; edited 1 time in total
#159924 - elhobbs - Tue Jul 08, 2008 12:47 pm
I am not an efs expert and you may have messed up your post, but it looks like you are saying you use efs before you initialize it. If that is so then you probably want to do the init first.
#159925 - oldschoolgamr - Tue Jul 08, 2008 1:40 pm
Oh - sorry - YES, I actually initialize it elsewhere when the program boots up so the order of the commands in the last post should be changed... I had done it a couple of different ways to allow dev bouncing during debug.
So what I really need is help making this work in V2... it works great in V1 with hardware, but not in emu...
I edited the original post to fix this confusion... EFS is initialized first... sorry.
#160016 - Michoko - Wed Jul 09, 2008 9:12 am
Well, I suppose you're almost there. The only thing to do to migrate is to use the standard C file functions (like fopen, fread, fclose...) instead of the previous specific EFS functions.
As an example, here is a function which loads a raw file into a buffer:
| Code: |
u32 EFS_GetFileSize(FILE *file) {
u32 size;
fseek(file, 0, SEEK_END);
size = ftell(file);
fseek(file, 0, SEEK_SET);
return(size);
}
// Loads a RAW file
u8* LoadMediaFile(char* name)
{
u8* buffer;
FILE* file;
u32 size
file = fopen(name, "rb");
if(file != NULL)
{
size = EFS_GetFileSize(file);
buffer = malloc(size);
fread(buffer, 1, size, file);
fclose(file);
return(buffer);
}
else
{
return(NULL);
}
}
|
Good luck
Michoko
#160021 - Bernie - Wed Jul 09, 2008 12:02 pm
I've been trying to get EFSlib 2.0 to work with PAlib. Using a makefile from an older EFSlib example for PAlib, I got it somewhat working. Something's amiss though, because EFS fails to initialise on the hardware (but works in emulators), yet the libnds example works just fine.
I think that the problem has something to do with the makefile, which I uploaded here: http://www.origamihero.com/palibmakefile.rar
I've been comparing it to the makefile in the libnds example, but it turns out that this is quite a bit beyond my abilities. What could be missing? Thanks in advance for any help.
#160057 - Zalo - Wed Jul 09, 2008 10:06 pm
Hi. Before all, congratulations for the lib, it is exactly what I was lookng for just now
I have been trying to get it work, but I can't completelly do it. Maybe is because what I am trying is not posible. I want to make an application that loads its resources included in the nds but that has an option in game to load a file from the flash card.
I can only make it work with one of the two options:
- Taking all the resources from the .nds (using chdir("efs:/"))
- Taking all the resources from the flash card (using chdir("fat:/"))
The problem is with the initialization. To make it work loading from efs I have to do
| Code: |
| EFS_Init(EFS_AND_FAT | EFS_DEFAULT_DEVICE, NULL); |
But to make it work from the flash card I have to write this
| Code: |
fatInitDefault();
EFS_Init(EFS_ONLY | EFS_DEFAULT_DEVICE, NULL); |
Otherwise it won't work.
Anyway maybe It's something weird with the way I compile because I still have to use devKitArm_r20, with r_23 I can't list directories
Those something like that only happening to me?
Can anybody try to write a mixed application reading both from the .nds and from the flash card? I'll really appreciate it ;)
Anyway, thanks for the lib it is wonderful!
_________________
-----
Zalo
#160062 - Bernie - Wed Jul 09, 2008 10:47 pm
Zalo: Hey, thanks! :) By the way, I've found another way, too:
The makefile line 'include $(DEVKITARM)/ds_rules' caused efslib not to work for me on slot 1 cards, but replacing it with 'include $(DEVKITARM)/base_rules' works without the need for using EFS_ONLY. Strange.
Anyway, EFSlib 2.0 is awesome and works great! :D
#160111 - ChronoDK - Thu Jul 10, 2008 3:57 pm
How do I append the efsroot folder to my .nds file?
I'm guessing the example does it through the makefile, but I'm not sure which lines I'm supposed to transfer to my own makefile. Maybe it can be done using command line stuff as well?
EDIT: Looks like I fixed it by adding "-d ./efsroot" to the ndstool command in the makefile.
#160130 - Polaris - Thu Jul 10, 2008 7:28 pm
This lib sounds really neat and from everyone's comments it seems like it is plain awesome, I got one problem though.
I don't understand squat about Makefiles :P If I'm using the arm9 Makefile that comes with devkitARM, what do I need to add and where to have this working?
#160137 - ChronoDK - Thu Jul 10, 2008 8:57 pm
As I noted above, I just added -d ./efsroot to the ndstool command in the makefile. That's line 25 when using the combined template from the libnds examples.
#160140 - silent_code - Thu Jul 10, 2008 9:10 pm
@ Polaris: Read tonc, it includes a small section on makefiles. Or browse any university's computer science site and download some slides. :^)
You could also read "propper" material about make, like the manual or documentation, of course. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#160147 - Polaris - Thu Jul 10, 2008 10:13 pm
I'll have to read on some of that sooner or later. But not right now :)
After staring at the Makefiles for a while I think I got what needed to be copy and pasted, the combined Makefile is slighlty different to the separate ones, I guess because nothing needs to be merged. Everything went just right but a couple of messages caught my attention in the output window of Visual Studio.
The first which I think I should be worrying about says: "blablabla.nds does not have an EFS section" that sounds troublesome, maybe it has something to do with not trying to Initialize the lib? I hope so.
The second I think, might just be a mistake, it reads "*** Embedded File System ID patch tool v1.0 by Noda". The zip file states pretty clearly that it's v2.0, probably just an inconsecuential mistake.
#160171 - kiswa - Thu Jul 10, 2008 11:54 pm
As I understand it, the library is V2.0 and the patcher is V1.0!
Speaking of which, I have not yet figured out how to compile the patcher for use in Linux. Anyone help with that?
I'm trying to figure out how to make the makefile for it to compile in Linux, but that may take me a while....
EDIT: Of course, I was being too complicated. A simple "make efs" worked just fine. :|
#160257 - Polaris - Sat Jul 12, 2008 11:37 pm
Turns out that line saying there was no EFS section on my .nds was there because I didn't initialised EFS. So I got everything working, after all it was just initializing EFS instead of libFat, no biggie.
I did noticed a couple of strange things in my working demo.
The first, the files that I read using libFat weren't read properly by EFS, the program did managed to show the sprite but the colors were all screwed up. Using grit on the images again and using brand new, just like the last binary files, with no changes in the code got me correct results. It was nice that for once one of my ilogic solutions actually worked, but it still was pretty strange.
The second thing that just happened is that when I tried the .nds on hardware the sprite showed up, but with missing colors, the ones that were in place were ok though. I turned off my DS and tried loading the .nds again and the sprite was there in perfect form. Again, strange behaiviour.
Any info on what might be happening?
#160266 - tepples - Sun Jul 13, 2008 2:28 am
Might the problem with colors have something to do with unaligned memory accesses?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#160360 - ChronoDK - Mon Jul 14, 2008 3:53 pm
My demo is only working in DeSmuME - not in No$GBA and not on hardware when using GBA Movie Player CF. All I get is a black screen.
Any idea what could be causing this?
#160365 - silent_code - Mon Jul 14, 2008 4:21 pm
That's very little information, ChronoDK. No time for guesses atm.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#160375 - ChronoDK - Mon Jul 14, 2008 6:09 pm
Sorry about that - I can of course show the code I'm using.
| Code: |
EFS_Init(EFS_ONLY | EFS_DEFAULT_DEVICE, NULL);
/*videoSetModeSub(MODE_5_2D | DISPLAY_BG0_ACTIVE);
vramSetBankC(VRAM_C_SUB_BG);
SUB_BG0_CR = BG_MAP_BASE(31);
BG_PALETTE_SUB[255] = RGB15(31,31,31);
consoleInitDefault((u16*)SCREEN_BASE_BLOCK_SUB(31), (u16*)CHAR_BASE_BLOCK_SUB(0), 16);
//Filestream
std::ifstream infile;
infile.open( "list_NPCs.txt" );
std::string str = "";
while ( std::getline(infile, str) ) {
std::cout << str;
}*/
lcdMainOnBottom();
videoSetMode( MODE_5_2D | DISPLAY_BG0_ACTIVE | DISPLAY_SPR_ACTIVE | DISPLAY_SPR_1D ); //Main screen uses mode 5 with sprites and one BG active
videoSetModeSub( MODE_5_2D | DISPLAY_BG0_ACTIVE ); //Sub screen has the same configuration
vramSetBankA(VRAM_A_MAIN_BG); //1 x 128kb for main background
vramSetBankB(VRAM_B_MAIN_SPRITE); //1 x 128kb for main sprites
vramSetBankC(VRAM_C_SUB_BG); //1 x 128kb for sub background
BG0_CR = BG_32x32 | BG_COLOR_256 | BG_MAP_BASE(0) | BG_TILE_BASE(1);
SUB_BG0_CR = BG_32x32 | BG_COLOR_256 | BG_MAP_BASE(0) | BG_TILE_BASE(1);
//The address of the tile and map blocks
u8* tileMemoryMain = (u8*)BG_TILE_RAM(1);
u16* mapMemoryMain = (u16*)BG_MAP_RAM(0);
u8* tileMemorySub = (u8*)BG_TILE_RAM_SUB(1);
u16* mapMemorySub = (u16*)BG_MAP_RAM_SUB(0);
//Read BG0 palette file to memory
std::ifstream infile( "mainmenu_BG0_MAIN.pal.bin", std::ifstream::binary );
infile.read((char*)BG_PALETTE, 256 * 2);
infile.close();
infile.clear();
//Read BG0 tiles from file to tile memory
infile.open( "mainmenu_BG0_MAIN.img.bin", std::ifstream::binary );
infile.seekg(0, std::ifstream::end);
long size = infile.tellg();
infile.seekg(0);
infile.read((char*)tileMemoryMain, size);
infile.close();
infile.clear();
//Read BG0 map from file to map memory
infile.open( "mainmenu_BG0_MAIN.map.bin", std::ifstream::binary );
infile.read((char*)mapMemoryMain, 32 * 32 * 2);
infile.close();
infile.clear();
|
With the above code, all I get is a black screen on hardware and no$gba - it works in desmume. The code that is commented out works just fine in no$gba as well - it prints a lot of text from that file - but it does not work on hardware either.
#160407 - ChronoDK - Tue Jul 15, 2008 8:55 am
Hmm, the problem might not be EFS related actually. I think I'm not reading/writing stuff correctly. How and where should I use 16-bit reads/writes?
#160420 - Bernie - Tue Jul 15, 2008 1:50 pm
A quick question, if I may - is writing to files with EFS on emulators still not possible at the moment?
#160426 - silent_code - Tue Jul 15, 2008 4:33 pm
I hear it's possible, but you have to preallocate the files. I'm not sure, though.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#160455 - Polaris - Wed Jul 16, 2008 6:44 am
According to Noda's first post that's precisely what you need to do. But it also says that you need DLDI support, so I guess that leaves emulators with no file writting, am I right?
tepples: Thanks for the tip, I think I solved my problem.
#160460 - silent_code - Wed Jul 16, 2008 9:02 am
... Unless FCSR does support file writing. ;^)
(Which I don't know.)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#160478 - ChronoDK - Wed Jul 16, 2008 6:52 pm
I'm definitely doing something wrong. I can open the files and I can read strings from text files, but when I try to copy stuff to VRAM I get a black screen on hardware. Can someone see what I'm doing wrong below? And how do I fix it?
| Code: |
//Read BG0 palette file to memory
std::ifstream infile( "mainmenu_BG0_MAIN.pal.bin", std::ifstream::binary );
for (int i = 0; i < 256; i++) {
u16* x = 0;
infile.read((char*)x, 2);
BG_PALETTE[i] = *x;
}
|
#160479 - elhobbs - Wed Jul 16, 2008 7:28 pm
| ChronoDK wrote: |
I'm definitely doing something wrong. I can open the files and I can read strings from text files, but when I try to copy stuff to VRAM I get a black screen on hardware. Can someone see what I'm doing wrong below? And how do I fix it?
| Code: |
//Read BG0 palette file to memory
std::ifstream infile( "mainmenu_BG0_MAIN.pal.bin", std::ifstream::binary );
for (int i = 0; i < 256; i++) {
u16* x = 0;
infile.read((char*)x, 2);
BG_PALETTE[i] = *x;
}
|
|
x should be a buffer to read data into, you have it pointing at a null pointer. I am surprised this does not give an access violation and die. a quick hack would be | Code: |
//Read BG0 palette file to memory
std::ifstream infile( "mainmenu_BG0_MAIN.pal.bin", std::ifstream::binary );
for (int i = 0; i < 256; i++) {
u16 x;
infile.read((char*)&x, 2);
BG_PALETTE[i] = x;
}
|
#160489 - ChronoDK - Wed Jul 16, 2008 8:43 pm
Whow, newbie mistake! Thank you! Backgrounds work on hardware now. Unfortunately, sprites wont work using that method. Is there a quick hack to fix this one as well?
| Code: |
//The sprite and palette memory adresses
u16* spritePalMain = SPRITE_PALETTE;
u16* spriteMemMain = SPRITE_GFX;
//Read sprite palette file to memory
infile.open( (path + m_sprite + ".pal.bin").c_str(), std::ifstream::binary );
for (int i = 0; i < 16; i++) {
u16 x = 0;
infile.read((char*)&x, 2);
spritePalMain[i + (m_palIndex * 16)] = x;
}
infile.close();
infile.clear();
//Read sprite data from file to sprite memory
infile.open( (path + m_sprite + ".img.bin").c_str(), std::ifstream::binary );
infile.seekg(0, std::ifstream::end);
long size = infile.tellg();
infile.seekg(0);
for (int i = 0; i < size/2; i++) {
u16 x = 0;
infile.read((char*)&x, 2);
spriteMemMain[i + (m_tileIndex * 16)] = x;
}
infile.close();
infile.clear();
|
#160496 - silent_code - Wed Jul 16, 2008 8:57 pm
Random, unrelated tip:
| Code: |
uint16 *spritePalMain = &SPRITE_PALETTE[(m_palIndex * 16)];
...
for (int i = 0; i < 16; i++) {
u16 x = 0;
infile.read((char*)&x, 2);
*spritePalMain++ = x; // I am very sleepy and I don't know, if that line would cause trouble - at least not off my head and not right now. Split the increment when it doesn't work as expected.
} |
(Untested, but you sure get the idea - it should be faster.)
EDIT: Yes, there should be some dereferencing. :^D
And what exactly does not work? How do your "corrupted" sprites look like?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
Last edited by silent_code on Wed Jul 16, 2008 11:41 pm; edited 2 times in total
#160500 - DensitY - Wed Jul 16, 2008 9:41 pm
Are your source sprites in tile format already? (assuming your loading 1D tiled Sprites).
data must be stored in 8x8 tiles in 1d Tiled mode. so say you had 32x32 sprite, you'd read take the first 2 lines of that and store that in a 8x8 tile box, rince repeat (with a 32x32 sprite you'd end up with 4x4 blocks of 8x8 tiles).
#160502 - silent_code - Wed Jul 16, 2008 9:52 pm
... Or let grit export it propperly. ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#160503 - ChronoDK - Wed Jul 16, 2008 10:05 pm
So embarrassing... I forgot to remove that null pointer mistake from my animation code as well. It works now. Thanks everyone, and sorry about that...
I am using grit and 1D sprites by the way.
#160504 - DensitY - Wed Jul 16, 2008 10:08 pm
| Code: |
*spritePalMain++ = x;
|
just noticed it should of been that lolol..
#160506 - ChronoDK - Wed Jul 16, 2008 10:24 pm
Yep ;)
#160507 - Apache Thunder - Wed Jul 16, 2008 10:26 pm
EFS sounds great. I want to use this to make for example an existing NDS application access EFS instead of DLDI (aka access storage device). How do I do this?
Does this require me to edit the source code of the application I want to use this (like Moonshell for example, I want to add EFS to that).
If only adding EFS was as simple as DLDI patching a rom.
This would prove usefull since I am using the WMB app that yellowstar modded (original app made by Juglak). The rom I send to the client won't have storage device to use obvoisly since it will be in the DS's internal ram only. No other devices attached, so I would like to get that rom to be completly self-contained using EFS.
the FCSR method is the only method I know of right now that doesn't involve source code edits of the NDS program inquestion. Right now it looks like EFS is even more a mess to work with then FCSR method simply because I won't beable to compile some apps. Like Moonshell for example. Its source code is too much of a mess to recompile, so I won't beable to do any source code changes to it.
I tried the EFS patcher, but it complains about the NDS not having a "EFS Section"
Perhaps you can make a "EFS DLDI Driver" so that a DLDI capable app can access its efs area instead of the device its running on. Playing with the source code of the app is out of the question for me, since there is a lot of apps out there that won't compile without significant source code changes. I lack any programming knowledge for the DS, so this will be impossible for me.
_________________
Sig under construction...Please check back after the sun explodes....
Last edited by Apache Thunder on Fri Jul 18, 2008 10:00 pm; edited 1 time in total
#160511 - silent_code - Wed Jul 16, 2008 11:46 pm
@ AT: You should inform yourself about libfat, DLDI and EFS before setting yourself such a task. Many of your questions can be answered by the existing descriptions and FAQs. ;^)
FCSR is a DLDI driver for use with libfat, whereas EFS can be considered an alternative to libnds.
Replacing libfat with EFS isn't exactly a platform specific programming task. I believe it's rather trivial to move from libfat to EFS, especially as both can be present in a single program... ;^)
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#160518 - Apache Thunder - Thu Jul 17, 2008 4:11 am
Well it isn't trivial at all if I wanted to do this with Moonshell or DSOrganize! The source code for that uses really old devkitarm and it would be a pain to get all that to compile right and still keep the new version of DevkitARM for the modern source coded apps.
I still have no idea what version is required to compile Moonshell/DSOrganize, and as far as I know there is no place on the internet that I can even find the source code for the last version of Moonshell. (the author's homepage no longer works)
And quite frankly, its not worth finding the old version of DevkitARM and installing it along side the new one (without braking anything) just to compile a few selective apps.
To us "non-coders", simply compiling the source code can be a pain in ass!
So I request that someone make a EFS DLDI driver for libfat!
_________________
Sig under construction...Please check back after the sun explodes....
#160529 - silent_code - Thu Jul 17, 2008 9:50 am
Oh, I was just talking about replacing the filesystem handling libraries, not upgrading anything. That are two different tasks. Sure you would have either to get an old version of the libs and devkit (that is not a problem, if you have a good IDE) or update the codebase, but even that can all be done in a few hours or days, depending on your skills.
If you are not a programmer, then don't set yourself such tasks. Maybe you know somebody who can help you with his programming knowledge?
Or you start small and learn to program.
If I had the time, I'd give it a shot. Sorry. :^/
Again: Don't mix up things that don't belong together! I doubt it is possible to make anything like a EFS DLDI driver... that doesn't make any sense to me. EFS and libfat are two distinctive filesystem handling libraries!
And what do you want to use MS / DSO for anyway? I doubt you can do very much with a (max.) 3.75MB ROM including the filesystem. Especially knowing the size of DSO (around 8MB) and MS (around 1.4MB).
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#162847 - kiswa - Sun Sep 14, 2008 4:25 am
I have a problem with using EFSlib 2 in Linux.
I compile my code under Windows XP and it works great. Exactly the same code under Linux and EFS fails to initialize. I don't know what else is different between the two besides the EFS Patcher.
Anyone have any ideas?
#162950 - kiswa - Tue Sep 16, 2008 11:50 pm
| kiswa wrote: |
I have a problem with using EFSlib 2 in Linux.
I compile my code under Windows XP and it works great. Exactly the same code under Linux and EFS fails to initialize. I don't know what else is different between the two besides the EFS Patcher.
Anyone have any ideas? |
I've narrowed it down to the EFS patcher. I took the .nds file that wasn't working and used the Windows EFS patcher on it. It then ran on hardware.
Anyone have a Linux EFS patcher known to work that they could upload?
#163003 - kiswa - Thu Sep 18, 2008 12:59 pm
Really? Nothing for two days....
I can't believe no one else has had trouble compiling EFS stuff on Linux.
#163011 - kusma - Thu Sep 18, 2008 3:36 pm
kiswa: This might be a stupid question, but are your CPU 64 bit (Core2 CPUs are), and in that case have you tried to compile the patcher with gcc's -m32 flag?
#163017 - kiswa - Thu Sep 18, 2008 7:41 pm
It's an old laptop that barely runs Linux, so no, not dual core or x64.
That said, all I did was and it seemed to work. Should I have done something different?
#163250 - mml - Sat Sep 27, 2008 9:02 am
Found an array overrun :P
| Quote: |
source/efs_lib.c: In function 'EFS_Init':
source/efs_lib.c:551: warning: array subscript is above array bounds |
Here's the relevant snippet:
| Code: |
// if nds file is found, open it and read the header
if(found) {
*** char buffer[5];
nds_file = open(efs_path, O_RDWR);
// check for if a loader is present
lseek(nds_file, EFS_LOADERSTROFFSET, SEEK_SET);
*** read(nds_file, buffer, 6);
*** buffer[7] = '\0'; |
Any particular reason that buffer is declared as only 5 chars long?
#163482 - gauauu - Fri Oct 03, 2008 3:35 am
License question: I see that the EFS patcher is GPL'd, but the library itself doesn't seem to specify a license. Is there a certain license I need to follow to use it?
#164966 - Chase-san - Thu Dec 04, 2008 11:24 am
I seem to have a problem, the nds I compile runs fine on the emu, but it fails to run on the hardware.. Any idea why this happens?
I do patch it with the EFS patcher and dldi tool. I have tried it with only efs and only the dldi, same result.
#165007 - silent_code - Fri Dec 05, 2008 10:14 pm
| Chase-san wrote: |
I seem to have a problem, the nds I compile runs fine on the emu, but it fails to run on the hardware.. Any idea why this happens?
I do patch it with the EFS patcher and dldi tool. I have tried it with only efs and only the dldi, same result. |
This is way to generic. There are a lot of possible causes, that have nothing to do with EFS, but can lock up the hardware.
Make sure you check all your settings twice and use some printouts to the console to find out where the problem manifests.
Good luck.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#165084 - Chase-san - Tue Dec 09, 2008 2:48 pm
I had already done all of that, really I think it may just be not finding the nds file on the fs. But i'll do some further research (or switch to gbfs).
EDIT: I figured it out, thanks though.
#165101 - silent_code - Tue Dec 09, 2008 9:36 pm
What was the problem?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#165242 - robertre2 - Sun Dec 14, 2008 7:13 pm
Fixed EFS problem in linux.
Replace line 149 of efs.c with
new_id = rand()%65536;
(original was new_id=rand();)
The problem is that in Windows the maximum random number is 2^16 instead of 2^32. This results in two bytes in the file not being equal to zero.
This fixes the problem in Linux (at least it did for me).
#165323 - tepples - Wed Dec 17, 2008 6:07 am
| robertre2 wrote: |
The problem is that in Windows the maximum random number is 2^16 instead of 2^32. This results in two bytes in the file not being equal to zero.
This fixes the problem in Linux (at least it did for me). |
If you're relying on assumptions about implementation-defined behavior, you can detect problems earlier with compile-time assertions. This macro creates a line of code that fails to compile if expr is false:
| Code: |
| #define CTASSERT(name, expr) extern char name[(expr) ? 1 : -1] |
If expr is false, it makes an array whose size is negative, causing the compiler to stop and spit out a diagnostic. You use it like this:
| Code: |
#include <limits.h>
#include <stdlib.h>
CTASSERT(cta_eightBitChars, CHAR_BIT == 8);
CTASSERT(cta_randMax16, RAND_MAX <= 65535); |
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#165649 - ritz - Thu Jan 01, 2009 7:41 pm
Any info on the EFS lib being updated to work with devkitARM 24?
#165650 - zazery - Thu Jan 01, 2009 9:04 pm
I am using EFS Lib 2.0 with devkitARM r24 and libnds 1.3.1 and have not run into any problems. I have noticed the array overrun that mml reported and a couple warnings about incompatible pointer types but that is it.
#165653 - ritz - Fri Jan 02, 2009 12:48 am
I fixed those things too, but I guess my real question is if the author is still around doing updates/releases or if I should just continue to modify my own copy of the library.
#165796 - MaesterRowen - Wed Jan 07, 2009 5:59 am
Hey guys, I am just getting onboard with this library and I have run into a snag unfortunately.
Hardware I am using:
CycloDS Evoluvtion
I have an 8gb SDHC card
My problem is that the EFS_Init function is hanging on the "searchdirectory()" function. The code works fine on an emulator, but on the hardware, it'll hang.
Now I am curious, if this is just an extremely slow search, or maybe I have a problem elsewhere that I am overlooking. I have had the program running for about 5 minutes now, and it hasnt found anything, so that leads me to believe something fishy is going on.
If anyone else has experienced this problem, do you think you could offer some help?
Thanks!
#165797 - ritz - Wed Jan 07, 2009 6:13 am
I had the exact same problem, I changed my code to use opendir and readdir (thx elhobbs). Works just fine now. Here's the post about it:
http://forum.gbadev.org/viewtopic.php?p=165695#165695
#165798 - MaesterRowen - Wed Jan 07, 2009 7:03 am
I am not sure I completely understand the changes required (still relatively new, so bear with me:).
I need to change the diropen(".") to opendir(".")?
What do I change to readdir?
Thanks ^_^
#165800 - MaesterRowen - Wed Jan 07, 2009 7:35 am
Actually, scratch the top comment. I figured it out. I had to basically re-write the SearchDirectory Function to work with the new commands. Pretty simple when following the libfat example.
Thanks for pointing me to the right direction.
#167469 - headspin - Fri Mar 13, 2009 2:17 am
Has anyone got this working on a GBA Movie Player? When I run the demo I get "EFS init OK!" "Found NDS path: GBA ROM" then I press the A button and it goes into a loop saying
FILE: /, size: xxxxx bytes
Where xxxxx bytes keeps incrementing and then resetting back to zero.
I also tried a custom demo which runs fine on No$ but goes to a black screen on the MP.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#167475 - NinjaCoder - Fri Mar 13, 2009 10:06 am
if i'm just going to load data fom the EFS is it better to just use the GBFS that comes whit devkit pro, or is it recomended to still use EFSLIB?
#167477 - headspin - Fri Mar 13, 2009 1:39 pm
So here are some tests of my demo (which loads an image into a buffer and dma's it to both screens) and the official directory demo included with EFS
No$GBA - Both work
R4 - Mine doesn't work (black screens), but the dir demo does work
M3 - Both work
DSLink - Both don't work (white screens)
MP - Both don't work (some image flickers on for a moment then black) / the dir demo does as described in my previous post
I'm really confused about it not working on the R4.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#167494 - headspin - Sat Mar 14, 2009 7:37 am
It seems the problem I was having was because of the new libfat in devkitARM r25. For anyone else who would like to use EFS in r25 you can download an updated example from here.
Incidently I didn't need to change to use opendir or readdir but the following code in efs_lib.h
| Code: |
// defines
#define EFS_MAXPATHLEN 768
#define EFS_MAXNAMELEN 128
// the NDS file path, dynamically set by the lib
extern char efs_path[EFS_MAXPATHLEN]; |
If anyone can say for sure if I should move to use opendir and readdir instead please let me know. But AFAIK the above fixes the problem although it still does not work on the GBA Movie Player.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#167496 - headspin - Sat Mar 14, 2009 5:39 pm
EDIT: Okay it seems like EFS works with all the flash carts I've tried now, except for the GBA Movie Player.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#167646 - renatobs - Sat Mar 21, 2009 7:10 am
Hi. I?m a brazilian developer ( newby ) and my english is not good but I think that you?ll understand me. I?m developing a remake of the game and I already have a lot of thing of the game finished, but now I need to use LIBFAT to imrpoved my "cart space".
I have read a lot about EFS but I?m very confused with a lot of things. I have studied the exemples and I could got some ideias. Does not the EFS working in NO$GBA ?! In my real NDS with EZFlashV the most of them are working... Need I to do some special thing to these files working on No$gba ?
My main problem now is that I?m putting "mp3" files in my game. I?m using the AS_Lib ( that is so fantastic ) and I can play "mp3" and "sound efeccts" together without problems. These is excelent !!! But now I can?t do more things cuz the cart became almost 4Mb. I need to put the "Mp3" files out of RAM, using the "Mp3 Strem Player". Unfortunaly NODA is out ( I guess ) cuz I can?t a answer from him. Then I?d like a help from someone here, cuz "you are a kind of GOD?s of development in NDS".
Well, these are my problems:
- I need that someone detect what?s happen with "AS_Lib" that it can?t play "MP3 stream" by "FAT" or "ESF_FAT" ;
- In the case that I can?t solve this problem, is there some way to play the MP3 change these in the RAM ? The Direct Play of AS_Lib play a MP3 from RAM, but when I compile the code, the compiler create 2 files from MP3 ( *.o and *.h ), one have the codes of MP3 and other the headers with name and size. How could I change these in the RAM ? Creating a volatile array and put there a mp3 to play ?!?
- If I have a "image" file converted by "pcx2gba" with a "data" and "pal" arrays, how can I put these in a FAT dir, read and put in VRAM, for exemple ?! Usually I use the "swicopy" or "dmacopy" with a pointer to tranfer the arrays to VRAM, but the files are in RAM, included in the code, and them get space of.
I don?t know if I wrote understandably... If not, sorry !! Please, I need some help and i?ll be so grateful !!!
Thanks !!
PS.: here is my game:
- http://br.youtube.com/watch?v=oHwqK46bE50
- http://forums.shiningforcecentral.com/index.php?showtopic=12564
#167652 - headspin - Sat Mar 21, 2009 10:59 am
To get EFS lib working with the latest version of devkitARM you should download my updated version here. You will need to copy the mp3's to the efsroot folder and reference them as "/MyFolder/MySong.mp3". If you have them in the root of efsroot then just use "/MySong.mp3".
One other change I forgot to do in my update is in efs_lib.c you should put
| Code: |
"efs_path: \n"
" .skip 768 @ Path of the rom \n" |
The reason for this is the max file length changed in the latest versions of fatlib and because of this the SearchDirectory function would fail to find the .nds file.
Now to access the your mp3's you can use
| Code: |
| file = fopen("/MySong.mp3","rb"); |
And now you can use standard functions from stdio.h to read the file into a buffer to play or you can stream the music from the buffer and refill it using timers. Just be aware that fseek can be a bit slow so I would just use fread() instead and avoid fseek if you can. fread() will move the file pointer the amount of bytes read so you should not need to fseek().
ndstool attaches the files in efsroot to the end of the ROM so you will not get an .o or .h created. And yes it should work fine in No$GBA as well as on any card with dldi support.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#167661 - renatobs - Sat Mar 21, 2009 2:06 pm
Thanks for your help. But, I still have problems with AS_Lib... when I turn on the option to use EFS lib or only FAT, this don?t work... the compiler work with the FAT option, but the MP3 don?t play, and the compiler don?t work with EFS cuz I receive a error message about the variable "mp3file" that have some problem with EFS... ASL_Lib only work with "DirectPlay" mode, that read the mp3 from RAM... then "StreamPlay", tha use FAT/EFS mode don?t work...
And about the tiles background reading from FAT, could you help me with some ideia !!! I have a pointer like "u8* tileMemory = ( u8*)BG_TILE_RAM(1);" where I use like a pointer to put a tiles of background. I?d like to put the information (data) of tiles in a directory and after read and put there. Could I put a "data[]" and "pal[]" in a file inside a directory (FAT) and read after ?!?
Sorry for my english !!!
Thanks again for your help !!!
PS.: for me ( and I think that for some other people ) is very important a help to AS_Lib... NODA is responsible by AS_Lib and EFS_lib, but he?s out a long time... Any help with AS_lib will be great !!!!
#167800 - renatobs - Sat Mar 28, 2009 5:31 pm
Hi. I?m a brazilian developer ( newby ) and my english is not good but I think that you?ll understand me. I?m developing a remake of the game and I already have a lot of thing of the game finished, but now I need to use LIBFAT to imrpoved my "cart space".
I have read a lot about Chishm FAT but I?m very confused with a lot of things. I have studied the exemples and I could got some ideias. Does not the EFS working in NO$GBA ?! In my real NDS with EZFlashV the most of them are working... Need I to do some special thing to these files working on No$gba ?
My main problem now is that I?m putting "mp3" files in my game. I?m using the AS_Lib ( that is so fantastic ) and I can play "mp3" and "sound efeccts" together without problems. These is excelent !!! But now I can?t do more things cuz the cart became almost 4Mb. I need to put the "Mp3" files out of RAM, using the "Mp3 Strem Player". Unfortunaly NODA is out ( I guess ) cuz I can?t a answer from him. Then I?d like a help from someone here, cuz "you are a kind of GOD?s of development in NDS".
Well, these are my problems:
- I need that someone detect what?s happen with "AS_Lib" that it can?t play "MP3 stream" by "FAT", "ESF_FAT" or try change to "Chishm FAT";
- In the case that I can?t solve this problem, is there some way to play the MP3 change these in the RAM ? The Direct Play of AS_Lib play a MP3 from RAM, but when I compile the code, the compiler create 2 files from MP3 ( *.o and *.h ), one have the codes of MP3 and other the headers with name and size. How could I change these in the RAM ? Creating a volatile array and put there a mp3 to play ?!?
- If I have a "image" file converted by "pcx2gba" with a "data" and "pal" arrays, how can I put these in a Chishm FAT dir, read and put in VRAM, for exemple ?! Usually I use the "swicopy" or "dmacopy" with a pointer to tranfer the arrays to VRAM, but the files are in RAM, included in the code, and them get space of.
I don?t know if I wrote understandably... If not, sorry !! Please, I need some help and i?ll be so grateful !!!
Thanks !!
PS.: here is my game:
- http://br.youtube.com/watch?v=oHwqK46bE50
- http://forums.shiningforcecentral.com/index.php?showtopic=12564
#167809 - josath - Sun Mar 29, 2009 5:35 am
renatobs, can you please stop posting the same exact message everywhere? You've posted it at least three times now.
#167816 - renatobs - Sun Mar 29, 2009 2:50 pm
sorry...
#168184 - Jesse - Tue Apr 14, 2009 6:30 am
I just wanted to confirm the EFSlib with the changes posted by headspin works well with the latest version of libnds.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena
#168389 - Jesse - Mon Apr 27, 2009 1:16 am
I ran into a new problem though. When EFSlib searches directories it eats up 1648 bytes of the stack for each recursion, and crashes when the 16k stack runs out. I guess it would be best to change that code to dynamically allocate memory instead.
_________________
http://www.collectingsmiles.com/colors & http://www.collectingsmiles.com/hyena
#168415 - a128 - Tue Apr 28, 2009 4:46 pm
Is EFSlib faster then
http://blea.ch/wiki/index.php/Nitrofs
from eris?!
The good think about NitroFS is that it hooks to the interface of fread, fopen and so on....
_________________
"Hey! It compiles! Ship it!"
#168423 - zazery - Tue Apr 28, 2009 10:13 pm
| a128 wrote: |
The good think about NitroFS is that it hooks to the interface of fread, fopen and so on.... |
I have not used NitroFS so I can't comment on speed but EFS allows you to use fread, fopen etc.
#168431 - headspin - Wed Apr 29, 2009 5:17 am
I just tried replacing EFS with NitroFS for my game and didn't notice any speed difference. The only thing I don't like about NitroFS is you have to pass the full path to your NDS file while EFS searches the card to find it.
NitroFS is being integrated into devkitARM so it will become the standard. The path to the nds will be available using argv but until more cards implement this I will be using EFS. But it's very easy to go from EFS to NitroFS anyway (took me a couple of minutes to swap them over).
Both use hooks to fread/fopen so they are practically the same. Infact it looks like quite a bit of code has been "borrowed" from NitroFS.
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game
#168664 - melw - Thu May 14, 2009 6:49 am
I noticed that EFS lib didn't work anymore with either of my M3SD adapters (SLOT-2), even when using the updated version from Headspin. While I'm not sure where this bug comes from, moving the EFS_AND_FAT check right in the beginning of EFS_Init() function fixed this for me:
| Code: |
// initialize the file system
int EFS_Init(int options, char *path) {
bool found = false;
// init libfat if requested
if(options & EFS_AND_FAT) {
if(!fatInitDefault())
return false;
}
...
}
|
Change tested and confirmed to work with R4DS, M3SD Lite and M3SD.
#169328 - veubeke - Fri Jul 03, 2009 12:00 pm
For anyone who wants to know. It took me some debugging to find out that my 64bit binary of the efspatcher doesn't work (it seems to produce IDs that are too big). So anyone with a 64bit linux might want to use wine or a 32bit version.