Pink Sweet - Cave CV1000
Un Pink Sweet confié par need#. La direction bas du joueur 1 reste bloquée et certains contrôles ne répondent plus.
La PCB est en bon état :
Pour commencer je remarque que des condensateurs céramiques CMS ont été remplacés et qu'un pont a été fait à l'aide d'un strap de 0,15mm sur une des pistes allant au CPU :
A noter aussi, quelqu'un a fait une croix sur le CPU (un précédent réparateur ?) :
Un commentaire Pr. Jones ?
Pour commencer, je regarde ce qu'il se passe sur la broche 18 du peigne JAMMA (P1 direction bas) -> le signal reste bloqué en bas à 0V alors qu'il devrait être à 3,3V !
Et non pas à 5V car même si ce système est alimenté en 5V pour rester compatible avec la norme JAMMA, un régulateur est chargé de diminuer la tension pour alimenter le jeu en 3,3V.
Cela vient du fait que les composants "modernes" fonctionnent en 3,3V et non plus en 5V.
je remonte très rapidement la piste jusqu'au CPU (SH7709S Renesas QFP 208) broche 188, car sur le chemin se trouve uniquement deux résistances et un condensateur.
Je vous laisse imaginer la vulnérabilité du CPU en cas de mauvaise manipulation du connecteur JAMMA.
La broche 188 du CPU se situe ici :
Cette broche correspond à MCS[0]/PTC[0]/PINT[0] soit 3 possibilités d'entrées/sorties selon la configuration du CPU :
- Mask ROM chip select 0 (MCS#)
- Input/Output Port C 0 (PT#)
- Port interrupt 0 (PINT#)
Tous les contrôles sont câblés sur les entrées/sorties "PTL/PTC/PTD" du CPU. Ces entrées sont lues et stockées dans 3 registres de 8bits (emplacement de mémoire interne du processeur) correspondant à chaque port (L/C/D).
Registre du port C (PCDR)
Des instructions contenues dans la ROM du programme principal sont exécutées pour lire ces registres. Ce qui permet ensuite d'exécuter d'autres instructions correspondant à l'affichage des interactions avec le joueur.
Dans le cas présent l'état du registre PCDR (Port C) se retrouve avec son bit de poids faible (PC0DT) activé en permanence. Par conséquent à chaque boucle d'instructions lisant le registre PCDR, le programme interprète le contrôle bas du P1 toujours activé.
Pour valider une éventuelle panne sur le SH3, je retire le pont qui a été fait sur la piste menant au CPU. Ce pont n'était pas là par hasard car il est sur la piste qui correspond à la direction bas du P1 et allant à la broche 188 du CPU :
Le pont laisse place à une coupure dans la piste, je pense que le réparateur précédent à utilisé cette technique pour isoler le signal suspect.
Ensuite je sonde le signal du coté CPU après la coupure de continuité. Il est bas (0V) alors qu'il devrait être haut (3,3v), ce qui veut dire que cette entrée/sortie du CPU est HS !
Professeur ?
Il faut maintenant commander des CPU et attendre...
...
Quelques jours plus tard la commande arrive...
Malheureusement les CPU ont été emballés à la "one again" et des broches ont souffert durant le transport.
On est dans une tolérance au dixième de millimètre et les broches sont pliées... Fantastique !
C'est parti pour une séance de redressage qui pique les yeux !
Fini ! Au dodo avec la migraine...
Le lendemain je fait tomber le CPU HS :
Et le remplace :
Je m'occupe ensuite de ces condensateurs CMS qui ne sont visiblement pas d'origines :
Vu que je ne connais pas leur valeur par défaut, je dessoude le voisin et le teste :
130 nanofarads !
Les deux intrus n'ont effectivement pas la bonne valeur car il plafonnent à quelques dizaines de nanofarads.
Je les remplace par des 130nf :
Ensuite je décide de contrôler les résistances en réseau de 100Ω qui sont juste en dessous :
Sur certains éléments je trouve des valeurs de 350Ω à 60Ω là où je devrais trouver 100Ω.
Aucune chance que les contrôles qui passent par ces lignes fonctionnent normalement.
Au passage je vérifie les réseaux de résistances voisins. Ils ont quasiment tous des anomalies dans leurs valeurs allant de quelques Ω à plusieurs kilo Ω ! Qu'est-il arrivé à cette PCB...
Je lance quand même le jeu pour vérifier... Et comme prévu, certains contrôles ne fonctionnent pas. Par contre la direction bas du P1 fonctionne normalement, petite victoire...
Je dessoude une des résistances en réseau pour relever les dimensions du boîtier et trouver de quoi les remplacer.
Après moult recherches sur le net je passe commande pour :
- résistances en réseau, package 2406, x8 éléments, valeur 10KΩ, référence CAT16-103J8LF.
- résistances en réseau, package 2406, x8 éléments, valeur 100Ω, référence CAT16-103J8LF.
Quelques jours passent et je suis enfin prêt pour attaquer la suite :
Un fois toutes les résistances retirées :
Il faut ensuite ressouder tout ça, et c'est pas gros :
Un décollement de la rétine plus tard... Tadam !
Je lance un test, et...
Écran NOIR !!! Mais quoi ? Sérieux ?!!
Du son mais pas d'image... L’effroi m'envahit... Et si c'était le FPGA qui venait de claquer ?
...
Game Over ?
...
...
...
Bah en fait : NON ! C'est le PVM qui vient de caner ! LOUL !
Je savais bien qu'il ne fallait pas faire confiance à Sony.
Je balance cette saleté surcotée de PVM et je ressort mon bon vieux moniteur Atari :
On en a fait du chemin ensemble ❤️.
Je lance le jeu -> écran titre -> cool :
Self test normal...
Tous les contrôles P1 et P2 sont OK !
Chouette !! Je me dis que c'est bon. Mais il reste l’ultime test : lancer une partie.
...
Je mets un crédit, et :
Pourquoi tant de haine ?!? Qu'est-ce que je t'ai fait ?! Ta mère chez Infogrames !
Après recherche, il s'avère que ces systèmes seraient équipés d'une protection empêchant de créditer si jamais l'entrée du crédit reste activée trop longtemps !
Et oui quand la pièce chute et active le micro-switch du monnayeur, ça va vite !! Alors que si on essaie de l'entuber ça peut être plus lent. A noter que d'autres jeux possèdent la même protection, tel que Cadash (1989) par exemple.
Je lance donc une partie en effleurant rapidement le bouton "crédit", et :
Un CV1000 sauvé ! Je suis vraiment content d'en être venu à bout, et need# est au paradis !
