Archives par mot-clé : donkeykong

REPARATION PCB DONKEY KONG 3

Cette magnifique borne de Donkey Kong 3 a un petit souci : elle ne démarre pas du tout ! L’écran est figé sur un amas de chiffres multicolores.

Quand l’écran est ainsi rempli de Sprites ou Tiles, c’est bien souvent que le CPU est bloqué au démarrage. Je sors donc la PCB de sa cage de Faraday pour pouvoir l’inspecter.

Selon le manuel, le jeu à besoin de 5 volts, -5 volts et 24 volts. Cette dernière tension est embêtante car non standard. Mais après quelques recherches il s’avère qu’elle ne sert qu’à faire fonctionner le compteur de pièces ! Ouf, je me lance donc dans la fabrication d’un adaptateur pour pouvoir lancer le jeu en dehors de la borne.

Je branche le tout et je lance la PCB sur mon supergun. J’arrive sur le même écran fixe que dans la borne.

Enfin presque… les PCBs Nintendo utilisaient des couleurs inversées! Ici je n’ai pas pris la peine de faire un inverseur, ce qui explique pourquoi l’affichage est en nuances de noir.

J’inspecte le CPU, il ne Reset pas et a une bonne horloge. Par contre il y a  8 adresses qui pulsent de façon très bizarre ainsi que la broche WR (write). Elles pulsent pendant un quart de seconde puis se figent à High ou Low un moment et ainsi de suite. Visiblement le CPU tente d’écrire quelque chose mais n’y arrive pas. Il s’agit probablement d’un problème de RAM car ce sont les seuls composants de mémoire dans lesquels on peut écrire. Je sors les schémas et inspecte le circuit CPU/RAMs/ROMs.

Il n’y a que deux RAMs reliées à la broche WR (via un buffer). Je ne vois donc que quatre possibilités :
– une RAM est défectueuse (voire les deux),
– une/des EPROMs reliées à l’Address Bus des RAMs en question est fautive,
– le CPU ou le DMA (Direct Memory Access) sont défectueux,
– l’Address Decoding est mauvais.

Concernant les RAMs, il s’agit d’une TMM2115AP et d’une MB8416A. Je n’en ai malheureusement pas sous la main donc je préfère investiguer sur les autres possibilités d’abord.

Je commence par dumper les EPROMs et je les compare avec MAME. Tout est ok.

Je tente de mettre un CPU et un DMA que je sais fonctionnels. Cela ne change absolument rien.

J’inspecte minutieusement le circuit de l’Address Decoding. Tous les TTLs impliqués se révèlent être bons.

A ce stade je suis quasiment sûr que la panne vient d’une des 2 RAMs. La Fujitsu est unique sur le jeu, par contre la Toshiba TMM2115 se retrouve ailleurs sur la PCB. Je vérifie celle en position 6F (sur le circuit du son) à la sonde logique et remarque que toutes ses broches pulsent correctement. Je décide d’essayer des les interchanger, comme ça si l’une est défectueuse je devrais observer des différences de comportement. Je les dessoude et les swappe.

Moment de vérité : j’allume le jeu et… il démarre !

C’était donc bien la RAM en 7F qui était fautive. Il ne me reste plus qu’à trouver une RAM de remplacement car j’ai des bug de son à cause de la mauvaise RAM (certaines notes manquent dans les mélodies).

Je constate que c’est en fait une simple 16kbits avec le même pinout que les célèbres 6116. J’en profite alors pour tester la RAM en question avec le programmateur d’EPROM qui gère les 6116. Pas moins de 6 broches ne répondent pas, elle est complètement morte !

Je commande un lot de RAM sur le net, mais en attendant que cela arrive j’aimerais  m’assurer que le son marche bien malgré tout. Je cherche dans les PCBs chez moi et trouve une IDT6116 sur un boot de Street Fighter II. Elle fera parfaitement l’affaire.

Le jeu démarre et cette fois les musiques sont complètes ! Je teste les inputs, et malgré la difficulté pour voir ce qu’il se passe à l’écran tout à l’air de marcher, la PCB peut dorénavant rejoindre sa borne !

Bonus Stage

La borne a marché une bonne vingtaine d’heures avant de présenter un comportement bizarre : au bout d’un certain temps de jeu l’écran commence à onduler doucement, puis l’effet s’accélère ainsi que l’amplitude des vagues jusqu’à ce que la synchro soit complètement perdue. A partir de là le son ralentit progressivement et s’arrête…

Ma première intuition est d’aller vérifier la clock du CPU pour voir s’il elle ne ralentirait pas progressivement. Mais l’oscilloscope m’infirme cette hypothèse, l’horloge principale reste bien fixe.

Qu’est ce qu’il pourrait bien y avoir en commun entre la synchro vidéo et le son ? Je scrute les plans et je remarque que le signal vblank est relié aux pins NMI des 2 puces sonores !

Le signal vblank est l’intervalle de rafraîchissement vertical durant lequel le faisceau des canons à électrons remonte en haut de l’écran. S’il vient à changer il est normal que l’écran perde la synchro. Quant au NMI il s’agit d’un Non-Maskable Interrupt, un signal qui a la priorité absolue,  il peut donc affecter le son. Je m’empresse de sonder la piste du vblank, au début tout est normal.

Puis le signal commence à ralentir doucement jusqu’à complètement s’arrêter. Voici notre coupable !

Le signal vblank vient du plateau vidéo. Je remonte la piste à l’oscilloscope et étonnamment les TTLs s’avèrent être bons les uns après les autres. J’arrive finalement à l’horloge principale du plateau vidéo. Chose intéressante, plus je travaille sur la PCB plus la synchro lâche rapidement, le composant responsable de tout ça est littéralement en train de mourir !
Le circuit de l’horloge est enfermé dans un petit boîtier métallique.

Les pattes du quartz sont quand même accessibles donc je tente de les sonder à l’oscillo. J’ai à peine le temps de poser les sondes que l’image perd la synchro et je n’ai aucun signe de vie sur l’oscilloscope. Le coupable est mort…
Un quartz c’est assez robuste,  je ne pense pas que ce soit lui… je soupçonne plutôt un autre composant relié à lui. Je dé-soude le boîtier et selon le schéma le transistor Q1 est le suspect numéro un.

Je le retire du circuit pour le tester. C’est bien lui le coupable !

Je mets un transistor neuf et la PCB part comme en 40… euh pardon, 83.

Voilà, espérons que cela soit la dernière réparation avant un moment sur ce super jeu !

A.M. aka A-M