Badablek

tu m'as mis le doute zinzin64. Donc par acquis de conscience, j'ai retenté sur Wii...je retire ce que j'ai dit sur l'interface ! C'est juste horrible (je commence à me souvenir pourquoi je n'aimais pas RetroArch ) Pour dire, je n'ai même pas trouvé comment entrer dans les menus ou faire quoi que ce soit à part admirer une interface orientée "début de l'informatique". Pourtant sur ScummVM ça ne me gêne pas, mais là, c'est un belle rigolade. Bref, rien ne vaut les interfaces "GX" des émulateurs standalone, sur Wii. L'interface aux petits oignons, on la trouve sur Switch

RetroArch, comme son nom le laisse supposer, est fait pour les émulateurs de consoles d'anciennes générations même si la Wii est abandonnée depuis longtemps, ce n'est pas vraiment le "cœur de métier" de cette interface. Donc, sur Wii, la configuration idéale, c'est : Isos Wii + Gamecube > USBLoader GX (avec l'appui de Nintendont) Anciennes générations > RetroArch Comme dit plus haut, tu peux également tout agglomérer avec Wiiflow, qui a un système de plugins (ce qui permet, par exemple, de lancer les roms de jeux directement depuis l'interface de Wiiflow qui se charge de passer le témoin à l'émulateur). Mais je trouve que ça fait trop chargé, et trop lourd à configurer correctement (un coverflow qui fait 4 kilomètres de long parce qu'on y a mis tous les romsets old gen, très peu pour moi). Et sinon, peu importe la méthode utilisée pour lancer les jeux Wii, c'est dans un dossier WBFS obligatoirement (convention mise au point entre les loaders et les cIOS). On parle de cœur d'émulation, parce que ce ne sont pas les émulateurs "standalone". RetroArch compile tous les émulateurs supportés pour les agglomérer dans une même interface unifiée. Donc oui, en gros, cœur = émulateur Pour le scan, oui, depuis RetroArch 1.8.2, on peut scanner les dossiers sans appui d'une base de données. Et depuis longtemps on pouvait le faire avec une base de données. L'inconvénient de la base de données, c'est que tu dois avoir un nommage strict des jeux pour qu'ils soient reconnus, et il faut que les signatures des fichiers (checksums) correspondent à cette base. Ce qui veut dire que les traductions non officielles, les redumps, bad dumps, hacks et autres ne sont pas visibles avec la base. Le mode sans base permet d'y pallier (moyennant, je suppose, un nommage strict également), et d'associer de jolies jaquettes à tout ce petit monde, histoire d'avoir une interface cohérente et attractive. Le CPC, à mon avis, ça tourne comme un coucou suisse sur Wii, avec Caprice32 Tu vas voir que RetroArch est vraiment très agréable à utiliser, et a des fonctionnalités vraiment tip top. Et pourtant c'est un vieux de la veille qui refusait de l'utiliser qui t'en parle Tu as un système de favoris pour épingler tes jeux préférés (associés au cœur d'émulation de ton choix), tu peux profiter de je ne sais combien de systèmes, tu peux aussi faire mumuse avec Retroachievements, utiliser les cheats accessoirement, voir les jaquettes et extraits vidéo des jeux, le tout dans une interface très PSP/Switch. Vraiment du bon boulot.

salut, si tu ne veux pas trop t'embêter avec 50 émulateurs différents (et autant de configurations de dossiers), je te conseille simplement RetroArch, qui est disponible sur Wii. La colecovision est émulée avec le cœur free_intv. Si tu télécharges la dernière version de RetroArch (1.8.2) Wii, tu verras tous les cœurs d'émulation supportés. En gros : arcade, cps1, cps2, Neogeo, Snes, GB, GBC, GBA, Nes, Colecovision, Megadrive, GG, Master System, etc. De quoi s'amuser toute sa vie une partition FAT32, c'est parfait ! Avec ça, tu fais tout tourner sans souci. Comme RetroArch est très souple, tu peux par exemple, faire un dossier ROMDATA, avec des sous-dossiers par cœur. Restera plus qu'à paramétrer le dossier de départ de RetroArch sur ROMDATA et tu seras bon. Accessoirement, pour avoir un truc rangé proprement, tu peux également scanner tes dossiers (avec ou sans l'appui d'une base de données) pour que RetroArch classe les jeux tout seul, par console. Et si tu prends les packs de jaquettes, tu peux te faire un truc aux petits oignons. http://www.retroarch.com/?page=platforms Si tu préfère les versions stand-alone, tu as aussi moyen de faire de belles choses : fceu-GX, snes9x-GX,vba-GX, mGBA, smsplus-GX, GenPlus-GX, WiiSX, UAE4Wii, etc. mais ça sera plus long à paramétrer, et bien moins homogène. Certains aiment également passer par le loader pour tout agréger avec Wiiflow Lite. Perso j'aime pas mélanger les torchons et les serviettes, mais ça dépend directement des goûts de chacun Pour moi, RetroArch reste le meilleur choix.

