themam

Salut, Pour le dvd de config, tout est normal. Tu fais le changement, il modifie la mémoire de la puce, MAIS il ne peut la relire, DONC il te repropose le choix comme si tu n'avais rien fait. Pour tes sauvegardes, fait d'autres assais : dvd verbatim (x16 gravé en x2) ou autres ; logiciel de gravure IMGBURN ou autres.. Bref, c'est un pb de disque / de gravure. A+

Salut, Bizarre l'affaire J'ai mesuré le voltage des pins (moi aussi à partir de la pin 8) pin 1 : 3,26 pin 2 : 0V pin 3 : 0V pin 4 : 0v pin 5 : 3,26V pin 6 : 3,26V pin 7 : 3,26V Donc à priori à l'identique. Mais cette mesure ne permet pas de savoir si tu n'as pas permuté 2 fils ( 5 & 7 par exemple )... Il faut vérifier celà ! Auto-détection de la zone ( mettre 02 dans la 1er adresse de l'eeprom ) pose des problème et n'est implantée que depuis la version 2.38 Essaye avec une version 2.32 et en mettant au début de l'eeprom 02 00 ( region PAL et vitesse lente ).

Salut, La team Wiifree propose (déjà) une nouvelle version 2.41 Je tenais à signaler sur le même site psx-scene le code YAOSM 1.3 - Supports DMS/D2A/D2B chipsets - Wii originals - Wii original imports* - Wii backups - Wii backup imports* - Gamecube originals - Gamecube original imports** - Gamecube backups - Gamecube backup imports** - Gamecube homebrew - All medias (DVD-R, DVD-RW, DVD+R, DVD+RW) - Speed fix (no stuttering) - Automatic region detection - Stealth (well, at least as much "stealth" as any other Wii modchip currently available) Le programmeur utilise un autre langage pour créer son source, il a analysé les autres freecode, et il trouve même des erreurs dans le code wiifree. Bref, c'est une bête et d'après mes lectures et tests, son code semble très stable et peut-être plus "finalisé" (il manque seulement l'audiofix comme pour la wiifree -utiliser make-multiv3 pour faire l'audiofix des jeux GC- ) Moi, perso, j'ai programmé mon 12F629 avec son code yaosm1.3 et tout est parfait

Salut, Même avis.. Baisse la vitesse de lecture des backups de la Wii (medium, voire low), en utilisant dvdconfig ou en mettant 01 à la 2ème adresse de l'eeprom. Grave des sauvegardes sur des DVD de meilleure qualité et en vitesse plus lente. Et tout reviendra dans l'ordre.

Salut, Oui, il faut la reprogrammer. Moi, perso j'ai depuis sa sortie la version 2.32 (le speedfix en vitesse moyenne) en cela fonctionne parfaitement. En tout cas, en ce qui concerne les sauvegardes de Wii et GC, zone PAL. Les dires de 'iznogoud44' jettent un petit doute dans mon esprit ... D'après mes lectures le pic de la wiinja_deluxe (comme la Wiid d'ailleurs) est un 12F683 (le PIC le plus évolué en 8 pattes) qui n'est pas auto-programmable. Alors comment peut-on la mettre à jour ? En théorie cela est impossible, on peut seulement modifier sa mémoire eeprom ... A creuser ;-)

Pour les cours d'électronique, ça m'a fait pareil (et ça me rajeunie pas). Je suis en charente-maritime, sympa pour les huitres mais c'est pas la pointe de la technologie, normal. Pour les moyen-super-marché, c'est justement ce que j'ai fait. Leclerc n'en avait pas, mais je passerai régulièrement. A+

En général je ne suis pas têtu, mais je me suis laissé influencer par mes essais virtuels, désolé . Oui, tu as raison c'est certainement çà (pour l'interprétation par le simu). En conclusion, l'essentiel c'est que tu confirmes que le code wiiskas fonctionne, point final. Il me tarde d'avoir la console (je viens de passé 2h avec mon fils à essayer d'en trouver une, que dalle...) pour faire les essais. Je signale à tous qu'il y a encore une nouvelle version de la wiifree v1.22. Une infos qui doit être importante quel code fonctionne avec le chipset D2B ? (d'après les fichiers textes joints : wiiskas=non ; wiifree=oui ) Merci, de ta patience et de ton écoute. A+

