[Cid2Mizard]

pas de problème esf + asLib de mon côté
d'ailleurs, je lis un mp3 avec efs:/ dans le chemin sans problèmes

Euh oui mais je parle de ASlib + Lobbylib 

[Alekmaul]

Et pour l'ASLib et la LobbyLib, je suis embété dès que j'initialise l'ASLib , que se soit avant ou après la Lobby, ca ne va pas soit j ai pas de wifi ou soit sa plante dès l'init.

Y a une solution pour utiliser ASLib + LobbyLib ?

Certainement un pb de gestion des FIFO entre l'arm7 et l'arm9, cherche de ce coté là.

[Zombie]

Merci pour ta réponse Noda... J'utilisais effectivement l'ASlib modifiée (pour EFS)...

Maintenant, je n'ai plus d'erreur mais quand je lance le NDS sur mon émulateur, j'obtiens ca à l'air de se figer et je n'ai aucune musique...

Voici mon code :

Code

 (c):
EFS_Init(EFS_AND_FAT, NULL);
 
PA_InitASLibForMP3(AS_MODE_MP3 | AS_MODE_SURROUND | AS_MODE_16CH);
 
AS_MP3StreamPlay("efs:/music/music1.mp3");
AS_SetMP3Loop(true);
 

Je loupe p-e un truc ?  

EDIT :
Ca plante au "PA_InitASLibForMP3" pour être précis...

EDIT2:
Ah ben si je vire la ligne "PA_InitASLibForMP3", ca marche 
Cette ligne est-elle vraiment nécessaire ?

EDIT3:
Ok, je faisais juste le gros boulet... La ligne "PA_InitASLibForMP3" était déjà plus haut dans mon code... Donc en double, ca ne passait pas...   

[Alekmaul]

Yop Noda,
Je viens de détecter un gros problème d'incompatibilité avec les linkers qui ne possède pas de reconnaissance des fichiers en "case sensitive" (comme le MK5 je pense).
Ces derniers sauvegardent les noms de fichiers en MAJUSCULE, même si tu les indiques en minuscule.
Ainsi, si tu mets ton homebrew dans un sous répertoire (style /Homebrews), le premier lancement fonctionne bien, mais l'écriture du path dans le fichier NDS indique /Homebrews/FICHIER.NDS, même si ce dernier est nommé Fichier.nds
Ce qui fait qu'au second lancement, impossible d'initialiser EFS ... planton du homebrew

Je me demande s'il n'y a pas de pb aussi à la lecture si tu stockes des données dans un sous répertoire de ton arbo efs, il n'arrivait plus à la trouver, j'étais obligé de tout mettre à la racine de l'arborescence.

[Noda]

Ce problème vient visiblement de la libfat avec certains linkers, qui dès que le fichier est en format 8.3 passe en majuscules... je vais vérifier que dans l'init de l'EFS je fais bien gaffe à pas prendre les majuscules en compte (car la libfat est case insensitive de toutes facons il me semble, le cas contraire serait bien problématique par contre :s).

Pour les fichiers dans arborescence faudrait que je teste, mais c'est fort possible que ca vienne d'un bug de ndstool qui implémente mal la contruction du NitroFS. Pour retrouver un fichier (id) de toutes facons c'est la fonction de parcours de ndstool qui a été modifiée dans EFS, et pour la lecture de celui-ci, l'offset de départ c'est simplement offset de base + décalagege*id, et il n'y a que l'id qui change la dedans. Donc une fois l'id trouvé, si les fichiers sont pas au bon endroit je crois pas pouvoir faire grand chose :/ ou alors j'ai loupé un truc dans les spec du NitroFS  C'est simple a vérifier sinon: le coup des répertoires, ca marche avec NitroFS ou pas? vu qu'il parcourt le NitroFS différement, si ca marche avec NitroFS ca devrait etre corrigeable a priori.

Sinon un truc qu'à dit Michoko me chagrine quand même l'arborescence qui marche sur ému (driver GBA) et pas sur linker (driver DLDI) sachant que ce qui change entre les 2, c'est la lecture qui passe de memcpy à fseek + fread :/ Bug bizarre de la libfat? (ce serait loin d'être le 1er que je trouve...)

[Alekmaul]

bon ... pb résolu mais tu vas pas être content Noda  ...

En fait, le pb vient de l'utilisation des read / open / close / write à la place des fread / fopen / fclose / fwrite.

