Symptômes : ne démarre pas.

Esthétiquement, les coques sont en état moyen, on dirait qu'elles ont pris l'eau ou beauucoup d'humidité. La A-Board et la B-Board sont finalement en bon état cosmétique, vierges de toute intervention :

En allumant le jeu, je suis accuilli par un écran fuschia fixe :

Un test croisé me permet déjà d'écarter la A-Board qui s'avère fonctionnelle, le problème se situe sur la B-Board. Le jeu est probablement suicidé : la pile rechargeable qui maintient la clé de décryptage en RAM est probablement vide, et la clé, volatilisée.

Fort heureusement, la batterie n'a pas coulé. Si le jeu a été en contact avec l'eau, il vaut mieux en changer. Certaines batteries Maxell équipant les B-Board CPS2 ont tendance à exploser, causant des dommages irrémédiables à la carte et aux composants avoisinants. Ce n'est a priori pas le cas ici, je la retire :

J'ai deux solutions : soit utiliser un set d'UVPROMs décryptées (les roms Phoenix créées par Razoola), soit recharger la clé de décryptage en RAM avec la pose d'une nouvelle batterie. Je préfère conserver les UVPROMs d'origine, je vais donc recharger la clé de décryptage. Je pose donc une batterie SAFT neuve :

Eduardo Cruz a mis au point un procédé de rechargement des clefs de décryptage, sur la base des travaux menés par Andreas Naive, Nicola Salmoria et Charles McDonald en 2007. Ce procédé repose sur l'injection de clefs via un Arduino connecté à la B-Board. Je programme donc un Arduino :

Je sépare la B-Board de la A-Board, je branche l'Arduino sur la B-Board, tout est prêt. Je lance l'injection des clefs ...

Et quelques instants plus tard, le programme m'invite à tester le jeu, ce que je m'empresse de faire. La séquence de boot démarre, c'est plutôt bon signe : le programme s'exécute correctement : la clé s'est bien chargée en RAM. Mais ce message va doucher mes espoirs d'une réparation rapide :

Je suis accueilli par un "RAM ERROR" sybillin. Sachant que la A-Board fonctionne, le problème se situe sur la B-Board. J'ai découvert en travaillant sur ce système que le CPU est sur la B-Board, contrairement au système CPS-1. Les deux seules SRAMs présentes sur la B-Board se trouvent en 3A et 4A :

Je retire la première :

Résultat, n'est même pas détectée par mon testeur ! Je retire la seconde :

Mon testeur lève plusieurs erreurs (jamais au même endroit)

Je pose deux SRAMs de remplacement, le jeu démarre avec du son ...

Mais après quelques instants, je me rends compte que les sprites sont manquants à l'appel :

C'est génant. Les MASKROMs sont bonnes, pas de piste coupée apparente non plus. Le mode test ne me sera pas d'une grande aide :

Un test croisé me permet de localiser la panne sur la B-Board. Je reste donc dessus et plus particulièrement sur ces deux ASIC :

Le DL-2027 et le DL-1927. Ces deux composants sont reliés au bus de données et adresses graphiques, sur lequels se trouvent les MASKROMs contenant les graphismes. Le DL-2027 est un sélecteur de données, il sélectionne les données graphiques à afficher, le DL-1927 est le générateur d'adresses pour cette partie graphique. Le coupable doit être l'un des deux. Je retire le 1927 :

Et je pose un composant de remplacement. Cela ne changera rien, le composant était bon, je le remets sur sa carte d'origine. Reste le 2027 que je retire :

Je pose un remplaçant :

Cette fois, les graphismes sont de retour, le jeu est parfaitement jouable.

Bilan :
2 x SRAM 6264 (Fujitsu)
1 x Pile rechargeable 3.6v (Maxell)
1 x ASIC DL-2027 (Capcom, Fabrication Fujitsu).

Le saviez-vous ?

Avant la solution Arduino, dans les années 90, la clé de protection était chargée en RAM à l'aide d'un PDA Sharp PA-V1 par les employés de Capcom. L'appareil était alors branché à la B-Board.

Les clés étaient stockées sur des cartes mémoire de 128Ko, une par jeu :

Ce PDA n'a manifestement jamais traversé les frontières du Japon !
(crédit photos : CPS2Shock - Razoola)

A dans 15 jours.