Attention à ce que montre IC-Prog au désassemblage, je te rappelle qu'il croit que c'est un 16F84. D'où le fait que, même après la fin du code (à 2 data de l'étiquette Label_002), il continue à interpréter la mémoire (mémoire non programme mais des données). Il vaut mieux utiliser le programme PIC-Simulator-IDE qui lui permet de sélectionner le PIC correct (je le répète ce prog c'est de la balle !). Oui la derniere valeur est la calibration_osc, il est possible (mais fort improbable) que le programme le lise, mais c'est impossible que le code y fasse un saut ! (la 5ème instruction qui appelle le Label_0002 est un CALL, alors comment revenir dans le programme ensuite, s'il n'y a que des DATA ??). Bref, depuis le début, je pense (en l'ayant essayé au simulateur) que le code wiishas ne fonctionne pas. Mais, ce n'est pas essentiel, car il est certain que le code wiifree fonctionne, et de plus, il évolue rapidement. A+

Salut, A priori on a le même code (du moins au début). Voyons le fin du code : (desassemble de la fin + dump de la fin de la mémoire programme) 1) Le désassemblage de ic-prog ne concerne que le 16F84, mais à priori, pas de pb les instructions sont les mêmes, mais pour le reste ?? en tout cas les zones mémoires son différentes. 2) Avec l'image, tu peux vérifier si ça correspond à ton code (attention, il serait normal qu'à la fin se soit différent, explication plus loin...). 3) On voit bien le 'Label_002' qui est appelé par la 5ème instruction du code (call) 4) Tu dis 'la fin du programme contient du code', mais quel code ? Il n'y a jamais de code à la dernière adresse. En effet, la dernière adresse à 03ff contient ou devrait contenir la valeur de calibration de horloge interne du PIC (une valeur variable du genre, au pif : 405A). 5) Donc, il est possible que pour toi à la fin du code, tu es 1 instruction. Mais ce n'est qu'une interprétation du désassembleur (qui fait ce qu'il peut). 6) Conclusion, jamais un code correct ne fait un saut à la dernière adresse. Comme tu le dis, je suis hors sujet donc j'arrête. A+ à tous et désolé pour la prise de tête. ATTENTION par contrainte de place j'ai dû effacer image+fichiers des précédents post pour libérer le dossier 'fichiers joints'.

A priori, ça roule. "gsm2xtreme" sur Wii-Scene-Forum à voir maintenant sur un site français, actif et à la pointe, j'ai nommé Gueux-Forum :lol: . A+, avec espérons ... des résultats encourageants.

Après une recherche rapide sur le net , voilà infos : Chez ALS Composants pour un 12F629 à programmer avec le code WiiFree "wiifree v1.2 12F629.hex" Chez Selectronic pour un 12F683 à programmer avec le code WiiFree "wiifree v1.2 12F683.hex" ( à noter : je pense que le code pour le 12F683, doit fonctionner sur un 12F675 ) Mais comme tu l'as dit : il faut les programmer ces composants ... et donc faire/acheter un programmateur. Pour le code WiiFree v1.2 voir ICI A+

