EFS Lib

[Schyzophrenic]

Pour info, on peut remplacer dans le makefile ../efs.nds (ou autre extension) par $(OUTPUT).nds (ou autre extension).

Cela permet d'avoir un makefile générique

Sinon, bah j'ai pas encore testé, mais je suis dessus

Merci pour tout ce travail !

[Schyzophrenic]

Noda, je n'ai pas réussi à faire fonctionner EFS en C++... C'est moi qui suit nul ou la lib n'a pas été prévu pour ça ??

[Noda]

Euh à priori j'ai bien rajouté les "extern "c" {" la ou il fallait, mais j'avoue ne jamais avoir testé... enfin à part le pti rajout que j'ai marqué, c'est sensé marcher quand meme :/

[Schyzophrenic]

Alors je pense que c'est moi qui ne suit vraiment pas doué...
Dès que j'inclue une fonction EFS j'ai cette erreur :
main.cpp:16: undefined reference to `EFS_Init()`

Une idée ? Pourtant j'ai bien inclus le .h dans mon main et les fichiers .h et .c sont bien dans mon répertoire source..

[Noda]

essaye de renommer efs.c en efs.cpp

[Schyzophrenic]

J'en reviens pas que ce soit aussi simple !! :/ Merci beaucoup Noda! Ca compile bien maintenant !

Par contre, pour ma gouverne, c'est du à quoi ??

[Noda]

au makefile je pense tout simplement, qui n'inclus pas les fichiers .c lorsque l'on est en mode c++

[Schyzophrenic]

Merci Noda.

J'ai une autre question, il y a t il un moyen de faire fonctionner le tout sous emulateur (no$gba ou autre) ?

Si je lance l'exemple ca me fait FAT init error (normal puisque non patché DLDI)

Si je patche avec FCSR, j'ai EFS init Error...

Bon, j'ai trouvé ... Merci Alekmaul

[mastertop101]

