28 réponses à ce sujet

[shadow256]

Perso, je trouve ça plus compliqué et moins fiable de retrouver le fichier emummc.ini sans demander la localisation du fichier à l'utilisateur car tu ne sais pas de base sur quelle partition (FAT32 ou exFat) de la carte SD est placé ce fichier (il peut y avoir d'autres partitions sur la SD). Comme je suis en plein dedans pour NxNM, ce que j'ai préféré faire personnellement est de parcourir la table des partitions primaires MBR de la carte SD et pour chaque partition chercher la signature de l'emmc (nombre magique) qui correspond à la GPT de la RAWNAND (vraisemblablement à l'offset 0x4001 après les deux partitions BOOT). SI la signature est OK, on dumpe. SInon on passe la partition suivante. C'est d'ailleurs comme ça qu'Hekate trouve les partitions emuMMC dans son outil de migration de l'emuNAND. On ne sait jamais ce que les utilisateurs peuvent bien faire avec leurs fichier *.ini ^^

Pas faux, pas faux du tout même.

Merci beaucoup @eliboa


C'est tu s'il est possible de ce servire de la même Emunand/Emummc en fichier sur la SD pour Sxos et Atmosphère ?

Car j'aimerai tester Atmosphere en Emummc. Je sais que pour la version partition cachée il suffit juste d'étider le fichier .ini
Est ce que c'est la même configuration ?
Merci

Non, pas possible d'utiliser la même emummc fichiers avec SX OS et Atmosphere, ceci n'est possible qu'avec l'emummc via partition car Atmosphere utilise d'autres noms de fichiers que SX OS pour détecter l'emummc, c'est pas la seule différence de se que je sais car j'avais essayé de réécrire le code source d'Atmosphere pour qu'il gère ceci mais ça bloquait après la vérification des fichiers, même s'ils étaient détecté il y avait des choses qui n'allaient pas ensuite donc j'ai abandonné. Avec l'emummc via partition on utilise une petite feinte dans le fichier de configuration pour indiquer que l'emummc commence au secteur 0x2 de la SD, se qui permet de sauter les 1024 octets inscrit par SX OS avant le vrai début de l'emummc via partition.

[eliboa]

Merci beaucoup @eliboa


C'est tu s'il est possible de ce servire de la même Emunand/Emummc en fichier sur la SD pour Sxos et Atmosphère ?

Car j'aimerai tester Atmosphere en Emummc. Je sais que pour la version partition cachée il suffit juste d'étider le fichier .ini
Est ce que c'est la même configuration ?
Merci

Nope a ma connaissance ca fonctionne que pour les emunand en partiton.

Edit : shadow plus rapide et plus complet ^^

Modifié par eliboa, 15 octobre 2019 - 08:24.

[Feaze]

Merci beaucoup @shadow256 et @eliboa

Dommage car je trouve l'Emunand/Emummc en fichier quand même beaucoup plus pratique.

[La Roukine]

Aussi l'emunand en partition est plus simple a emuler pout le CFW qu'une Nand en fichier, ce qui explique pourquoi au debut il n'existait que ce type d'emunand

En théorie l'emunand en partition devrait mieux fonctionner que celle qui est fichiers ?

[eliboa]

En théorie l'emunand en partition devrait mieux fonctionner que celle qui est fichiers ?

C'est surtout que c'est plus simple à mettre en œuvre dans le code d'emuMMC. Après niveau perf, j'imagine que tu perds un peu en emunand fichier mais je ne sais pas dire si c’est significatif en FAT32. L’emuMMC en fichier sur une partition exFat edit: FAT32 de la SD est très lente cela dit.

Le truc c’est qu’en mode fichier ton emuNAND peut être fragmentée (logique des FS FAT), ce qui oblige le CFW à passer par la FAT de la partition contenant les fichiers emunand pour switcher sur les bons clusters lors des accès en lecture/écriture, puis de repasser par la FAT (cette fois-ci de l’emuNAND fichier) pour enfin accéder aux vraies données. Bref ça fait double emploi, en tout cas pour les partitions FAT de la RAWNAND (essentiellement SYSTEM et USER).

Modifié par eliboa, 15 octobre 2019 - 09:08.

[shadow256]

J'ajoute également que l'emunand via fichiers sur une SD en EXFAT est bien plus sujette à la corruption de données, surtout avec la gestion de l'EXFAT parfois capricieuse de la Switch qui corrompt des données on ne sait pas trop pourquoi (c'est les homebrews qui font cela en général, Retroarch en est un spécialiste mais aussi Kosmos Updater qui semble souvent provoquer ce genre de déconvenues). Alors oui, l'emunand via fichiers est plus pratique pour la sauvegarde/restauration mais est probablement plus lente et est aussi moins fiable sur une partition en EXFAT car sa corruption peut se produire n'importe quand et puis bon au final c'est pas bien compliquer de sauvegarder la partition de l'emunand pour SX OS au moins, c'est certain que s'est pas un copier/coller mais c'est pas la mort à faire non plus avec dd. Perso je suggère plutôt l'emunand via partition, pour moi elle reste le meilleur choix au niveau du rapport stabilité/simplicité et puis avec l'emunand via partition de SX OS on peut l'utiliser aussi sous Atmosphere en même temps se qui est top.

[Feaze]

@eliboa C'est très surprenant car moi qui suis en Emunand SXos sur une carte SD scandisk de 400 Go en FAT32, je trouve mon Emunand super rapide.

[eliboa]

@eliboa C'est très surprenant car moi qui suis en Emunand SXos sur une carte SD scandisk de 400 Go en FAT32, je trouve mon Emunand super rapide.

Oui apparemment le problème de lenteur ne concerne que emuMMC, pas l'emuNAND de la TX.

[Linkynimes]

@eliboa C'est très surprenant car moi qui suis en Emunand SXos sur une carte SD scandisk de 400 Go en FAT32, je trouve mon Emunand super rapide.

Oui apparemment le problème de lenteur ne concerne que emuMMC, pas l'emuNAND de la TX.

J'avais fait des test sous emuMMC avec une SD de 64Go de Sandisk et sa rammais comme pas possible
Puis j'ai commandé une SD de 128Go Sandisk et je n'ai plus aucun soucis de lenteur en emuMMC sous Atmosphère, les deux SD étaient en exFAT