iznogoud44

sur le montage avec BS170 , verifier que vous ne branchez pas le BS 170 à l'envers, de même verifier que le transisitor soit fonctionnel, car il est arrivé plusieurs fois, que le progr ne marchait pas parceque le bs170 etait hs.

de rien , on est la pour ca, c'est le but primaire d'un forum, ce que certaines personnes ont tendance a oublier.

emelage de pinceaux grandiose , pour résumé , en mode gc, la wii désactive tout ce qui rapport avec le mode wii (wiimote nunchuck manette classique) seul les manettes gamecube et les ports memory card ainsi que le lecteur sd sont fonctionnels, en mode wii , par contre tout est fonctionnel, mais à ce jour , aucune faille du mode wii n'a été trouvé , ce qui explique que tous les homebrews existant ne fonctionnent qu'en mode gamecube, le jour ou une faille sera trouvé , la on pourra peut etre utiliser les wiimotes et autres périphériques du mode wii avec des homebrews.

tuto dispo Pose et mode d'emploi Wiifree créer par moi même, valider et approuver, attention il ne contient pas le mode d'emploi pour apprendre à souder , pour cela entrainez vous

la Wii c'est comme nos femmes, cela ne se prête pas , quoique pour nos femmes, je suis pas sur

bizarre tes tensions, mais bon je n'ai jamais vérifier sur le mien, vu qu'il fonctionne depuis longtemps, pour le reste comme je dis, si tu as l'erreur et que le pic fonctionne sur la wii, alors te prends pas le tête, et laisse comme ca

les 16f n'ont pas de valeur oscall , ils ont une valeur Configuration Word, mais pas d'osccall, car il possèdent une valeur fixe de quartz, préprogrammée en usine, et qui ne varie pas come les 12F683 sauf que ces derniers possèdent en plus une valeur Frequency etc Calibration. question con, vous posez le pic sur votre programmateur avant de lancer le logiciel de programmation, si oui , ne cherchez pas votre erreur 1001 vient de la , il faut lancer le logiciel, indiquez le type de pic puis le poser et effectuer une lecture du pic , ensuite vous le programmez et normalement, c'est ok

@ frozenplot : oui, mais je me suis basé sur les données d'un jeu DS pour comparer les versions entre usa et europe, et je retrouve ce même genre de modification @vida1 , il est logique que presque toues les backups ntsc passent sur une console usa, vu que les usa et jap ont toutes deux , une wii ntsc donc la compatibilité est accrue, de même pour les pal sur wii ntsc, la compatibilité est aussi accrue, pourquoi, tout simplement parce que les isos ntsc usa, ont quasiment tous le même hex, de même pour les iso jap , tandis que nous il n'y a pas de hex représentant notre zone , on en possèdent plusieurs types. @ tout le monde: je viens de rediger une petite news sur Wii Addict à propos d'un utilitaire qui vient de sortir , il pourrait certainement nous etre utile, pour comprendre un peu mieux le phenomène des gamecode, et ainsi peut être avancer un peu plus dans la compatibilité des isos. la news est dispo ici News désolé si cela dérange quelqu'un que je renvoie vers un site autre mais je n'avais pas l'envie de m'amuser à tout retaper voir même copier coller.

tu parles du quel , celui de hardstore ou le simple, si c'est celui de hardstore , oui il est alimenté par le port db9, comme celui avec sb170 sauf que ce dernier , on rajoute une alimentation en 5v pour palier au risque de tension trop basse du port serie, mais normalement celui de hardstore doti comporter un condo ainsi que deux zeners pour fonctionner correctement

non l'alim n'est pas en cause, et pour te le prouver, mon ancien coucou, avait une alim de 200w avec dessu un athlon 64 3500+ et une 6800gs et cela fonctionnait sans problème , donc c'est plutot du coté des fabricants de carte mère , qui ne doivent pas tenir le cahier des charges du port db9 exactement tel qu'il est préconisé, l'exemple type est via, qui à une époque bloquait la limitation des pots usb à - 150 mA, allez brancher un dd externe dessus, le dd n'arrivait meme pas à démarrer, alors que sur d'autres cm , aucun souci, tout cela pour un cahier des charges non respecté.

@ Frozenplot : bah si tu as acces au firmware des puces , wiifree et openwii, les sources sont dispo pour les deux, donc pour le moment, il n'y a rien de possible ni d'impossible, le suel vrai problème est de trouver : qu'est ce qui fait qu'un jeu import fonctionne et pas un autre, ok avec toi pour le fait de qui va trouver, mais faut pas rêver, si c'est une team vendeuse, elle ne fournira pas les sources, ils sont pas fous non plus. @vida1 : le changement effectué à la volée par les puces n'est actif, qu'a partir du moment , ou la puce identifie la region de la backup comme étant différente de celle de la Wii, exemple; "super paper : ntsc à l'origine, si tu patches par le biais de regionfree, wiigion, ou bien WiiFreeBoot, pour modifier l''iso en pal , alors la puce ne verra pas de différence de zone, donc elle lancera le jeu comme etant pal, de même si tu prends la beckup ntsc d'origine, alors la puce verra une différence de région donc, ele appliquera le patch à la volée" dans les deux cas, cela revient au même , sauf que sur ma wii, si je patch les iso alors je me retrouve avec un décalage de l'affichage du jeu , alors que si c'est la puce qui efectue le chgt à la volée , plus de décalage, me demandez pas à quoi c'est du , j'ai toujours pas compris pourquoi cela fait ça, pour en revenir à notre souci, j'ai regardé avec un comparateur hex, les iso dbz2 pal et dbz2 ntsc, et j'ai trouvé plusieurs différences, dont une qui décale l'ensemble des données de l'iso d'une décimale, je n'ai pas essayé de modifier quoique ce soit pour l'instant, le reste de l'iso semble être le même, mais étant donné que cette décimale, décale tout l'ensemble de l'iso , impossible de vérifier la totalité de l'iso. De plus , cela demande un travail de ouf, pour comparer deux iso en temps réel, mes deux coucous en ont ras la gueule , lorsque je lance un comparatif d'iso, c'est 10 minutes facile d'ocupation CPU à 100%, et ce même avec du dualcore (bah ouais les acces disque aussi sont a fond, bien que les isos soit sur deux DD Sata différents). en bref pour résumé , je pense que la solution n'est peut être pas du coté de ce que l'on cherche au final.

