Bonjour.
La guerre contre le Démon des Pannes continue.
Aujourd'hui, un PCB original
Phoenix de chez
Taito est habité par le Démon et souffre d'un bug graphique sur certains sprites.
Certains sprites sont affichés avec une ligne verticale de 1 pixel de large buggée.
Ce bug se répète tous les 8 pixels sur ces sprites.
Le hardware du PCB Phoenix est conçu/exploité de manière un peu particulière :
- une partie du hard gère la layer des "petits" sprites : les petits vaisseaux qui attaquent ; très classique
- une autre partie du hardware gère la layer du background du jeu ; très classique aussi
- la priorité des 2 layers est gérée par le hard ; les petits sprites sont prioritaires (affichés en avant-plan)
La partie background est utilisée pour afficher des décors, comme un fond d'étoiles.
Mais elle est également
aussi utilisée pour afficher soit des "gros" sprites, soit le gros vaisseau du boss !
Lorsque le jeu a besoin d'afficher ça, il utilise donc en fait la 2e layer...
Les "gros" sprites ont un bug. Chaque 1ère colonne de groupe de 8 pixels est buggée.
Il existe des lignes verticales parasites, qui se répètent tous les 8 pixels.
Ce n'est pas très visible, sauf en poussant un peu la luminosité de l"écran.
Avec cette petite manip...
... le bug apparait mieux à l'écran :
La pin soulevée de l'EPROM provoque les traits rouges verticaux sur le background du jeu.
Grâce à ce petit hack, le bug graphique se montre un peu plus flashy : il est maintenant mauve et non plus gris foncé.
Les investigations peuvent alors commencer :
Le problème, c'est que les sprites bougent dans tous les sens (normal, c'est ce qu'on leur demande).
Il m'est impossible d'essayer de voir/comprendre quoi que ce soit, tellement ça gigote dans tous les sens.
Tous les signaux sont fugitifs, il y en a de partout...
Malheureusement, contrairement à un PCB comme Chelnov, il n'existe pas de dip-switch qui permet de figer le jeu.
Il est temps de sortir le deuxième petit hack, très violent, mais parfaitement efficace :
Je me suis branché en parallèle sur le condo du circuit d'auto-reset du CPU du jeu.
Au moment de la mise sous tension, le condo est vide et le CPU est en état de RESET.
Rapidement, le condo se charge et l'état de RESET s'efface, le CPU démarre. Ca permet d'attendre automatiquement la stabilisation de l'alim avant de faire booter le PCB.
Dès que je ferme l'interrupteur, le CPU va se bloquer car il est en état de RESET.
Toute la partie mise à jour des sprites ne peut plus se faire. L'image devient figée, mais reste dynamiquement générée par le reste du PCB qui - lui - continue de fonctionner.
J'amplifie un peu mon hack de lignes rouges verticales (4 pins soulevées donnent des colonnes de 4 pixels de large) et je vais me concentrer sur une ligne
bien précise de l'image :
La ligne est composée, à son début :
- de cyan : dans le mot "score"
- du rouge : dans le chiffre du score
- du rouge : une barre verticale générée par mon hack
- du mauve : c'est là le problème, car on devrait avoir du rouge
Pour pouvoir investiguer correctement, je dois régler l'oscillo pour qu'il déclenche sur la bonne ligne vidéo.
Je mets 8 canaux numériques (bus) de l'oscillo sur les 8 bits du compteur de lignes généré en interne par le PCB :
Ensuite, je demande à l'oscillo de déclencher lorsque ces huit canaux valent une certaine valeur, c'est à dire le numéro de la ligne.
À tâtons, je trouve que la ligne qui m'intéresse. C'est la ligne n°42, soit 0x2A en hexadécimal. C'est la valeur que je règle dans l'oscillo.
Là, c'est vraiment pratique pour observer ce qu'il se passe :
- l'image du jeu est 100% figée, mais pour autant toujours générée dynamiquement par le hardware ; simplement le CPU ne fait plus "vivre" le jeu
- chaque pixel est toujours exactement généré au même instant au même endroit par la même partie du PCB selon les besoins
- mon oscillo déclenche toujours son affichage exactement sur la même ligne
Je peux ainsi, tel Néo dans la Matrice, me déplacer avec l'oscillo dans une réalité électronique qui semble figée.
Je peux me déplacer à volonté partout dans le hardware du PCB et observer tout ce que je veux sans être gêné par le coté dynamique de la génération de l'image.
Les signaux que j'observe sont exactement ceux présent au moment de la génération de la portion de ligne qui affiche le bug graphique.
J'ai ensuite ajouté sur l'écran de l'oscillo un 2e bus constitué des 7 bits d'adresse des 2 petites PROMs qui contiennent la palette de couleur.
Je peux ainsi observer que mon hack de barres rouge demande l'affichage de la couleur d'index 0x10 dans la palette.
Quand le bug se manifeste, c'est la couleur 0x17 qui est demandée...
À suivre...