tu as tout bon alors piège à con à éviter (je dis parce que je me suis fait avoir) : ne surtout pas faire part 1 > part 2 > part 1 sinon c'est un semi-brick (de la puce, pas de la console) j'explique le pourquoi du comment j'en suis arrivé à faire cette bêtise : je voulais essayer le pre-bootloader (encore par mattytrog), pensant que c'était mieux que Switchboot (ce qui n'est pas le cas, soit dit au passage)...après avoir flashé uniquement le part2 (ce qui était la seule chose à faire), je constate que je ne peux plus démarrer Hekate ou SXOS, la faute à un mode de fonctionnement pas franchement user-friendly où le mode d'intéraction utilisateur a été chamboulé : en gros, il faut maintenir POWER 3 secondes le temps qu'un décompte apparaisse à l'écran, puis vite appuyer sur Vol+ ou Vol- pour interagir (moins d'une seconde pour se décider)... Voyant cela, j'ai l'idée lumineuse de reflasher PART1 (pensant que celui que j'utilisais jusqu'à présent n'était compatible qu'avec SWITCHBOOT). Ayant déjà flashé PART2, je me dis qu'il n'y a pas besoin de le reflasher...erreur grave ! Je reboote, patatra, plus rien, puce brickée, console qui ne démarre plus du tout, impossible de remettre la puce en mode UF2, impossible de reflasher proprement. Du coup j'ai de suite monté l'autre Trinket m0 que j'avais sous la main pour récupérer mes billes. Finalement, après une petite discussion avec Mattytrog qui m'a confirmé que je pouvais inverser la vapeur, j'ai réussi tant bien que mal à rebooter avec Hekate (injecté depuis TegraRCM) en montant la puce dans une Quest en mode AutoRCM (plus simple pour démarrer quand la puce a du mal), qui m'a permis de lancer le payload dédié à mettre la puce en mode UF2, pour ensuite enfin récupérer l'accès USB et réinjecter PART2. donc en gros, j'aurais du faire PART1 (switchboot) > PART2 (switchboot) > PART1 (fusee-suite)> PART2 (fusee-suite) pour retomber sur mes pattes. Ou plus simplement NE JAMAIS REFLASHER PART1 APRÈS PART2 ce qui m'a mis dans le jus, c'est que je sais que PART1 gère les boutons (autrement dit, l'interaction utilisateur), et comme je n'arrivais à rien niveau combos de boutons (notamment hekate mod), j'en ai conclu (peut-être trop rapidement) qu'il fallait reflasher PART1. courage pour le montage maintenant

salut megadeth, il n'y a plus grand monde sur le forum, et on est un petit peu le 31 décembre....donc un peu de patience, non ? pour en revenir au sujet, tu ne trouveras JAMAIS swiss intégré directement au freeloader (déjà parce que le freeloader est sorti bien avant que n'existe ce loader, d'autre part parce qu'étant un produit officiel, il ne va pas te donner de quoi hacker ta console). Et ce n'est qu'un CD de boot pour démarrer des jeux d'une autre région, il n'ouvre pas le hack en grand. Par contre, l'Action Replay est logiquement capable d'exploiter le SD Gecko (et donc, par ricochet, de lancer swiss). Si tu veux vraiment t'embêter, je dirais, pourquoi pas, mais il y a bien plus puissant (ce que j'utilise personnellement) : Il te suffit d'avoir The Legend Of Zelda - The Wind Waker, une carte mémoire préparée avec la sauvegarde hackée qui va bien et ton SD Gecko évidemment. Ne restera plus qu'à démarrer Zelda le plus normalement du monde, et dès l'écran-titre, il chargera, en fonction de ce que tu auras injecté dans la sauvegarde, Swiss, le loader de homebrews ou tout autre exécutable. Pas besoin de puce, pas besoin de manipulations fastidieuses, le tout avec un des jeux les plus populaires de la console (et qui trône, en général, dans toute collection d'un joueur Gamecube) Plus d'infos ici : https://github.com/FIX94/ww-hack-gc ps : une Wii hackée + GCMM, c'est royal pour injecter la sauvegarde GC la carte mémoire ne pourra pas te servir à jouer à ce jeu par contre (le hack se lançant automatiquement dès l'écran-titre) EDIT : le freeloader semble finalement pouvoir lancer Swiss, si le binaire est placé à la racine du gecko et renommé autoexec.dol info à confirmer par contre, ça m'étonne fortement.

relis bien ma phrase ;-) (certes un peu ambiguë) Je ne dis pas qu'elle ne l'est pas, je dis juste qu'une fois programmée, elle n'est plus visible. Je sous-entendais par là: en la connectant depuis son port USB (avant de le dessouder pour la pose dans la console). Je suppose qu'une fois posée, ça fonctionne en appuyant 2x sur reset. mais pas encore eu le temps de tester. tout ce que je voulais pointer du doigt, c'est qu'une fois programmée, vu qu'elle n'est plus visible, on ne sait donc pas si elle fonctionne vraiment... et le doute n'est levé qu'une fois la console rallumée (j'avoue avoir eu quelques secondes de stress qui m'ont paru de longues minutes ;-) )

