[WIP 100%] Réparation d'un PCB Thunder Hoop

J'ai acheté pour pas très cher un magnifique PCB de Thunder Hoop. Un synmpathique jeu de 1992 de Gaelco. Pas très connu parce que tardivement et mal émulé. En plus du cryptage des RAMs graphiques, cette petite horreur fait des tests cachés de timing entre le circuit graphique et le CPU, et se permet de corrompre la RAM volontairement quand un truc ne lui revient pas.

Alors déjà, j'ai reçu ça vendredi dans le plus petit carton que j'ai eu l'occasion de voir dans ma courte expérience d'acheteur compulsif de jeux pétés sur eBay. Une boîte de chocolats:



Dedans, un PCB qui n'a pas l'air d'avoir déjà été réparé, mais qui n'a pas l'air non plus d'avoir été conservé à l'abri de la poussière.
Premier branchement..



Le PCB ne consomme pas particulièrement de courant, mais il affiche un joli motif (toujours le même), avant de passer sur fond blanc et de ne pas en bouger.



Je commence par les basiques, avec le contrôle du pin de RESET du CPU (rien à signaler), et le pin d'horloge...



Mais rien à signaler, un beau signal à 12MHz.



Côté activité des bus de données, on note une seconde d'activité, avant que tout se fige. Pour relever l'activité, je sonde la broche A1 (il n'y a pas de broche A0 sur le 68000, il ne sait lire que des adresses paires). Cette broche va changer quasiment à chaque instruction ou entrée/sortie. C'est un bon indice d'activité.
Je vois donc des oscillations, puis plus rien. C'est l'occasion de voir qu'il n'y a pas de circuit de watchdog sur ce jeu, sinon il redémarrerait en boucle.



Je n'ai encore jamais vu ça, alors je commence par me raccrocher à ce que je connais, et j'essaie d'attaquer la piste des EPROMS de jeu corrompues. Vu la tête des autocollants de protection des fenêtres, quelqu'un a dû se poser la même question et essayer de les reflasher.



Passée la bizarrerie de la taille différente des deux EPROMS alors qu'elles se partagent chacune la moitié des mots de 16 bits lus par le processeur, je décide de comparer mes dumps avec les sets de MAME.
D'habitude, j'utilise des sites sur lesquels d'uploade les dumps. Là, je tente une nouvelle piste, avec le mode ROMIDENT de MAME. Il lit mes ROMs et le recherche parmi les signatures des jeux qu'il connait.
Et il reconnait bien mes ROMs, il va falloir trouver autre chose.



Etant donné que je suis parti pour passer pas mal de temps à étudier les différentes pattes du CPU, avec lequel je n'ai pas l'habitude l'avoir des problèmes, je décide de créer une étiquette avec LibreOffice et je vis un calvaire parce que le copier-coller est plein de bugs!



Le 68000, dans sa configuration présente, a des cycles de lecture-écriture durant lesquels il se met en attente de ses périphériques. Plutôt que de présumer que les opérations sont terminées, il se bloque en attendant qu'on lui dise qu'elles le sont.
En analysant les broches de contrôle, j'en déduis qu'une opération d'écriture est demandée, et que le périphérique n'a pas répondu...



Le concept de memory mapping arrive à grands pas...
Pour faire simple: le 68000 accède à des zones mémoire par leur adresse. Le matériel peut associer des zones mémoire à des périphériques. Par exemple, suivant à quelle adresse on lit des données, on pourra accéder à de la ROM, à de la RAM, aux boutons des sticks ou au processeur audio....
Les différentes zones mémoire sont souvent auguillées par un circuit propriétaire, un CPLD ou dans le cas présent, un GAL.
Il est ici, juste à côté du CPU et de la RAM système:



Je fais un plan des lignes de poids fort du bus d'adresse, et elles convergent bien vers le GAL (le goût):



Histoire de ne pas me taper la reverse engineering du mapping mémoire, je regarde directement dans le code source du driver Gaelco de MAME!



Je prends chacune des zones mémoire avec leurs plages d'adresse, et je calcule la valeur correspondante pour les bits de poids fort du bus d'adresses. Ca me donne des masques d'adresses à peu près distincts (pourvu qu'il ne s'agisse pas d'un problèmes de contrôles, parce que c'est la foire dans cette zone).



Ensuite, il ne me reste qu'à lire la valeur des différentes lignes du bus d'adresses pour savoir à qui le CPU parlait quand il s'est arrêté!



Je note un à un les bits que je lis sur le bus d'adresse, et je les colle sous ma grille. Et bingo, le CPU essaie d'écrire dans le 1er mot de la Sprite RAM!



Je fais ensuite des sondages sur les différentes zones de RAM (il y en a un paquet: RAM système, vidéo RAM, screen RAM, Palette RAM, Sprite RAM) pour trouver les puces qui s'occupent de la Sprite RAM.
J'essaierai de montrer ça dans la vidéo finale si elle n'est pas trop longue!



Ensuite, je lis les signaux de contrôle des 2 puces de RAM et je trouve le signal de lecture bloqué actif. C'est bizarre, parce que le CPU demande une écriture au moment où il se bloque.
J'en déduis qu'il y a un souci avec le contrôle de ces puces, et je commence à suivre les pistes (littéralement) au multimètre en mode continuité.
Pour m'aider, j'utilise des couches dans Paint.Net pour représenter les différentes zones, les puces qui entrent en jeu et les fils entre les puces. Et le moins qu'on puisse dire, c'est que les signaux voyagent! Ils peuvent faire un aller-retour d'un bout à l'autre du PCB pour arriver à destination!
Après un passage dangereux à 2mm du CPLD dont un souci aurait signé la mort du PCB, un via passe dessous et le signal retraverse le PCB. Je perds sa trace un bon moment après une puce de buffer et je commence à dédespérer de le retrouver.
Du coup, je me dis qu'un autre GAL doit être dans la place, et je cherche la position des GAL sur la carte. Et Bingo, il y en a un pas loin des puces de Sprite RAM et l'une de ses lignes de sortie est raccordée aux broches de lecture des RAMs!

Voilà donc le beau parcours entre la Sprite RAM et le GAL:



Je rallume le jeu et je sonde les broches de sortie du GAL (elles sont en haut sur tous les GAL, a priori) et je trouve des tensions toutes pourries de 2V! Et 2V, ce n'est pas près de 0V, ni de 5V. Ca sent clairement pas bon (comme le furet de @Richter).



J'en déduis que le GAL est mort. Ca tombe bien, j'en ai acheté des brouettes de toutes les générations quand je bossais sur les synchros vidéos et le hack Hyper Olympic.
J'ai ici 2 générations. Du vieux Lattice qui consomme à bloc et qui est lent, et du récent Atmel qui consomme aussi beaucoup mais probablement moins, et qui est bien plus rapide.
La génération Lattice est probablement plus proche du GAL à remplacer, mais je vais tenter le coup avec le modèle récent!



Un GAL, c'est de la logique programmable. Le souci, c'est qu'il faut avoir le programme à mettre dedans! Sur un bootleg, c'est quasi mission impossible. Mais sur un jeu original, il y a toujours un passionné qui est passé par là pour en faire un décodage "brute force" et en proposer une reprogrammation! Petite visite sur PldArchive, le site providentiel:



Et c'est super, la programmation des GAL de ce PCB est disponible!
Reste à touver laquelle m'intéresse, parce qu'il y en a 4...



Les références des puces, c'est la plupart du temps une affaire de colonnes et de lignes...
Ici, J



Et 16



Allons-y donc pour le prog 16J, mais je les récupère tous au cas où un jour...



Hop, le GAL dans le programmateur à tout faire...



Ca se programme en quelques secondes parce qu'il n'y a que 2ko là-dedans...



Puis il faut dessouder l'ancien GAL. Je commence par marquer les broches au marqueur. Parce que c'est pénible de dessouder, mais ça l'est encore plus de dessouder la mauvaise rangée de broches.



Après, comme souvent, pistolet à dessouder + finition à l'air chaud parce que je ne m'en sors pas et je ne veux pas arracher de pistes.



Et c'est pas si sale à la sortie



Même si après c'est moins beau, je remplace le vieux GAL par un support



Et je balance mon nouveau GAL dedans



Je teste, et...



Ca démarre, je me fais couillonner en pensant que le jeu est bloqué sur l'écran de démarrage parce qu'un DIP est en position test, et c'est parti, on peut y jouer!

Par contre, je n'ai pas de son. Juste un souffle.

A suivre donc avec le débugage du circuit audio. Tout est à base de OKI6295, comme sur World Rally, sur lequel j'ai passé pas mal de temps à comprendre comment ça fonctionne!
Cette puce est souvent utilisée sur les PCB de cette époque pour jouer les samples (stockés en ADPCM sur des  ROMs dédiées), tandis que les musiques sont jouées par un couple Synthé Yamaha / ADC Yamaha. Ici, il n'en est rien. Les musiques sont aussi jouées par le 6295.
Résultat: des musiques échantillonnées de qualité pourrie compressées à bloc et composées de boucles courtes.

Au boulot, je manque un peu de courage pour la suite

Le son est donc géré par le OKI 6295 ici présent.



Je commence par vérifier son signal d'horloge, généré en interne à partir d'un résonateur externe à 1MHz.



Et la fréquence que j'observe est instable et tourne autour de 6MHz. Ca ressemble au souci de World Rally quand j'avais brûlé le résonateur.



Et le résonateur, c'est ce petit bonhomme bleu.



Mais grâce à World Rally, j'ai un résonateur de rechange en réserve!



Une fois le résonateur remplacé, je refais une mesure de fréquence...



Pas mieux, cette fois, c'est 7MHz au lieu de 6MHz.



Je vais voir ce qui se passe si j'impose la cadence. Je ressors mon générateur de signaux, et je le programme pour un signal sinusoïdal à 1MHz, identique à celui que je devrais observer aux bornes du résonateur.



Je retire le nouvel oscillateur, et je le remplace par une résistance qui court-circuite les 2 bornes du résonateur, et je coupe la patte de la résistance.
Je dispose maintenant d'un point d'entrée dans la puce OKI 6295 à travers une résistance de 10kOhms parce que j'ai quand même un peu peur de tout cramer.



J'observe ensuite la sortie du DAC intégré à la puce.



J'observe un signal très haut, d'environ 11V, pour une puce alimentée en 5V. Quelque chose injecte une tension dans sa sortie analogique. Pas étonnant que la puce se comporte bizarrement!



La sortie est reliée à un ampli op parmi les composants de la section d'amplification.



Il s'agit d'une entrée non inverseuse. Je ne vois aucune raison valable pour que cette entrée soir portée à une tension de 11V à l'initiative de l'ampli op!



Je dessoude l'ampli op...



Je mesure le signal de sortie du DAC une fois l'ampli op retiré...



Et voilà un signal totalement dans les normes!



Si je relie ma sonde audio sur cetet sortie, j'entends la musique du jeu!



Je remplace l'ampli op par un qui fonctionne!



Et voila le son qui fait son entrée dans le jeu. Par contre, on dirait que ça jour les échantillons un peu au hasard. La musique n'est pas la bonne, les effets spéciaux sont bizarres, ...



Je remets à présent l'oscillateur en place, pour voir si la puce sait le faire osciller (vu qu'on n'injecte plus 12V dans sa sortie!)



.. et la réponse est non. La musique par à fond les gamelles, on tourne encore beaucoup trop vite.
Si j'injecte mon signal à 1MHz tout près de l'un des deux condensateurs du circuit du résonateur avec mon générateur de signaux, le signal d'horloge repasse à pile 1MHz jusqu'au prochain démarrage du jeu.



Après quelques tatonnements (et après avoir remplacé les deux condensateurs) et un peu de lecture sur les circuits oscillants, je me dis qu'il ne serait pas idiot d'intégrer dans le circuit un nouveau condensateur, en parallèle avec le résonateur. J'intègre alors l'un des condensateurs que j'ai remplacés, et l'oscillateur démarre à la bonne vitesse à chaque mise sous tension.



Sans perdre plus de temps, j'ajoute ce 3ème condensateur au dos du PCB, entre les pattes du résonateur.



J'ai à présent une fréquence stable et une sortie audible, mais j'entends des sons qui n'ont rien à voir avec l'action.
Avant de me plonger dans le debugage du bank switcher pour le OKI 6295, je fais tout de même une vérification des EPROMS qui contiennent les échantillons.



Pour ne pas les mélanger, je les marque, puis je les sors du circuit.



Après analyse, les dumps sont corrects. En dernier recours, je tente le pari de l'échange d'EPROMs.
Et c'est le coup de bol. En l'absence de son, un ancien réparateur avait dû essayer de réparer des choses, avait sorti les EPROMS, et les avait interverties!



Et voilà un jeu qui marche impec!



Pour finir, je lui ajoute quand même des pieds!



J'aurai remplacé un GAL, un ampli op, ajouté un condo sur le résonateur, et échangé deux EPROMs de la section audio.
Je me suis fait une petite partie (4 crédits), et c'est franchement sympa. Ca fait effectivement pas mal penser à Toki dans le déroulement!

C'est toujours aussi impressionnant ce que tu fais, et le temps que tu prends à tout décrire c'est fou.

Combien de temps ça a pris à tout réparer ? Si on enlève le temps de tout documenter ?

Et qu'est-ce que tu ne saurais pas réparer ?

T'es un ouf bouz.
En plus de ton talent, je vois que tu es aussi un petit malin: jamais j'aurais pensé à intervertir les 2 EPROMS du son !!
ça ne risque de rien abimer ce genre d'inversion ?? Par exemple si tu remets mal des EPROMS sur un CPS1 ou 2 ?? Tu peux pas les flinguer ??

Super jeu, un des meilleurs toki like

Franchement bravo ! C'est du chinois pour moi, mais ça doit être passionnant quand on maitrise le sujet comme toi

et lol @furet :D

anzymus a écrit:Combien de temps ça a pris à tout réparer ? Si on enlève le temps de tout documenter ?

Sur ce coup-là, le problème de démarrage était très technique, mais la piste était plutôt logique. Ca fait pas mal d'étapes, mais ça avance lentement mais sûrement. Je crois que je l'ai réparé en 3 soirées.

Pour le son, je connaissais très bien le circuit audio à base de 6295 parce que je l'ai creusé dans tous les sens pour réparer World Rally (du même éditeur). Du coup, ça s'est fait en 2 soirées parce que le résonateur m'a rendu fou!

anzymus a écrit:Et qu'est-ce que tu ne saurais pas réparer ?

Eh ben par exemple m'occupe d'un Combatribes depuis 2 ans (bootleg, sans les plans), il était complètement mort, et il me reste encore pas mal de boulot. J'ai dû y passer des dizaines d'heures.
Et globalement, si c'est une puce custom ou un CPLD qui est mort, c'est quasi foutu. Il faut faire un échange avec un autre PCB, mais vu que je n'ai pas de stock, c'est mort pour moi!

theWave a écrit:T'es un ouf bouz.
En plus de ton talent, je vois que tu es aussi un petit malin: jamais j'aurais pensé à intervertir les 2 EPROMS du son !!
ça ne risque de rien abimer ce genre d'inversion ?? Par exemple si tu remets mal des EPROMS sur un CPS1 ou 2 ?? Tu peux pas les flinguer ??

Absolument pas si les 2 EPROMS ont la même capacité et le même brochage.
Tu peux même échanger les puces de sprites ou de décors (ou les enlever) pour voir ce qui se passe du moment qu'elles sont de taille équivalente.
Un PCB, c'est pas un PC avec un disque dur. S'il manque une puce, du moment que ce n'est pas la ROM qui contient le code du CPU, il y a de bonnes chances que tout continue à fonctionner sans que le CPU s'en aperçoive.

snkspirit a écrit:Super jeu, un des meilleurs toki like

J'ai commence à y jouer ce week-end (j'ai fini de le réparer vendredi soir), je me fais déglinguer par le boss du 2ème niveau. Par contre, vu que je joue en 1 crédit, je refais les niveaux en boucle et je les connais déjà par coeur . Je le trouve plutôt plus facile que Toki pour le moment.

Richter a écrit:Franchement bravo ! C'est du chinois pour moi, mais ça doit être passionnant quand on maitrise le sujet comme toi

C'était la première fois que je tombais sur un problème de CPU bloqué comme ça sur une ressource, c'était très intéressant, en effet!
Et c'est encore mieux quand j'ai ce qu'il faut pour réparer et que je ne suis pas frustre à attendre des composants de Chine .

Richter a écrit:et lol @furet :D

C'était pour voir si tu lisais

... et juste parce que j'ai réalisé par hasard que je n'avais pas mis la vidéo de réparation dans ce topic, et que c'est couillon...