Gamoover

[move]Pour vous aussi la chipo ne sera jamais qu'un bootleg de merguez (c)sushy18 ? Alors soyez les bienvenus sur Gamoover ! [/move]

F4brice 5 - Démon des pannes 0

Démarré par f4brice, Jeudi 15 Juillet 2010, 22:58:40 PM

f4brice

Le PCB semble ne pas avoir booté du tout.
Là, comme ça, à froid... je dirais qu'il faut vérifier :

  • le signal RESET généré par l'alim et envoyé sur le PCB
  • les tensions directement sur le CPU, les ROMs et les RAMs
  • la clock du CPU


zebassprophet

donc ca pourrait quand même venir de l'alim?

faudrait que je retrouve les schema pour tester les tensions deja


merci pour ces infos  ^-

f4brice

Bonjour.

Le démon des pannes est en train de se prendre des mandales dans les gencives...  p=)

1er PCB : un Space Invaders :


Pour celui-là, c'est juste un apéro... Faux contact au niveau du connecteur entre le PCB horizontal et le PCB vertical.

Le 2e PCB est... un autre PCB de Space Invaders !
Là, c'est déjà plus velu...

Déjà, j'ai pu déterminer à l'oscillo que le composant en F6 était malade :


Notez que je n'ai pas arraché de pastille lors du dessoudage.
Dans certains cas, des pastilles sont absentes en l'absence de piste coté composant. C'est le cas ici.

Au passage, il y a eu un petit problème lors de l'insertion de ce composant sur le PCB lors de la fabrication :


Il a une broche recroquevillée sous lui.
Je m'en étais douté lors des vérifs à l'oscillo car j'avais vu qu'il n'y avait pas la pointe de la broche coté pistes.

C'est un composant un peu exotique : c'est un "9322", équivalent d'un 74LS157.

Mon testeur confirme ce que j'avais supposé à l'oscillo :


Ensuite, malgré pas mal de temps passé avec l'oscillo, je n'arrive pas à trouver ce qui cloche...
Il existe un romset de test pour Space Invaders : lien.
Ce romset réalise un test de la RAM au démarrage, ce qui m'intéresse beaucoup.
Je télécharge la version de Frederic Rodo. Ce sont 4 fichiers de 2 ko chacun, à flasher dans des 2716.

Problème : je n'ai rien pour flasher des EPROM TMS2716 (modèle à 3 alims 5/12/-5).
Du coup, je duplique chaque fichier de 2 ko en 16 ko, et je flash des 27128.
Je bricole un peu les EPROM pour qu'elles puissent l'insérer sur le PCB.

Les bits d'adresses supplémentaires de la 27128 peuvent être reliés à GND, à VCC ou même à un autre bit d'adresse car j'ai dupliqué le contenu.


À suivre...  :D

HerosSuperMan

Citation de: f4brice le Dimanche 30 Août 2015, 16:28:50 PM
Il existe un romset de test pour Space Invaders : lien.
Ce romset réalise un test de la RAM au démarrage, ce qui m'intéresse beaucoup.
Je télécharge la version de Frederic Rodo.

Frederic Rodo alias le bien nommé Spectroman de ce forum quand même je tiens à préciser  ^-
Mes Wip, mes RT... la vie quoi ^^
Mes recherches\échanges (bornes, PCB, pièces ...)
Recherche .. non..rien rien rien..le problème c'est que l'on fini toujours par trouver... >:D

maldoror68


sushy18

Citation de: HerosSuperMan le Dimanche 30 Août 2015, 17:26:06 PM
Frederic Rodo alias le bien nommé Spectroman de ce forum quand même je tiens à préciser  ^-

Chui pas sûr. .. le spectro du forum ne fais que picoler.... toujours un verre à la main....  jamais vu avec un fer. Un homonyme assurément. ..

F4brice toujours un plaisir de lire ce topic
Si tu ne sais pas demande, si tu sais partage !!
Faudrait pas perdre de vue qu'une borne d'arcade c'est pas une console, c'est rarement plug n play, plus souvent plug n pschitt... (Funkycochise 2008)
"Gratuit ? C'est déjà trop cher !!" ( Crying Freeman 2016)