mouais, il a fallu combien de temps avant que le glitch ne soit à peu près stable ? ce qui est sûr, c'est que le temps des puces à papa(papy) façon ps1, c'est fini avec les protections software+hardware actuelles. Ça sera très certainement du glitch, avec le lot d'imprévisibilité qui l'accompagne (normal pour un truc qui est justement basé sur le fait de "perdre" complètement le processeur pour lui faire exécuter ce que l'on veut) Pour l'instant, la team Xecuter ne bouge pas une oreille (tu m'Elton, John)

certains points sont un peu "chauds" si la panne du fer à souder est trop grosse. Avec un Weller 15w (pas forcément adapté à du matos RoHS) et une panne un poil trop large, le point Vol+ a été le plus embêtant (présence de connecteurs et nappes très proches, étroitesse du point d'origine, etc.) Mais en y allant gentiment, sans se presser, ça passe tranquille. Pour la configuration, le tuto est extrêmement pauvre en détails. Notamment : une fois la puce correctement flashée, elle n'apparaîtra plus jamais dans l'explorateur ! J'ai flippé avec ma première trinket, pensant l'avoir cramée. En flashant ma seconde puce (toujours avoir une pièce de rechange ), même topo une fois flashée (ç'a ma laissé penser qu'en fait les puces étaient OK, mais j'ai soudé à l'aveugle quand même pas un mot (du moins, c'est abordé très très vaguement) sur la façon de mettre les payloads, de faire cohabiter Atmosphère et SXOS (par exemple), d'utiliser Hekate (ne pas oublier l'interface Nyx pour un truc plus sympa à utiliser) rien sur la découpe obligatoire du carter métallique qui protège la CM pas plus que sur certaines options (USB Disconnect, et options en rose sur la photo de la CM) Je pense que son auteur a trop l'habitude des trinket et de la bidouille, et en oublie les bases : un tuto est fait pour expliquer de bout en bout les processus mis en œuvre. j'ai fait quelques remarques ici, à ce sujet :

bon le sujet date un peu, mais j'ai enfin sauté le pas. Me suis installé un Trinket m0 en mode perma-CFW. Ça fonctionne très bien !

salut, si tu soudes les straps Vol+ et Joy-con, et que tu utilises le fichier PERMA-CFW, ta console démarrera par défaut en mode Custom Firmware (avec ou sans emuNAND, suivant ta configuration...emuNAND plus que recommandée, comme tu l'as bien compris). Voir extrait de notice ci-dessous, venant du sujet très documenté sur GBAtemp : Vu la façon dont tu veux exploiter ta console, je suppose que le gros avertissement en rouge ne te concerne pas. Si tu laisses ta console en 4.1.0, et que tu paramètres une emuNAND à jour pour le CFW, à aucun moment, en appuyant sur Reset de la puce, tu ne pourras cramer le moindre efuse (puisque tu restes en 4.1.0 officiellement). Pour moi, cet avertissement concerne ceux qui voudraient booter en CFW sans emuNAND...mais ça ne reste que mon interprétation de la chose. Enfin, concernant le mode AutoRCM, c'est logiquement parfaitement géré par la puce depuis la version 1.5.3beta : Sachant qu'il faut à priori plusieurs mois pour que la batterie se vide complètement, console éteinte, avec le trinket m0 qui consomme (peu). Donc pas sûr que ce soit réellement un problème. ça me fait penser que ma Trinket m0 dort depuis des mois dans un tiroir...je vais me motiver pour la poser tiens EDIT : je viens de finir le montage...je n'avais pas conscience que c'était aussi chaud patate, ça m'a rappelé de bons souvenirs (puçage PS2 notamment). le tuto sur GBAtemp est, à mon humble avis, très mal foutu. impossible de trouver à quoi servait l'option USB disconnect (marron) ni quel(s pin(s) correspondent à quelle(s) fonction(s) en rose aucune ligne sur la façon de passer le trinket m0 en mode UF2 au tout premier flash rien sur le fait qu'une fois correctement programmée, la puce n'est plus flashable depuis le PC ! Je pensais avoir flingué mon trinket qui n'apparaissait plus du tout (en mode normal comme en mode UF2), j'ai donc programmé dans la foulée le deuxième que j'avais sous la main > même résultat. J'ai donc fait le montage à l'aveugle, sans savoir si la puce était encore vivante. pas un mot sur le payload à mettre à la racine. C'est bien évidemment fusee-primary.bin pour Atmosphère, à renommer payload.bin pas un mot sur le fait que la puce ne permet plus de remettre la coque alu correctement (à découper) y'a un boulot de dingue qui a été fait sur les fonctions de la puce, mais au détriment d'explications CLAIRES et précises sur son fonctionnement ou ses options. Dans le doute, j'ai tout connecté SAUF les options en rose. Étonnement, l'USB disconnect n'est pas détecté par Hekate. ps : j'ai flashé : Part_1_TRINKET_PERMA_CFW_Latest.uf2 puis Part_2_TRINKET_SWITCHBOOT_PART2_LATEST.UF2, ça donne : Appui simple sur Power : boot sur le payload (Atmosphère) Maintenir Vol- et et appui simple sur Power : boot sur hekate Dans Hekate, Reboot (normal) permet de démarrer sur la sysNAND (pas trouvé de raccourci pour le faire sans Hekate

ravi de pouvoir aider un des (rares) amateurs de cette console (sortie trop vite, oubliée trop rapidement) mine de rien, on peut encore faire de bien belles choses avec, même si la Switch l'a totalement éclipsée de la scène (et surtout...des programmeurs de homebrews).

tu peux également ajouter sigpatchtosystem à un raccourci manette sur haxchii (via config.txt) Ainsi, admettons que tu le paramètres sur le bouton A, il te suffira de maintenir A au chargement de haxchii pour lancer automatiquement sigpatchtosystem. exemple : a=wiiu/apps/sig_patcher/sign_c2w_patcher.elf default=sysmenu perso me suis fait un config.txt ultra complet (Mocha, WUP Installer, SwapDRC, etc.), avec une image de chargement de haxchii modifiée pour me rappeler à quoi chaque touche correspond C'est très pratique.

salut, Haxchii n'est que la faille de lancement qui ouvre les portes. Mais elle ne suffit pas pour activer les patches signature. Si tu essaies de lancer un contenu (chaîne) non signé, tu auras forcément une erreur de ce type. Il te faut lancer Mocha CFW (depuis haxchii) AVANT de pouvoir profiter de contenus non signés (que ce soit aussi bien pour les installer ou les lancer). Le mieux étant de profiter de la fonction de semi-loader de haxchii (grâce au fichier config.txt qui permet de définir des raccourcis manette pour lancer telle ou telle application) Seule exception : les jeux eshop mixés avec les "tickets" des mêmes jeux, mais au format DVD, puisque dans ce cas, tout est correctement signé (les tickets DVD sont signés avec une clé générique pour que n'importe quelle console puisse démarrer les jeux). Par contre HBL peut démarrer sans aucun patch signature, directement depuis haxchii. Tu es sûr de bien lancer le bon exécutable (fichier elf sur la SD) ? Si tu as installé la version chaîne comme le propose le tuto, obligatoirement, Mocha CFW doit avoir été lancé AVANT (et à chaque démarrage de la console, rappelons-le). En résumé, une console sous haxchii, sans les patches signatures supplémentaires de mocha CFW (ou équivalent), ne peut lancer que : homebrew launcher (format .ELF UNIQUEMENT) depuis lequel on peut exécuter les fichiers .RPX des homebrews bien sûr jeux Wii U eshop mixés avec leurs tickets DVD Wii U correspondants Tout le reste nécessite les patches signatures : jeux Wii U eshop ne disposant pas de ticket DVD (il en existe quelques uns, la version physique ne partageant pas le même titleID que la version dématérialisée) ou de type Wiiware (pas de version physique du tout) chaînes non signées (ce qui inclut TOUS les homebrews sous forme de chaîne)

non, c'est juste GodMode9.firm que tu prends (en gros, considère les .firm comme des exécutables) par défaut, les développeurs de homebrews proposent un peu tous les formats (.3dsx, .bin, .firm, etc.) pour contenter tout le monde (il n'y a pas qu'un seul hack possible sur 3DS). c'est un peu expliqué ici, dans le tuto 3dsguide (le dossier gm9 n'est pas obligatoire, il contient quelques scripts pas forcément utiles) ps : si ce n'est pas déjà fait, ne laisse rien dans ton port cartouche, en tout cas le temps de booter tranquillement sur Luma, de le configurer et de constater que la console démarre correctement. Il ne faudrait pas y laisser un linker programmé NTRBOOT par exemple (qui risque de bootlooper sur l'installation de b9s)

salut, le souci dans son cas, si j'ai bien tout suivi, c'est que la console ne démarre plus...donc mise à jour impossible, KGB64 @mitch8 supprime tous les fichiers à la racine (arm9.bin à soundhax.m4a) ainsi que le dossier boot9strap (au pire, renomme-le autrement), télécharge Luma 10.0.1 et extrais boot.firm à la racine. Là, on n'est pas certain que le boot.firm corresponde bien à Luma, sur ta capture d'écran. et comme tu as gardé arm9.bin et boot9strap (qui correspond à safeb9sinstaller), il se peut que l'exploit b9s démarre en boucle sur safeb9sinstaller (arm9.bin) plutôt que Luma3DS (boot.firm) dans le pire du pire des cas, tu mets le payload de godmode9 dans Luma (ça doit aller dans Luma\Payloads il me semble), tu démarres en maintenant START. Une fois sur Godmode9, tu vas sur ta carte SD (SDCARD), tu te mets sur boot.firm et tu appuies sur le bouton Y (copier), tu vas ensuite dans ta sysNAND (SYSNAND CTRNAND) et tu colles boot.firm en appuyant sur Y. Il va te demander si tu veux copier le fichier ou le chemin du fichier (raccourci), tu valides bien évidemment la copie entière du fichier. Pour écrire dans la sysNAND, il va t'inviter à faire une séquence de boutons pour confirmer, tu te plies à sa demande. Quand c'est fait (tu as donc boot.firm à la racine à la fois de la SD et de la sysNAND. Tu éteins la console, tu retires la SD, tu démarres et tu vois ce qui se passe. Si la console démarre bien (configuration de Luma puis boot complet), elle sera en mode Custom Firmware "de secours", ce qui confirmera que ta configuration est OK, auquel cas ça peut venir de ta microSD (carte bas de gamme, copie, etc.) ou qu'un fichier du hack n'est pas là où il devrait être. et si ça marche bien sans SD, ne restera plus qu'à formater proprement la carte, remettre UNIQUEMENT Luma3DS (donc boot.firm) et retenter ta chance. Et si ça fonctionne, tu pourras commencer à t'amuser un peu plus.

à mon avis, le risque de brick étant à mon maximum sur les unités iPatched, la team Xecuter a trop peur d'un retour de bâton contre-productif pour ses petites affaires très lucratives. un SXOS brickeur de Switch, ça ferait mauvais genre (d'autant qu'ils ne sont pas débutants en la matière, avec le brickeur volontairement intégré à leurs premières versions de SXOS) Il y a déjà bien assez de Switch non patchées dans la nature pour ne pas trop se soucier des iPatched / Mariko. Peut-être qu'une fois le filon épuisé, ils y repenseront (mais vu les millions d'unités non patchées, ça n'arrivera pas avant longtemps). à moins d'une faille béante à la sauce RCM, je doute qu'ils (Xecuter) mettent ls mains dans le cambouis avant un bon bout de temps.

salut, si la team Xecuter y travaillait, ça se saurait...Ils attendent tranquillement, le bec grand ouvert, que les vrais hackers (SciresM et compagnie) fassent tout le boulot à leur place. Sauf que, pour l'instant, malheureusement pour les désirs capitalistes de Xecuter, seules les consoles nouvelle génération en 3.x et 4.x peuvent être bootées sous Atmosphère. Ça repose sur deux failles purement software, utilisées conjointement, et qui ne seront jamais compatibles avec la dernière version du firmware (branche 8.x), qui corrige tout ça. Et comme les modèles Mariko sont de plus en plus vendues en 8.x, c'est mort d'avance. Bref, pas demain la veille que Xecuter sortira quelque chose de concret, non repompé des petits copains hackers bénévoles Il ne faut rien attendre d'eux, c'est ce qu'il y a de plus sage à faire.

le seul intérêt de rester sur un firmware ancien, c'est une potentielle faille "gold". Mais dans l'absolu (et j'en suis de plus en plus convaincu moi-même), c'est beaucoup d'ennuis pour un "peut-être". Perso j'ai passé ma quest en autoRCM + firmware 8.1 (pas folle la guêpe, je garde quand même un nombre de efuses bas au cas où) et je ne le regrette pas. Le firmware 8.1 permet de ne plus se soucier de savoir si tel ou tel fichier sera ou non compatible, et je n'ai, jusqu'à présent, trouvé aucun homebrew incompatible (ma plus grande peur à chaque mise à jour majeure de firmware) mes trinquet sont encore soigneusement emballés, un jour viendra, peut-être pour le moment, le génial dongle rcmloader me suffit amplement (la minuscule plus-value du trinket me fait même dire que ça n'en vaut pas la peine par rapport aux modifications que cela implique).

perso je ferais le contraire : réinjection de la NAND propre dans le sysNAND création d'une emuMMC en mode "incognito" de base, tu aurais une console saine, avec bootloader original, nombre d'efuses qui correspondent à la version du firmware, NSP 100% officiels et quand tu veux passer du côté obscur : RCM > emuMMC anonyme mais n'étant pas expert dans ce type de cohabitation, je me trompe peut-être.

le souci du online avec le hack switch, c'est que si tu as lancé le moindre NSP "frelaté", entendre par là avec un ticket non valide (ce qui inclut les homebrews), ça se voit comme le nez au milieu de la figure. Et personne ne sait si les efuses sont vérifiés à la connexion. Perso je ne conseille pas le online sur console hackée, pas même avec des XCI sous SXOS. ps: une console anonymisée ne peut pas se connecter au "live" Nintendo.

nickel les efuses ne concernent que la sysNAND, de toute façon le bootloader officiel ne sait même pas ce qu'est une emuMMC/emuNAND . Quand tu bootes une emuMMC, tu passes par un bootloader custom, qui ne touchera jamais à tes efuses. Donc aucun souci de ce côté, pas de corrélation entre le nombre de efuses cramés dans le CPU et l'emuNAND. Les efuses permettent juste au bootloader de savoir ce qu'il a le droit de lancer (protection anti-downgrade). Par contre, bien évidemment, les MAJ, c'est via choidujourNX. Il vaut mieux éviter toute communication online (risque fort de ban), à moins d'avoir anonymisé l'emuMMC avec incognito (un patch a été créé pour atmosphère dans ce but)

content que ça marche pour toi