programmation avec picprog4u ou ic prog ou encore winpic, peu importe, par contre ne va surtout pas allumer la console pour faire le flash , il faut retirer le pic pour le poser sur le programmateur, et la connexion se fait sur port série, cable simple pas null-modem, pour le fait de pas t'embêter , mes pic et prog me sont revenus à 5 € maxi, donc c'est tjrs moins cher, surtout que les pics , si tu cherches bien , tu peux les avoir gratuitement.

tu veux qu'elle puisse faire le café aussi ta gamecube, non je ne pense pas car le système est complètement différent au niveau de la connectique, il faudrait dans ce cas recréer un programme , cad repartir de zéro, mais si tu arrives à retrouver le lien concernant l'IPL , on jettera un ptit coup d'oeil pour te dire si cela peut se faire.

ok themama, mais alors dans ce cas, le probleme ne vient pas du prog mais du pc , du moins le port serie qui ne délivre pas assez de tension pour monter à 13v , je trouve cela étrange quand même en 3 ans j'ai changé 7 fois mon matériel info, bon ok carte mère , toujours asus, mais cela m'etonne qu'il y ait des differences si enorme, entre plusieurs pc.

ca n'existe pas déja ce systeme , sur les xbox 360 ?

même avec une mise à jour des modchips , cela ne résoudra pas le problème, le souci étant que personne à ce jour n'a trouvé le moyen de passer outre ce souci de zone, et vu que les 3/4 des teams récupère les infos pour les mises à jour de leurs puces sur le net, cela m'étonnerais qu'une team trouve par miracle le moyen de contourner le problème, par contre je pense à quelque chose de débile, si le seul moyen était de faire croire à la wii, qu'elle est d'une zone différente que celle d'origine, cela résoudrait les problèmes, bon j'ai précisé que c'était débile , car le seul moyen pour modifier cela , est d'avoir accès au Fimrware de la wii, ou au moins le NAND, masi vu l'avance qu'on pris WAB er DarkFader en - d'une semaine, je serais pas étonné, que la solution arrive par ce biais.

bah voila , comme quoi il suffit de chercher un peu et l'on trouve toujours la solution à son problème de soi même .

pour ton message d'erreur ne te prends pas la tête, ce n'est aps parce que le log te dit erreur verif que ton pic n'est aps bon, c'est juste qu'il trouve une erreur dans l'hex original et celui de ton pic., essaie quand même ton pic sur la wii, pour certains cela fonctionne pour d'autres non, de plus , jn'arrive toujours pas à comprendre vos problèmes de lecture ecriture verification de pic, je possède le prog de base avec un sb170, depuis deux ou trois ans, et je n'ai jamais , ou très rarement eu ce type de message.

lien sur le forum Wiinewz pour les deux modèles existant le green et le red, au cas ou vous auriez des soucis pour les utiliser le green le red voila en anglais , mais je me doute que vous êtes de pros de l'anglais.

non rien ne t'en empèche, concernant le kit vendu sur hardstore, je trouve ca legerement cher pour un pic de base avec un port serie et 3 resistance ainsi qu'un transistor, sans compter le cout de l'hex wiifree (O €).mais bon si ca vous plait d'acheter quelque chose qui au départ est gratuit, il y aussi foxchip qui en vend.

garantie foxchip ,problème soit de puce, soit de pose de puce certainement, (un clone peut être).

et dire que la wiid est ni plus ni moins qu'un 12F629, renommé, il y a meme un gars sur wiinewz qui vend la même mais sous Wii206, exactement les meme pdf de promo et le meme pcb, c'est bizarre quand même.

E44, je ne peux pas te repondre vu que je vais directemnt au magasin , donc pour la qualite de livraison et de traitement des commandes ??? je n'en sais rien, par contre pour les pics , les acheter pas commander les en sample sur microchip sample , ils vous enverront des pics gratuitement

cablage prog non conforme au plan, reverifie ton cablage, et surtout cote prise db9, l'inversion est frequente au niveau des branchements. possible que ton transistor soit hs.

le code est identique sur les deux, la seule chose quei change au niveau du code est les informations de configuration de l'hex pour un 16F628, l'avantage pour l'instant , il n'y en a pas vraiment vu la taille du code ( à part le fait qu'il n'y a pas besoin de valeur osccal lors de la prg, comme pour les 12F683), par contre si la team developpe plus son code, oui il faudra passer sur 12F683 ou 16F628, obligatoirement, capacité mémoire des pics oblige,en visuel les 12F sont des 8 broches et les 16F sont des 18 broches, donc plus imposant, , il est aussi fiable sur 12F que sur 16F