f4brice

Voilà la suite du combat du jour...

J'ai décidé d'utiliser l'artillerie lourde : l'analyseur logique !  :-*


L'analyseur n'a que 18 canaux.
Il y a 8 canaux sur le bus de données de l'EPROM de test
Il y a 8 autre canaux sur les 8 bits de poids faible du bus d'adresse de l'EPROM de test.
1 canal va sur le signal A5 directement sur le CPU.
1 dernier canal va sur le signal RESET, ce qui me permet de déclencher l'analyseur et de ne pas me noyer dans un océan de signaux...

Pourquoi sur l'EPROM de test et non pas sur le CPU ?
Pourquoi espionner en particulier le signal A5 du CPU ?

Je vous fais la version courte. J'ai passé pas mal de temps à analyser à droite et à gauche pour enfin comprendre ce qui cloche...

Voilà ce que l'analyseur logique observe :


Ces données sont à rapprocher du contenu de l'EPROM de test :




Je peux voir que le CPU lit et exécute correctement toutes les instructions du début de l'EPROM de test.
Grosso modo, le watchdog est reseté puis il y a un JMP en 0x0556 où le test de la RAM commence réellement.
Là, le test débute, mais à partir de l'instruction 10 en jaune, le CPU pensait lire l'octet à l'adresse 0x0560 (valeur 0xFE), mais il a lu à son insu celui à l'adresse 0x0540 (valeur 0x20).

A partir de là, c'est à peu près n'importe quoi puisque la sémantique du test de RAM n'est pas respectée, le CPU recevant du code se trouvant à un autre endroit en EPROM.

L'écart entre 0x0560 et 0x0540 n'est que sur 1 bit, celui de rang 5.
Il s'agit donc du bit A5 sur le bus d'adresse qui déconne.
L'oscillo le confirme :


Là où c'est pervers, c'est que j'aurais pu trouver cette panne sans l'analyseur logique.
En fait j'avais déjà examiné le bus d'adresse et je l'avais trouvé OK.
Sauf que le problème n'arrive que pour l'EPROM située à l'emplacement H sur le PCB. Son support a un faux contact.
Et durant mes investigations, j'avais testé le bus d'adresse sur une autre EPROM, située sur un autre support...  ;D

À suivre...

aje_fr

C'est comme sur les pcb de la même époque (galaxian, pacman, etc...), les supports ont tendances à s'oxyder et merder. Le mieux c'est de tous les changer  ;).
A+
Think different, don't purchase Apple !

spectroman

#200

La seule EPROM a programmer est la H, j'y ai passé des heures a optimiser le code en taille pour que ca rentre sur 2Ko :P.
Les autres eprom je m'en sert juste pour calculer le crc32 et du coup détecter si il y'a un problème d'eprom ou support.

Je remplace les roms par des 2716 standards et je modifie le strapping :



Sinon tu peux modifier l'eprom H comme tu as fait et laisser les roms E,F,G d'origine.

J'ai toujours pas écris le manuel utilisateur de la rom de tests, si tu as un doute n'hésite pas.

De mémoire, il y'a :
Le test des rams
Le test des roms
Le test des registres à décalage de la vidéo
Le test des sons, des entrées et une mire de réglage vidéo (après je fait sauter le wathdog et ca recommence)

zebassprophet

c'etait un apero la premiere pcb parce qu'elle etait deja passé dans les mains d'un professionel....

F4brice y'a 4-5 ans ;)

merci msieur  :-)=

zebassprophet

up from hell

j'ai un hammerin harry qui me met ROm ok, mais ram hs.

je vais voir tenter de rentrer dans le mode diagnostique histoire de dire

f4brice

Bonjour.

La guerre contre le Démon des Pannes continue.  p=)

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...

Amano J

Bordel tu me fais rêver, je ne capte pas tout mais pourtant c'est passionnant  :-*

DCE

Que c'est beau ^- Toute cette science déployée pour la préservation de notre précieux rétro-patrimoine ludique  :-*

maldoror68

c'est une palette... à la diable (ce démon des pannes)

je sors.... :fleche:

Stek

F4brice... fais moi l'amour !!    :-*