dinozore

Lu, On est d'accord, c'est ce que je répondais aussi ++ Dino

Lu, Je pense que tu me comprends mal : Quand je parle de patcher l'octet de région, je parle de la méthode qui justement autorise le dézonage partiel. Quand je parle de le patcher "à la volée" il s'agit du région override des puces si on s'en réfère à la terminologie wiikey, et quand je précise "ou non" il s'agit du patchage physique dans l'entête non crypté de l'iso. Donc je répète, nous sommes d'accord à ça prêt que je dis que le pourcentage de réussite avec un dézonage partiel, même s'il est beaucoup moins bon lorsque l'on convertit vers PAL, est bien plus élevé que tu ne sembles le penser Jète donc un coup d'oeil <par ici> . Bon ça c'était la précision sur le dézonage partiel, mais pour ne pas te perdre kikinini (dis donc faut pas s'tromper sur le premier "n" hein ! ), les réponses à tes questions sont dans l'ordre : - puce + geckoOs - oui ++ Dino

Lu, Etonnant... Si j'ai le temps je vérifie ça ce soir avec une v3 et une v1-spi_greffé que j'ai gardées pour échantillon (plus de v2, j'ai eu besoin de passer la dernière). ++ Dino

Re, @deuiz> Pareil que sur 360, verbatim mkm001 (meilleurs que les 003 lors de mes tests persos). Mon backup de ssbb date du début où on a su extraire le dl et il bootait de la même façon avec l'ancien montage qu'avec le nouveau, c'est à dire normalement. Je teste systématiquement ce jeu. Graveur pioneer. ++ Dino

Lu, @deuiz> Aucun retour sur un problème du genre en ce qui me concerne. Lors des tests de mon côté ça a toujours était au moins aussi vigoureux et mes -R de tests se lancent sans soucis. Essaye de regraver ton backup, voire tente avec une autre configuration de gravure. ++ Dino

Lu, J't'avais dis que c'était ça ++ Dino

Lu, Ouais comme avec la yaosm quoi ... ++ Edit: Woups désolé, j'ai fait un pti déterrage gentils. Faut dire que ya tellement foule dans la section wasabi ... Dino

Lu, Et ben une bonne chose de faite ! ++ Dino

Lu, Je suis d'accord avec toi, sauf qu'avec une puce sans hbc n'y rien d'autre on a quand même ~ une chance sur 3 en pal de lancer un import avec le patchage à la volée (ou non) de l'octet de région. La compatibilité est plus grande entre ntsc-us et ntsc-j. Bon c'est pas terrible comme probabilité et ça n'offre pas le choix des langues mais c'est toujours ça. ++ Dino

Lu, Merci pour l'info Pour info le disque résultat est trucha signé donc hbc ou firm <= au 3.2 obligatoire. ++ Dino

Lu, Oui oui J'avais déjà vérifié lors de l'annonce du point alternatif sur la borne de la résistance justement. Comme déjà dit, c'est surement la résistance qui change la donne. Sinon de mon côté, une petite dizaine de montage sur d1a ce weekend (chipsets divers) et pas le début d'un soucis. Je pense que l'affaire du bug d'éject est réglée ++ Dino

Lu, Moi non plus, Xp + carte via + slax. Sur deux 79 (j'en vois plus beaucoup) faits avec cette méthode, aucun soucis à signaler : c'est passé comme une lettre à la poste. ++ Dino

Re, oui, mais sur quel chipset ? (je me doute, mais c'est juste histoire que tout le monde comprenne la même chose) Tu as raison, je n'ai pas été clair. Donc pour précision : - J'ai toujours pris le G directement sur le chipset, l'un ou l'autre. - Avant lorsque je le prenais sur le D2x j'avais des bugs aléatoires même si le dernier montage que je faisais donnait de très bons résultats (cf <page 6> ). - Maintenant que tout dernièrement je le prends sur le D1A, je n'ai pas rencontré l'ombre d'un bug d'éject. Après c'est vrai que c'est encore trop frais pour tirer une conclusion, mais bug d'éject juste amoindri ou complètement disparu, il s'agit pour l'instant sans conteste pour ma part du meilleur montage. Ce weekend je vais pas chômer et je vais continuer sur le montage D1A. Je vous tiens au courant si je rencontre ou que l'on me fait part d'un bug d'éject. ++ Dino

Lu, Bon finalement je les ai faites hier soir et il n'y en avait que deux. Même résultat que dans mon précédent post : absolument aucun bugs d'éject lors de mes divers tests. Sinon pour info, comme Mr Belou, je soude toujours directement sur chipset et le bug était là aléatoirement. ++ Dino

Lu, Le plus simple : Soude un câble entre la borne de la résistance cms et la 3ème patte à plat Soude ensuite le câble de la wiikey sur la 3ème patte à la verticale cette fois-ci. C'est très facile à faire quand on en a l'habitude mais apparemment tu ne manies pas le fer avec une grande aisance donc si tu ne te sens pas ou si tu galères arrête avant qu'il n'y ait plus de dégâts et demande à quelqu'un d'expérimenté de te le faire. Ps: Change ton titre pour un plus explicite stp. ++ Dino

Lu, Tout à fait, c'est ce que je voulais dire hier soir mais je rencontre en ce moment de gros soucis de connexion. Quant au point alternatif sur le D1A, j'en ai monté 4 comme ça pour voir depuis que j'ai lu l'info et premièrement ça fonctionne, et secondo je n'ai eu aucun retour sur un bug d'éject alors que d'habitude quand il y en a un ça ne loupe pas dans les deux heures qui suivent la récupération de la console. J'en fait trois autres comme ça ce soir pour voir. ++ Dino

Lu, Ce qui est connu c'est que certains pcb posent des soucis d'éject. En revanche tous sauf les d2nothing (aussi appelé d3) sont puçables. J'ai rencontré une fois sur un lecteur précis un soucis très bizarre avec des wiikey 2 9 fils pcb blanc (les toutes toutes premières avec le tout premier firmware) qui s'est solutionné par un remplacement en d2pro. Ca n'était qu'un cas isolé et depuis aucun soucis à signaler ++ Dino

Lu, @bob7> T'es sûr d'avoir lu les messages précédents ? ++ Dino

Lu, Le problème n'est pas directement lié à la wiikey 2 mais au lecteur et au montage. C'est aussi vrai qu'on le rencontre plus sur la wiikey que sur la d2pro par exemple (et encore les v4 auraient le même soucis) mais c'est pas comme les wazabites v1 ou le problème venait directement de la puce. Après je pense aussi que le soucis pourrait théoriquement être amoindri par un meilleur firmware comme on l'avait vu sur les d2pro spi inférieures à la v4 avec d2c2, mais à mon avis il ne faut pas s'attendre à un miracle. ++ Dino

Lu, @iznogoud> Du calme, personne t'a agressé. Dans le cas présent il n'y a même pas besoin de tester, ça se voit à l'oeil nu. Mais si tu n'es pas convaincu tu peux toujours tester et nous dire ce que ça donne. ++ Dino

Lu, Tout à fait, ça m'étonnerait que ça lui plaise... ++ Dino

Lu, Tout d'abord si le backup de Mario Kart fonctionnait avant c'est que tu étais déjà au moins en 1.9g. - configdisc-1.2b (non officiel) --> region_override ON C'est bon j'ai modifié après j'ai restart > Ok - maj wiikey-1.9g/s j'ai pris la S pour le maj c'est bon il a bien pris il restart automatiquement on peut le verifié comment s'il a bien pris en compte > Faq n°19 : On peut pas autrement que par déduction logique - configdisc-1.2b (non officiel) --> region_override ON c'est fait j'ai restart > Ok - configdisc-1.3/4 (officiel) j'ai pris la 1.4 mais que dois je faire pour configurer une wiikey mise à jour en 1.9s s'il a bien pris en compte > Faq n°2 : Tu utilises le setupdisc 1.4 (=1.9s) mais comme expliqué les paramètres par défaut fonctionnent correctement - maj wii-3.2 ou supérieur cette etape n'est pas obligatoire donc j'ai laissé en 3.2E peut qu'il faut l'update non? > Faq n°5 : Mais pour Mario Kart la 3.2 suffit Lis aussi la Faq n°13 en entier et profite en pour nous préciser la manière dont se manifeste ton erreur. PS: Change le titre de ton post sinon tu vas te faire taper sur les doigts, genre "Wii 3.2E, problème après maj Wiikey 1.9s" pour le titre et "Mario Kart ne fonctionne plus" pour le sous-titre. ++ Dino

Lu, @bitonio> Pour un nettoyage complet du chipset, tu as quelques exemples de disponibles notament en <page 4> de ce même post celui de bugess ou bien encore le miens en <page 6> . Pour le problème d'éject avec clip, il est parfois bien pire qu'en montage filaire (cad systématique) contrairement à ce que tu sembles penser. Regarde en section wiiclip. Et puis il ne me semble pas qu'ils récupèrent la masse en plusieurs points, ils se contentent de la prendre directement sur le chipset en patte 17 côté centre. Du moins ceux que j'ai pu observer (wiiclip ou wiisilon). Pour le coup de tresser les câbles, c'est bien connu c'est dans le but d'éviter le <phénomène de diaphonie> . Et pour la section/longueur des câbles tu peux trouver chez xav un <article intéressant> . Après j'ai personnellement pu constater à plusieurs reprises que la longueur du câble pouvait changer la donne. Quant à la section, de l'awg 30 est largement suffisant pour les courants ici concernés (enfin au moins selon les spécifications) donc en théorie on ne fait que rajouter de la résistance à trop vouloir augmenter la section mais bon les distances sont tellement courtes ici qu'à mon avis c'est kiff-kiff. ++ Dino

Lu, @Mr Ness> Merci c'est gentils Bah j'avais trois pcb nus ce weekend dont un pincut fait en yaosm et deux en wiikey 2 donc y'a une chance sur deux pour que ce soit <celui-ci>, de toute façons ils étaient jumeaux sur le montage. ++ Dino

Lu, C'est ça, la puce n'intervient qu'au niveau du lecteur donc ne peut patcher que le zonage brute alors que certains jeux nécessitent un patchage du mode vidéo. Or celui-ci ne peut pour l'instant n'être obtenu que logiciellement. Ce qui se fait d'habitude avec une puce c'est d'employer geckoOs pour le dézonage total. ++ Dino