Salut Abbathdebini, et tout les autres... Encore un mystère de l’électronique !? Car comme je le montre par les démonstrations suivantes (virtuelles il est vrai mais très intéressantes et instructives ) le code Wiiskas bogue. Le code wiiskas beta1b dans IC-Prog : (chacun peut vérifier le début du code avec sa propre version). Ce code dans le simulateur PIC_Simulator_IDE, exécuter 'pas à pas' (on peut le faire en grande vitesse avec un µP virtuel pour voir les signaux sur les pattes) et comme on va le voir, le programme va très très vite merder : En vert --> microcontroleur 12F629 + le code wiiskas En rouge --> l'adresse de l'instruction + l'instruction qui va faire mal... ( en bleu --> l'instruction précédente qui appelle la rouge ) Le code Wiiskas désassemblé par PIC_Simulator_IDE avec en rouge l'instruction qui merde (en bleu celle qui l'appelle) : Cette instruction fait un saut (sous-programme) à l'adresse 3FF. (je vous l'avais bien dit, c'est du rapide, dès la 5ème opération ça va planter) L'adresse du saut est en fait la fin de la mémoire , et évidement à cette adresse il n'y a rien (que des bits à 1 non programmés donc à 3FF). Alors le microcontrôleur s'arrête, et pof ! plantage . Evidement, tout le monde peut vérifier celà, et en profiter pour voir la qualité de ce simulateur. Bref, je ne sais pas si tu as le même code Wiiskas que moi ???, ou, si tu t'es emmêlé les pinceaux dans les fichiers et qu'en final, tu aurais programmé ta puce avec un autre code Encore une fois, tout cela est bien bizarre A+ en espérant que ce mystère soit résolu, ou que cela fera avancer le bidule...

Salut abbathdebinic, j'aimerais avoir et tester (avec le simulateur) le fichier HEX de la Wiiskas que tu t'aies servi pour programmer ton 12C629. Peux tu aussi préciser le chipset de ta console. merci d'avance, A+

Oups Attention : le fichier WiiFree pour le 12C675 (qui est mis par erreur à la fin) est bien le "wiifree v1.1 12C675 (e59d).zip" Le code alphanumérique dans le nom du fichier est Checksum dans ICProg. Salut.

Salut à tous, D’abord bravo pour vos efforts. Je crois que j’ai des infos pour vous et qui peuvent (et qui devraient) vous intéresser. Ayant une petite expérience en modchip (sur PlayStation) et ayant à une époque réalisé mes puces (12C508 / SX28), j’ai lu vos recherches avec attention. Mais, n’ayant pas moi-même de Wii, je ne peux tout confirmer sur les infos suivantes. En 1 : Beaucoup de renseignements très très instructifs sur WiiNews (regarder particulièrement le Forum ‘WiiFree’). http://www.ps2-scene.org/forums/wii-modchips/ En 2 : J’ai depuis quelques jours regardé tous les HEX pour 12C629 passant sur le net. J’ai regardé chaque fichier (wiijacode, wiiskas, wiifree) avec ICPROG. Mais surtout, j’ai essayé chaque fichier HEX avec un super (avis personnel, et chapeau au créateur) simulateur "PIC Simulator IDE" de chez www.oshonsoft.com Et, je peux affirmer que le seul programme qui ne plante pas et qui semble faire quelque chose de sérieux (sortie ou attente de signaux sur les pattes à câbler) est le code de la WiiFree (fichier ). En 3 : Pour mettre le code HEX prévu pour un 12C629 sur un 12C675 (plus facile à trouver sur Conrad ou Sélectronic), il faut absolument faire une modif du programme prévu pour un 12C629 et destiné à un 12C675. Attention ! un peu de technique : La patte 5 (programmée en entrée dans le programme du 12C629) est automatiquement validée en entrée pour le convertisseur Analogique / Numérique du 12C675 (car le Special Fonction Register 'ANSEL' est mis à la valeur x0001111 automatiquement au reset). Il faut donc faire une modification pour mettre à 0 le registre 'ANSEL'. Ça à l’air balèze, mais le PIC Simulator IDE peut désassembler, assembler et tester (avec la vue des pattes du ci) tout programme (explications dans le fichier ). Donc j’ai fait la modif sur le code WiiFree (fichier ). Voilà la balle est dans votre camp pour tester sur une vrai console et pas virtuellement :-) Bon courage.