En effet, après quelques recherches, j'ai trouvé que le pb venait de l'écrasement de la zone de signature de l'efs sur MK5 (pas sur d'autres linkers comme l'edge où sa fonctionne bien ...).
Dans la fonction checkfile, sur MK5, le lseek(f, 0, SEEK_SET); suivi du dataChunk_size = read(f, dataChunk, EFS_READBUFFERSIZE); ne fait pas ce qu'il faut. En effet, le 1er octet est oublié dans la lecture, ce qui fait que la signature est trouvé à offset-1 à la place de offset et ça écrase donc l'octet de poids fort de la taille du fichier nds.
Lors du second lancement du homebrew, la taille n'étant pas correcte, ploum, planton :/
Je suis hélas certain que les autres read / write impliquent le pb de répertoire qui ne fonctionne pas sur MK5. Je vais essayer de tout remettre avec des fread/fwrite (même si c'est plus lent, je sais Noda  ) pour tester ...

[Noda]

Hmm c'est possible que ca vienne d'autre chose (cf bug de la libfat): j'ai remarqué récemment que faire des lecture puis écritures consécutives dans un fichier marchaient pas terribles parfois, genre:

fread(truc)
fseek(0)
fwrite(truc)

et le fwrite se retrouve écrit a un offset de 1024 sur mon DSX... un fclose puis re-fopen entre le fread et le fwrite résoud le pb.

Vu que le checkfile a été écrit ya pas mal de temps, c'est possible que y'ai pas de fclose entre les fread et les fwrite, ce qui peut causer ce souci là. Je regarderai ca ce soir.

EDIT: j'ai regardé, c'est bien ca . Rajoute donc un close puis open avant le lseek et tout devrait se passer comme prévu

[Alekmaul]

Soit mais comme indiqué, si je remplace les close/read/write/lseek par fclose/fread/fwrite/fseek, y'a plus aucun pb ..., étrange non ?
De plus, les répertoires dans la structure efs ne fonctionnent pas , un peu avec les fread/fcllose (ou j'ai merdé dans ma version customisée, ce qui est possible ..)

bref, en tout état de cause, je garde pour l'instant ma version "customisée" avec les fread/fwrite/fclose histoire de pouvoir tester avec le MK5

[Campanile]

Je me permets de m'interférer au milieu de tout ça, tu as un driver DLDI MK5 qui gère le write Alekmaul ?
J'ai peut être des problèmes aux yeux mais chez Chism j'ai vu qu'un read 
Du coup si tu as une version custom(ou dispo partout et que j'ai loupé) read/write, je suis preneur

[Alekmaul]

oui, pour moi, il gère le write, c'est celui de la libfat. En plus, c'est de l'auto patch dldi, donc y'a pas de pb.

Pour en revenir à ton post Noda, en plus  le pb est bien avant le write pouisque c'est à la lecture que ça va pas, donc dés le début , ici :

                fseek(f, 0, SEEK_SET);
                while(efs_offset<size && !found) {
                    dataChunk_size = read(f, dataChunk, EFS_READBUFFERSIZE);

Dés le début, pof le premier octet est pas lu et je ne crois pas qu'il y a des write avant

Mais bon, j'abandonne sur MK5, j'ai trop de bug là, je comprends plus ce qui plante dans ma version customisé ...

[Noda]

Bizarre que ca plante sur un read là, a moins que le seek ne soit mal implémenté En plus fread & co se basent sur des read etc, donc c bizarre que ca marche avec et pas sans (la seule différence à ma connaissance étant le buffering).

J'ai un MK5 donc je regarderai à l'occasion, mais c'est très étrange

[Noda]

Bon j'ai fait quelques tests et effectivement il y a problème avec le seek du driver DLDI du MK5, qui fait aussi que les répertoires ne marchent pas (je suppose donc que tu as un mk5 ou assimilé Michoko?? )

J'ai posté sur le forum Neoflash à ce sujet.

Sinon grace à un gentil monsieur de gbadev, un petit bug a été résolu qui permet à l'EFS de fonctionner correctement avec le driver GBA sur hardware, donc amélioration de la compatibilité

Dans la prochaine version, je vais intégrer mon pti moteur de parsing de répertoire que j'ai fait pour chdir un peu partout, ce qui fait que y'aura plus de prise de tete à savoir comment entrer les chemins pour les fichiers répertoire etc, tout les paths standard et relatifs seront supportés (comme "./blabla/../../ici/fichier.txt" par ex)

Au fait est ce que le maximum de monde pourrait tester le fichier précompilé EFSv2.nds de la dernière build (page 4 du topic) pour savoir si le test de listage des répertoires marchent sur d'autres linker que le mk5?

j'éditerai au fur et à mesure ce post pour savoir quels linkers ont déjà été testés:
- MK5 (& clones comme NCard): marcho pô
- DS-X: ok
- SCLite : marcho pô
- CycloDS : marcho pô
-

[Michoko]

Salut Noda,

Non malheureusement mon linker est un CycloDS Evolution
Je vais retester ton NDS précompilé, mais de mémoire ça fonctionnait. Je pense que mon problème vient plutôt d'un grand nombre de fichiers dans la ROM.

[Alekmaul]

En fait, faut aller plus loin dans le test et lancer 2 fois le fichier nds car le MK5 a le problème de lecture du ficheir au second lancement (moment où il recherche la signature qu'il ne peut trouver car il a écrasé cette dernière au premier lancement) ...
Aussi, il faut mettre le fichier dans un sous répertoire pour éviter qu'il prenne la racine du linker comme argent comptant.
Ainsi, le test sera plus probant

[Michoko]

Bon je retire ce que j'ai dit, il semblerait bien qu'il y ait un problème.

Conditions du test:
- EFSv2.nds compilé avec la RC1 et placé dans le répertoire "/homebrew/"
- Linker CycloDS Evolution avec firmware 1.31
- Dès le premier lancement, la ROM bloque sur "listing '/list/' directory"
- Idem pour le 2ème lancement
- sur NO$GBA 2.6a, tout fonctionne bien avec le même fichier NDS

Il y a donc bien un souci

Edit: Noda, si tu veux m'envoyer des builds de test, je me ferai un plaisir de te faire un retour.