Bonjour.
Voici une mise à jour de ce WIP de réparation du twin GTI Club.
État des lieux depuis la dernière fois :
- le PCB de droite est "réparé", grâce au changement complet de la video board récupérée sur un Thunder Hurricane
- le PCB de gauche s'est suicidé dans mon garage ; la puce 26V est vue BAD.
Aujourd'hui, je vais tenter de réparer le PCB de gauche.
Avant de commencer ça, je veux d'abord que l'environnement soit "favorable" au bon fonctionnement du PCB.
Ca commence par ça :
- les soudures ne sont pas terribles (mais je suis un peu exigeant)
- il y a 2 raccords sertis : l'un sur le +5V, l'autre sur la masse
(non visibles sur la photo) - il y a une faute d'orthographe à "JAMMA" (ça s'écrit avec deux M)
- le connecteur n'est pas au standard JAMMA
(il y a 4 entrées analogiques, ce qui n'existe pas sur le JAMMA)
Après :
- toutes les soudures ont été refaites
- les 2 raccords à sertir ont été remplacé par une soudure propre
- j'ai mis de la gaîne thermo sur tous les fils : isolation + maintien mécanique
- le mot "JAMA" a été effacé car ça ne pouvait apporter que confusion
Le champ de tests :
Place maintenant à la réparation du PCB...
J'avais passé beaucoup de temps à faire du reverse-enginering sur le PCB, pour comprendre comment sont utilisés certains composants.
Ce reverse-enginering me laisse croire que le problème est très certainement dû à ces cochonneries de switch bus à 5 bits en boitier TSSOP.
Voir
ce message.
En gros, le CPU principal et le DSP ont accès électroniquement à certains mêmes composants mémoires comme le 25V et le 26V.
Électroniquement, les puces choisies pour les 25V et 26V ne disposent que d'un seul et unique accès (1 seul bus d'adresse et 1 seul bus de données).
Il y a donc tout une bordèlerie de "switches de bus" qui permet selon un signal que je n'ai pas cherché à déterminer soit au CPU principal de causer à la puce mémoire (et pendant ce temps le DSP n'y a pas accès), soit la situation inverse (le DSP accède à la puce tandis que le CPU ne peut pas).
J'ai déterminé avec certitude que les puces 25V et 26V partagent :
- le bus d'adresse complet
- les signaux /CS /OE et R/W
Par contre, les bus de données sont bien séparés.
Il s'agit en fait d'une banale association de 2 composants 8 bits pour faire l'équivallent d'un composant 16 bits.
Donc comme la puce 25V est vue OK, je sais que :
- le switch CPU/DSP du bus d'adresse est OK
- le switch des signaux /CS /OE et R/W est lui aussi OK
J'en déduis que c'est le switch du bus de données 8 bits de la puce 26V qui a un problème.
Malheureusement, une puce qui réalise le switch ne sait faire que 5 signaux.
De plus, les 8 signaux du bus de données de la puce 26V vont sur 3 switch différents...
Ayant reçu ma commande de composants chez
Électronique Diffusion, je vais pouvoir en changer quelques-uns :
Pour les curieux, les composants sont stockés dans une bande destinée à une machine-outil chargée de les placer sur les cartes électroniques en cours de montage.
Voir par exemple
cette vidéo, et en particulier à 44 secondes de lecture.
Avant de foncer tête baissée dans le camboui, je décide de tester la carte, pour être sûr qu'en cas de pépin, le pépin est bien dû à ma dernière manip.
Finalement, je me rends compte que cette $%*!§@ de carte s'est
encore un peu plus suicidée dans mon garage. D'une "petite panne 26V BAD", j'ai maintenant les puces 36V et 36T qui sont
BAD ce qui correspond à "coma video board".
Rhaaaaaaa,
truerie de carte !
Finalement, changement radical de stratégie...
La vidéo board du PCB de droite que j'avais décidé de ne pas réparer (la CPU board tourne maintenant avec une autre video board) et de cannibaliser, et bien
je vais finalement tenter de la réparer.
Pourquoi ?
Dans
ce message, j'avais essayé de réparer le problème de la puce 26V BAD en récupérant une puce (une de ces saletés de switch bus 5 bit) sur la vidéo board donneuse d'organes.
J'ai fait 2 tentatives qui se sont soldées toutes les deux par un échec retentissant (d'une panne "26V BAD", je suis passé les 2 fois à "coma video board").
J'avais fini par remettre la puce d'origine et j'avais bien retrouvé ma panne "26V BAD".
J'en conclus que d'une part les 2 puces prélevées était donc déjà HS, et d'autre part, avoir ces puces HS suffit à être en "coma video board".
Je soude donc 2 puces neuves sur la video board ex-donneuse d'organes, et je remets en place les composants que j'avais retirés pour tests :
Je teste avec la CPU board de l'Operation Thunder Hurricane, afin de ne pas risquer d'abimer celle de la GTI Club :
Yeahhh, la chance semble avec moi...
Je n'ai plus le "coma video board" (30Y, 36V et 36T sont OK); les 2 puces BAD sont simplement celles que j'avais retirées pour réparer l'autre video board...
Du coup, transplantation inverse... Je vais reprendre les 2 puces de RAM sur le PCB que je pensais réparer et je vais les remettre sur l'ex PCB donneur d'organe puisque sa réparation semble bien partie.
Je remets la CPU board GTI Club, et...
Tadaaaaaaa ! Toutes les puces sont OK.
J'attends la fin du check ; le jeu doit calibrer le volant et le retour de force...
Rhaaaaa non.... Putain de poisse de bordel...
Le PCB reboote systématiquement en fin de check (alors que tout est OK).
Et là, je suis incapable de résoudre ce problème.
J'ai fait beaucoup de manips, vérifié les tensions de l'alim.
C'est le cul de sac...
Finalement, je décide un nouveau changement de statégie.
La video board qui s'est suicidée 2 fois de suite (OK => 26V BAD => coma)
doit être réparée.
Je sais que les puces 29V et 29U peuvent provoquer un coma.
Je décide donc de les changer, en commançant par la 29V.
Ces maudits boitier TSSOP sont toujours aussi chiants à souder (1 broche tous les 0,6 millimètre).
Je teste immédiatement après avoir changé la 29V...
La vidéo board n'est plus dans le coma.
Seules les puces de RAM retirées sont bien sûr BAD.
C'est parti pour une transplantation inverse de la transplantation inverse...
Si j'avais pu trouver un fournisseur pour ces saletés de puces de RAM Fujitsu, je me ferais largement moins iéch...
Et là miracle... Le boot check passe, le PCB ne reboote pas, le jeu calibre le volant comme prévu...
YEAHHH ! Le 1er PCB est réparé à son tour...J'éteins tout et je branche le 2e PCB qui est déjà réparé :
Oui je sais : l'écran de droite a un problème de géométrie (à froid).
C'est un simple condo qui se fait vieux. J'en ai pour plus longtemps de démontage du chassis vidéo Wells Gardner que de réparation, alors pour le moment je laisse comme ça, surtout qu'un capkit sera installé sur chaque écran.
Les 2 jeux ont bien démarré :
Je passe en mode test pour vérifier la liaison réseau entre les PCB.
Tout a l'air correct :
Finalement, je démarre une partie.
Le jeu indique attendre que l'autre joueur démarre à son tour une partie, ce que je fais.
Le jeu à 2 fonctionne très bien :
Je teste aussi le "TAG race".
C'est un jeu de stock-car où il s'agit de ne pas être le dernier à porter la bombe.
On la refile à son adversaire à chaque collision.
Il reste quand même du taf sur le PCB de gauche :
- de temps en temps, la video board de gauche déconne à mort ; au reset, j'ai la 25V qui est BAD, mais elle fini par tomber en marche ; je suis presque certain que c'est encore une autre de ces merdes de switch en boitier TSSOP qui déconne
- la vidéo bave pas mal, mais uniquement en mode 3D ; ça ne vient pas de l'écran car les mires sont bonnes alors que le "CG check" (test carte graphique) bave
Pfiouuuuu, je suis assez satisfait d'avoir pu avancer la réparation de mon twin à ce point.
Les nombreuses heures passées assis à mon bureau à faire du reverse-enginering sur la video board ont porté leur fruits.
Content je suis !
Reste à savoir combien de temps les PCB vont rester en marche, vue la facheuse tendence au suicidage que j'ai constatée...