Salut, 2 petites questions ;
À quoi sert la lib -lul ? (voir makefile de l'example palib)
Y a-t-il des fichiers utiles au système EFS dans le dossier efsroot ? (genre des fichiers servant à la sauvegarde des paths...)

[Noda]

la librairies -lul c'est pour inclure la uLib de Brunni

sinon aucun fichier nécessaire à l'EFS dans le root, c'est inclus directement dans le code

[mastertop101]

Salut, encore moi, je viens de tester l'exemple fournie, ça fonctionne sur Microninja (slot 1 micro sd) mais pas sur supercard CF... (patché avec DLDI, ou pas)

[Noda]

hmm chelou :/

Pourtant moi j'ai testé sur supercard SD et ca passait :/ C'est quoi le souci? lecture, écriture, les 2? t'a bien pris le ".sc.nds" pour la supercard?

Question con: tu l'as pris tel quel ou t'a recompilé avant (des fois que moi j'ai oublié de le faire avant de release, essaye en recompilant)?

[mastertop101]

En recompilant, tout pareil...

FAT INIT ok
Please wait, searching NDS... // d'ailleurs, c'est quoi ça ?
EFS init error!

[Noda]

Donc il ne trouve pas ne trouve pas le fichier NDS hmm...

Aah, repasse le fichier .sc.nds un coup dans efs.exe des fois que l'id n'ai pas été inscrit lors de la compilation pour voir?

T'utilise bien DKP r20?

Pour les versions avec loader je détecte si le loader est présent grace au code présent dans celui-ci (PASS-quelque chose...). Le .sc.nds doit contenir un loader normalement, mais s'il n'est pas bien détecté il ne trouve logiquement pas le fichier...

[mastertop101]

Envoyé par Noda

Donc il ne trouve pas ne trouve pas le fichier NDS hmm...

Aah, repasse le fichier .sc.nds un coup dans efs.exe des fois que l'id n'ai pas été inscrit lors de la compilation pour voir?.

Ça marche
D'ailleurs, une nouvelle version de WTD est pour bientôt? C'est le jeu DS que je préfere (incluant les jeux commerciaux) .

[Noda]

Dès que j'ai le temps de me remettre dessus (je pars jeudi à montréal!) j'attaque la nouvelle version

[Noda]

Ayé enfin!!! sur GBAdev, de sympathiques personnes ont trouvé le fameux bugs qui faisait qu'à chaque fois que Sméalum utilisait ma lib ca buggait et en plus c'était pas un petit, je comprend meme pas comment on (je) l'a pas trouvé plus tot: dans EFS_fread/fwrite, j'oubliais tout simplement de mettre à jour la position de lecture après avoir effectué le fread/fwrite!

L'update arrive la semaine prochaine (j'espère), j'ai quelques trucs à rajouter et à tester avant

Ps: faut pas s'inquieter pr l'heure, je poste depuis montréal soit -6h de décalage

[Noda]

Voilà enfin la mise à jour!!

Les plus gros bugs devraient etre (a priori) résolus, j'ai mis aussi à jour les exemple avec un test d'une lecture sequentielle

voila le changelog:

14/05/2007 - v1.1a
= corrected bug with EFS_fopen() when filename does not begin with "/"
+ added defines for c++ compatibility

28/09/2007 - v1.2
= fixed real fat mode (hopefully)
= corrected a major bug with EFS_fread and EFS_fwrite
= moved some functions tweaks to fix real fat mode
+ added autoflush on file close by default
+ added extension checking when searching the NDS file (improve speed)
+ added some options

[omg]

Te niouze!!!!!

[Noda]

Attention à ceux qui ont récupéré la version d'hier soir, elle contenait encore un vilain bug avec EFS_fread/fwrite, c'est maintenant corrigé

Je vous invite à retélécharger les archives en cas de doutes

[Lord Raptor]

Du beau boulot

[linio]

Bien le bonjour à tous.

Super ta lib Noda.

J'ai une petite question car je bloque sur ta lib.
Je veux lire un raw(son avec PA) contenu dans la roms stocké grace à ta bli.
Quelles fonctions utiliser?

[Michoko]

Salut Noda,

J'ai l'impression que j'ai trouvé un bug sur la v1.2. Dans mon projet j'utilise pas mal de petits fichiers, et j'utilise l'astuce FCSR pour tester mon code sur NO$GBA.

J'ai une fonction de base toute bête :

char* LoadTextFile(char* name)
{
	char* buffer;
	EFS_FILE* file;
	u32 size;

	file = EFS_fopen(name);
	if(file != NULL) 
	{

		size = EFS_GetFileSize(file);
		buffer = malloc(size + 1);
		EFS_fread(buffer, 1, size, file);
		buffer[size] = '\0';
		EFS_fclose(file);
		return(buffer);  
	 }
	 else
	 {
	  	  return(NULL);
	 }
}

Mais si je l'appelle en lui passant un nom de fichier qui n'existe pas, la fonction va bugger la prochaine fois que je l'appellerai (GetFileSize renverra des valeurs erronées par exemple). Après pas mal de tests, j'ai trouvé une solution temporaire : il faut utiliser la fonction EFS_Flush() dans le cas où l'ouverture s'est mal passée, comme ceci :

char* LoadTextFile(char* name)
{
	char* buffer;
	EFS_FILE* file;
	u32 size;

	file = EFS_fopen(name);
	if(file != NULL) 
	{
		size = EFS_GetFileSize(file);
		buffer = malloc(size + 1);
		EFS_fread(buffer, 1, size, file);
		buffer[size] = '\0';
		EFS_fclose(file);
		return(buffer);  
	 }
	 else
	 {
		  EFS_Flush();
	  	  return(NULL);
	 }
}

Tu me diras qu'à priori ce n'est pas la mort vu qu'on appelle rarement un fichier inexistant. Mais dans mon cas, par exemple, j'ai environ 350 petits fichiers texte, et cela ne passe visiblement pas bien sous NO$GBA (je ne sais pas si c'est un bug dans la lib ou dans NO$GBA lui-même). Du coup je suis sans arrêt en train de jongler avec mes fichiers de données, et la détection de l'existance d'un fichier est importante dans ce cas là.
Si d'ailleurs tu as une idée sur la raison de ce mauvais fonctionnement lorsqu'il y a plein de petits fichiers (ce n'est pas un pb de taille totale, mais plutôt du nombre de fichiers dans l'arborescence), je te serais très reconnaissant

Merci en tous cas pour cette superbe lib!

A+
Michoko

[Noda]

Hmm, j'y ai jeté un oeil, et je ne vois aucun souci dans mes fonctions à ce niveau là, d'autant que si le fait d'appeler EFS_flush résoud le souci (ca ne fait que fermer et réouvrir le fichier depuis la fat, ce qui cause un rafraichissement des tampons de la libfat), ca veut dire que le problème vient probablement de la libfat...

Sinon pour ce qui est de mal gérer plein de petits fichiers je sais pas trop, mais je crois que ndstool (qui injecte les fichiers dans le NitroFS) a une limite en terme de nombre il me semble, donc ca peut peut etre venir de la..

EDIT: apparemment le NitroFS gère jusqu'à 4096 répertoire et 61440 fichiers en tout, mais il me semble que ndstool n'implémente qu'en partie le NitroFS, donc la limite peut venir de là.

[Link Mauve]

Bonjour, j'ai eu un étrange petit souci avec le patcheur…
Quand j'utilise la version windows avec Wine (j'utilise Linux), EFS fonctionne. Quand je compile la source avec mingw32, pareil. Mais quand je le compile pour Linux avec gcc (4.1.3 20070929), la bibliothèque n'arrive pas à écrire dans la rom…
Avec deux petits programmes fait pour l'occasion, j'ai trouvé que seuls les octets c à f après le début de la section d'EFS changent… Ça ne vient donc pas du fichier ! Je sèche un peu là…
J'ai utilisé ce petit exemple trouvé sur dev-fr pour le test.
J'effectue mes tests sur un Supercard CF, avec le fichier .sc.nds, si ça peut mettre sur la voie…