Bonsoir.
J'ai passé mon dimanche complet sur le dépannage de Chelnov.
La vache. J'en bave grave.
Le PCB de Chelnov est composé de 2 cartes : une carte CPU et une carte de traitement graphique.
Après de très nombreuses vérifications et investigations, je me suis décidé ce matin à faire rentrer sur le ring le PCB de Chelnov en état de marche.
Mon idée :
- utiliser la carte CPU qui fonctionne avec la carte graphique du PCB à dépanner
- utiliser la carte CPU du PCB à dépanner avec la carte graphique du PCB qui fonctionne
J'ai examiné à la loupe le PCB malade pour m'assurer qu'il n'y aurait pas de risque d'endommager le PCB qui fonctionne.
Le risque zéro n'existe pas, mais je n'ai vraiment rien trouvé qui soit dangereux.
Bilan des permutations : aucune des 2 configurations ne fonctionne.
Ça veut dire qu'à la fois la carte CPU
et la carte graphique du PCB à dépanner sont en panne.
Là, c'est le démon qui vient de me poser un CBR (coup de boule rotatif). Pfiouuuu, ça pique...
J'ai décidé de séparer le problème en 2 :
- la réparation de la carte CPU en utilisant la carte graphique qui fonctionne
- la réparation de la carte graphique, en utilisant la carte CPU réparée
J'ai l'impression que j'ai dû à peu près tout regardé à l'oscillo...
Il est évident que le jeu démarre à peine et puis tourne en rond.
Le CPU part dans une boucle sans fin où... il ne fait rien.
J'ai bien sûr tout fliqué le CPU (OK), les ROMs (OK), la RAM (OK).
Chose très surprenante : plusieurs bits sur le bus d'adresse du CPU sont inactifs.
J'ai vraiment crû à une panne, mais il est possible que le CPU exécute une boucle infine très courte, genre :
10 faire quelques trucs;
20 faire d'autres trucs
30 si ( pas ( la condition de sortie de la boucle est remplie ) ) alors GOTO 10
40 ...Je me suis rendu compte que le CPU, durant cette boucle, accédait à un des 3 ports d'entrée...
Pour ça, j'ai fliqué tout le décodage du mapping mémoire du CPU, j'ai vu qu'il qu'il cherchait à lire sur le port d'entrée n°2...
À gauche, "CPUAB" signifie "CPU address bus".
À droite, "I/O SEL" signifie "I/O SELECT".
Ensuite, on trouve ça :
Il se trouve que le CPU accède aux entrées-sortie en
lecture, c'est à dire les
entrées.
Le signal INPR (Input Read) est actif quand le CPU veut lire l'adresse correspondante et qu'il valide son bus d'adresse (signal "AS" = Address Strobe).
Un petit tour dans le code source de Mame pour le driver du jeu, et j'apprends qu'il y a l'indication de VBL (Vertical Blank = indique que la carte graphique s'apprête à afficher une nouvelle image) sur ce fameux port n°2.
Et là à l'instant je viens enfin de constater que le CPU principal n'arrivait pas à voir les indications VBL :
Immédiatement, les composants "IC7" et "8M" sont suspects.
Je m'apprêtais à regarder à l'oscillo dans les parages quand...
Là, j'ai halluciné...
Je n'avais même pas remarqué qu'il manquait 5 composants !!!
En fait, j'avais bien vu que certains composants n'étaient pas soudés, mais il est extrêmement habituel que les concepteurs de PCB prévoient des composants sans les souder.
Ça arrive quand le PCB est prévu pour plusieurs jeux (ce qui est le cas du PCB de Chelnov).
En plus, dans la doc, on trouve des références à des boutons 4 et 5 pour les 2 joueurs.
C'est inutile pour Chelnov et même pas prévu sur le Jamma. Donc le fait qu'il manque des composants était tout à fait plausible.
Mon problème, c'est que c'est la première fois que je trouve du travail de dessoudage qui est parfait !
La personne qui a dessoudé ces 5 composants a fait du travail particulièrement propre. Il n'y a aucune trace, j'ai crû que les composants n'avaient jamais été présents.
Voici le PCB qui fonctionne :
À suivre : mise en place des composants manquants !
