Gamoover

Bonjour.

C'est bientôt le printemps, c'est la saison des nouveaux WIP !

En février 2011 (il y a bientôt 10 ans, la vache !), je faisais un road-trip pour aller récupérer une borne Gun Fight (Midway, 1975). C'était là : road-trip Gun Fight (https://www.gamoover.net/Forums/index.php?topic=23121.0).
La borne n'était plus trop d'origine : écran changé, PCB changé, pannel charcuté...

D'autre part, le sieur Sir Kayne (https://www.gamoover.net/Forums/index.php?action=profile;u=4414) vendait depuis juin 2009 le panel de cette borne, semble-t-il sans grand succès (lien (https://www.gamoover.net/Forums/index.php?topic=19384.0)).
Nouveau possésseur d'une Gun Fight au panel charcuté, j'avais acheté son panel juste après le road-trip.

Ensuite, la borne a pris la poussière pendant presque 10 ans dans ma gameroom...

Il y a quelques années, j'avais saisi l'opportunité d'acheter un PCB Gun Fight original et non testé.
Il était vendu par un ami, à un prix d'ami !
Le PCB n'était pas testé, je ne l'ai pas testé non plus juste après l'achat.
Je l'ai stocké juste dans la borne pour "plus tard".

Cette borne Gun Fight est l'une des dernières bornes non fonctionnelle de ma gameroom, alors il est temps de s'en occuper.

Je vais déjà commencer par tenter de réparer le PCB.
Notez que je ne perds même pas mon temps à croire qu'il pourrait encore fonctionner. Ce serait simplement invraissemblable.
En ce moment, c'est un peu la saison des PCB Midway en forme de "L" à base de Intel 8080...
Il y a eu les Gun Fight de Petit_Lapinou, il y a le Sea Wolf de jack_burton racheté à phil36, et aussi le Space Invaders de pet...
J'ajoute donc mon Gun Fight !

Normalement, j'installe le chantier de dépannage de PCB sur mon bureau, mais là, du fait du télétravail, mon bureau est un peu saturé.
Le dépannage va donc se faire dans le garage, sur l'établi.

La première mise en route confirme ce qui était déjà acquis : le PCB est en panne :


Je sors l'oscillo :


Notez que contrairement au guide de dépannage de ces PCB, j'ai laissé les EPROM en place pour le moment.
En fait, je veux déjà vérifier si le CPU est vivant.
Pour cette vérification, je n'ai pas encore besoin de retirer les EPROM.

Je constate, avec l'oscillo, que le CPU est 100% à l'arrêt, il ne fait absolument rien de chez rien :

• aucune activité sur le bus de data
• aucune activité sur le bus de données

Les signaux critiques du CPU sont vérifiés :

• les clocks ϕ1 et ϕ2 sont OK
• la pin "RESET" est OK
• par contre, la pin "READY" du CPU est toujours à 0

Cette pin READY à 0 explique pourquoi le CPU est tanké :


Il attend qu'un périphérique externe plus lent que lui soit prêt.
Quand on regarde comment ce signal est généré (rouge), on voit que c'est la sortie d'un latch 74 situé en E3 :


C'est très souvent que ces latches 7474 crament, mais avant de le dessouder, je regarde comment il est piloté.
Je me rends compte que sa pin clock (pin #11, vert) ne bouge pas, donc aucune chance que sa sortie se mette à jour :


La clock du latch vient d'un 7442 situé en C6 :


C'est un banal compteur BCD.
Il reçoit un compteur 4 bits en entrée, et chacune des 10 sorties s'active à son tour (à 0).
Vu que c'est un compteur décimal, aucune sortie n'est active pour les valeurs 10 à 15 du compteur en entrée.
En gros, il a 3 fonctions :

• diviser la fréquence du compteur en entrée par 16
• générer des signaux avec un rapport cyclique 15 pour 16
• générer des signaux jumeaux simplement déphasés de N clocks

Normalement, je devrais avoir un signal qui ressemble à ça (autre pin de sortie du 7442) :


Hop, je le dessoude :


Il passe sur le banc de test qui confirme qu'il est bien mort :


Je sors un 7442 de mon stock, et je le teste avant de le souder :


Il est bon, je le soude :


Notez que j'avais en stock un authentique SN7442 (pas LS), fabriqué en 1970.
Ça devient rare de trouver des trucs plus vieux que moi !!!

Je teste à nouveau le PCB avec cette réparation, et... absolument aucun changement à l'image !
Par contre, je vois que le CPU est maintenant vivant, il a l'air de vouloir bosser. C'est déjà ça !

Deuxième étape : je retire les EPROM du jeu ; normalement, je dois avoir des barres verticales.
Les EPROM sont toutes sur support, et maintenues par 2 points de colle à chaud :


Déjà ce type de colle est pourri, mais avec le temps elle ne colle presque plus.
Je retire les pâtés de colle avec une petite pince, puis je sors délicatement les EPROM avec un tournevis :


À l'image, j'ai un truc merdeux, pas trop fixe. Ça pue le problème de RAM :


Quand je synchronise l'oscillo sur le signal "DBIN" (Data Bus INput = le CPU mange des data venant de l'extérieur), je vois que le CPU mange bien du 0xFF.
Le signal "WR" est bien régulièrement actif, signe que le CPU tente d'écrire des trucs.

Donc, soit les "trucs" n'arrivent pas jusque dans les RAM, soit ils n'en ressortent pas ou mal.
Je m'intéresse donc aux RAM.
La première anomalie qui me saute aux yeux, c'est qu'elles ne sont jamais sélectionnées !!!
Normalement, elles sont lues périodiquement pour générer le signal vidéo, mais là non.

Les signaux de sélection des RAM (rouge) sont générés par une bouse de chip Intel 3245 situé en C5 :


Son examen indique qu'il n'est à priori pas fautif, car le signal qu'il reçoit sur sa pin 3 est foireux.
La porte NAND du chip B6 est morte :


Sur l'oscillo, les signaux jaunes et cian sont les entrées de la porte NAND.
Le signal magenta, c'est la sortie de la porte NAND.
On doit avoir le signal de sortie (magenta) à 0 quand les 2 entrées (jaune et cian) sont toutes les deux à 1.
Là, ce n'est pas le cas du tout. La sortie est simplement le complément d'une des entrées (la jaune), peut importe l'état de la 2e entrée (cian).
C'est probablement parce que le transistor en entrée de l'autre pin (le cian) est cramé, et que la porte NAND reçoit en permanence un "1" à la place du signal cian.

Je dessoude le 7400 en B6 :


Le testeur confirme mon diagnostic :


Je teste le remplacant :


Et voilà : il est soudé :


Maintenant je teste à nouveau le PCB, toujours sans les EPROM...


TADA !!!
J'ai les barres verticales magiques !

Je remets vite fait les EPROM...


Bon, il reste du travail...
On devine des bribes du jeu Gun Fight, mais bien buggées !

À suivre !  :D

Salut,

Chic, un WIP Gun Fight que je vais suivre avec le plus grand intérêt !!

Bien vu pour le READY qui était HS !  ^-^

Citation de: f4brice le Jeudi 21 Janvier 2021, 22:16:49 PM
Je m'intéresse donc aux RAM.
La première anomalie qui me saute aux yeux, c'est qu'elles ne sont jamais sélectionnées !!!
Normalement, elles sont lues périodiquement pour générer le signal vidéo, mais là non.

Les signaux de sélection des RAM (rouge) sont générés par une bouse de chip Intel 3245 situé en C5 :

Cette partie de tes observations m'interpelle ! Je ne comprends pas comment tu peux avoir des pixels à l'écran si les RAM ne sont jamais sélectionnées : quelle est cette diablerie ??

Sur mon Gun Fight #3 (https://www.gamoover.net/Forums/index.php?topic=42765.0), j'avais le chip 3245 en C5 qui était HS, et qui avait pour conséquence de ne pas générer le Chip Enable nécessaire aux RAM => l'écran était noir, vierge de tout pixel !

Mais d'où viennent alors les pixels que tu avais à la première mise sous tension ?  ;D

J'imagine que tu vas à présent faire le test des RAM avec le programme de test de Space Invaders, sur lequel toi et Spectro avez bossé ? :)

Hâte de lire la suite !  ^-^

A+

Ca pleut des wips techniques en ce moment  8)

Bon, encore une fois, je ne suis pas capable de tout suivre comme il faut, mais c'est tellement bien rédigé que ça donne envie de lire quand même.
Et puis c'est super instructif et ça reste du cas pratique  ^-

Citation de: Maitre_Poulpi le Jeudi 21 Janvier 2021, 23:17:30 PM
Ca pleut des wips techniques en ce moment  8)

Bon, encore une fois, je ne suis pas capable de tout suivre comme il faut, mais c'est tellement bien rédigé que ça donne envie de lire quand même.
Et puis c'est super instructif et ça reste du cas pratique  ^-

Tout a fait  ^-

Petit_Lapinou : tu pourrais te logger sur KLOV et me récupérer ces PDF :

• https://forums.arcade-museum.com/attachments/gun_fight_game_logic_schematics_-597-907-pdf.301944/ (https://forums.arcade-museum.com/attachments/gun_fight_game_logic_schematics_-597-907-pdf.301944/)
• https://forums.arcade-museum.com/attachments/gun_fight_game_logic_and_sound_-597-907e-pdf.301945/ (https://forums.arcade-museum.com/attachments/gun_fight_game_logic_and_sound_-597-907e-pdf.301945/)

J'ai un compte KLOV, mais mon mot de passe est faux, et la procédure de "mot de passe oublié" est actutellement en panne !

Merci !  :-*

Je te les ai envoyé par MP ;)

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210122103321-olschool-Capture-d-Aoe-Acran-2021-01-22-a-A-10.32.43.png) (https://gamoovernet.pixhotel.fr/pics/20210122103321-olschool-Capture-d-Aoe-Acran-2021-01-22-a-A-10.32.43.png)


(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210122103415-olschool-Capture-d-Aoe-Acran-2021-01-22-a-A-10.34.00.png) (https://gamoovernet.pixhotel.fr/pics/20210122103415-olschool-Capture-d-Aoe-Acran-2021-01-22-a-A-10.34.00.png)

Merci !  :-*

Salut,

Citation de: f4brice le Vendredi 22 Janvier 2021, 10:10:09 AM
Petit_Lapinou : tu pourrais te logger sur KLOV et me récupérer ces PDF :

• https://forums.arcade-museum.com/attachments/gun_fight_game_logic_schematics_-597-907-pdf.301944/ (https://forums.arcade-museum.com/attachments/gun_fight_game_logic_schematics_-597-907-pdf.301944/)
• https://forums.arcade-museum.com/attachments/gun_fight_game_logic_and_sound_-597-907e-pdf.301945/ (https://forums.arcade-museum.com/attachments/gun_fight_game_logic_and_sound_-597-907e-pdf.301945/)

Je vois qu'olschool s'en est déjà chargé ^-.
(et c'est heureux car je m'aperçois que je ne suis pas un "full member", et n'ai donc pas accès à ce téléchargement ! :-\)

Ces deux schémas correspondent à la carte fille, avec respectivement la gestion des sons, et la gestion du panel.

Tu peux trouver les schémas du câblage de la borne, et ceux de la carte mère sur TAMDB.NET (https://tamdb.net/index.php?action=downloads;sa=view;down=5232). Le scan est de très mauvaise qualité, mais c'est tout de même mieux que rien :'(... Pour la carte mère, j'utilise celui de Space Invaders qui est bien plus propre, et identique à celle de Gun Fight. Si ça t'intéresse, j'ai aussi un schéma de la carte mère Space Invaders version Taito, quasiment identique, et qui a été redessiné avec des outils modernes, donc très propre et très lisible (je ne sais plus où je l'avais dégoté...).

A+

J'ai repris le PDF dispo un peu partout (scans de mauvaise qualité), et j'ai réassemblé toutes les pages pour obtenir 3 grosses images :

• la partie CPU (qualité honnête)
• la partie GAME LOGIC (qualité pourrie)
• la partie WIRING DIAGRAM (qualité honnête)

Il me manquait la partie audio analogique, et en cherchant sur le net, je suis tombé sur ces documents KLOV annoncés être de bonne qualité.
Je partagerai ça dès que j'aurai fini de les retoucher.

Citation de: Little_Rabbit le Vendredi 22 Janvier 2021, 10:54:02 AM
Si ça t'intéresse, j'ai aussi un schéma de la carte mère Space Invaders version Taito, quasiment identique, et qui a été redessiné avec des outils modernes, donc très propre et très lisible (je ne sais plus où je l'avais dégoté...).

Je prends !  :-*

Bonjour, beau travail! Elle était bien malade... On dirait : soit un (ou plusieurs) bit(s) du compteur vidéo "collé", ou au niveau d'adressage de la ram vidéo.

Salut F4brice  :-*
Super début de dépannage bien détaillé comme souvent  ^-^ ^-^ je ne comprend pas tout mais quelques brides, mais cela m'aide et me fait progresser  :-)=
Je vais suivre ce WIP de prêt  ^-

 ^-^ Belle plume, c est super clair! ^-^

Citation de: Little_Rabbit le Vendredi 22 Janvier 2021, 10:54:02 AM
je m'aperçois que je ne suis pas un "full member", et n'ai donc pas accès à ce téléchargement ! :-\

Question basique : c'est quoi être un "full member" de KLOV?
J'ai bêtement cliqué et ca a téléchargé les fichiers.  :D
Bon OK j'ai un compte KLOV mais c'est tout.
Je ne crois même pas avoir fait une donation ou autre truc de ce genre.

Salut,

@Franzy2121 : je n'en sais trop rien :).

J'ai un compte créé sur Klov il y a de nombreuses années, avec 0 post, et quand j'ai voulu télécharger hier les fichiers, le site KLOV m'a dit :

CitationOops! We ran into some problems.
You do not have permission to view this page or perform this action.
Please see this post (https://forums.arcade-museum.com/threads/how-to-gain-full-access-please-read.176631/) on how to become a full member.

Du coup j'ai fait un don de $10.00 ... et à part le fait que mon compte Paypal a bien été débité, je n'ai pas encore vu de différence ! :D

A+

Bonsoir.

J'ai profité aujourd'hui d'avoir 1h de dispo avec mon aide de camp pour avancer un peu sur ce WIP.
La dernière fois, j'avais remis en route le CPU qui était bloqué, ainsi que l'accès aux RAMs pour la partie génération du signal vidéo.
Le test de fonctionnement du CPU sans les ROMs m'avait donné les barres verticales magiques, mais un test rapide du jeu complet donnait une image particulièrement buggée.

Il est temps de passer à la phase 2 du dépannage : l'utilisation de la ROM de test pour Space Invaders, ROM de test ô combien améliorée par notre Spectroman national !

Déjà, pourquoi utiliser une ROM de test de Space Invaders pour un autre jeu ?
Tout simplement parce que les parties CPU et vidéo sont totalement identiques !
Seule change la partie audio du PCB. Et pour ça, on verra en temps utile...

Tout comme Petit_Lapinou dans la réparation de son PCB Gun Fight #3 (https://www.gamoover.net/Forums/index.php?topic=42765.0), mon PCB dispose de 8 PROMs de 512 octets chacune, alors que la ROM de test de Space Invaders est prévue pour être écrite dans une EPROM de 2 kBytes = 16 kbits du type 2716.

Là, 2 possibilités :

• je découpe la ROM de test en 4 fichiers de 512 octets chacun, que je dois écrire dans 4 composants
  MAIS d'une part je n'ai pas ce genre de composant, et d'autre part je ferais l'hypothèse que mon PCB arrive correctement à gérer l'adressage des 4 composants, ce qui n'est pas acquis
• je modifie des straps sur le PCB, pour passer d'un adressage de blocs de 512 octets à des blocs de 2 kilo-octets, et aussi pour passer de PROMs préhistoriques tri-tension (+12V, +5V, -5V) à des EPROMs plus classiques mono-tension (+5V)

C'est parti pour l'option #2.
Grâce au travail documenté ici même par Petit_Lapinou, je gagne un temps considérable à cette étape.
Il me suffit de cloner exactement ce qu'il a fait dans son WIP !
Merci à lui !!!  :-*
Vous avez ci-dessous les exactes mêmes étapes réalisées et documentées par Petit_Lapinou.

Étape 1/3 : je change le mode d'adressage, de blocs de 512 octets en blocs de 2048 octets.
Ce sont les 3 straps S6 à changer...

Avant :


Après :


Étape 2/3 : on passe de PROMs préhistoriques tri-tension à des EPROM classiques mono-tension.

Avant :


Après :


Étape 3/3 :  il faut changer de place les 4 condos de découplage.

J'ai oublié de faire la photo "avant", vous n'avez que la photo "après" :


Ensuite, j'installe l'EPROM 2716 contenant déjà la ROM de test Space Invaders :


Je me suis auto-surpris : j'ai réussi à la retrouver dans mon merdier !
C'est la version 1.2 de la ROM de test. Il existe la version 1.3 qui corrige un petit bug.
Notez que mon EPROM est une MK2716J-8 de chez MOSTEK.
C'est moins préhistorique que les PROMs tri-tension de 512 octets, mais c'est quand même vieux et caca à programmer.
Il faut trouver un outil actuel qui sache encore programmer ces vieux trucs.
Mon programmateur d'EPROM ne connaît pas la MK2716J-8.
Néanmoins, j'avais découvert que son mode de programmation (tension et timings) étaient compatible avec la 2716 de chez ST.
D'où l'inscription sur l'étiquette pour ne pas perdre l'info !

Je mets sous tension le PCB.
Déjà le programme de test fonctionne. Il remplit les RAMs avec divers patterns comme prévu.
Et il s'arrête là dessus :


Arf, c'est plutot inattendu !
J'ai certainement une ou plusieurs RAM en erreur, mais il n'y a pas d'affichage des références !
Normalement, le numéro de la RAM KO est écrit à la place du petit bloc blanc. Il y a 16 blocs blancs pour 16 chips de RAM.
Là, le test RAM est KO mais l'affichage indique des RAM OK !?

Quelle est cette diablerie du Démon des Pannes ???

J'ai confiance dans la ROM de test, et il n'y a pas (plus) de bug d'affichage des RAM en erreur.
Donc ce n'est pas ça...

En fait, la réponse est sur l'image.
Si on regarde ces 4 zones d'images, il y a un détail intéressant :


Et bien tout simplement les zones 1 et 2 sont parfaitement identiques, ainsi que les zones 3 et 4 !

Si on reprend l'image du jeu quand je l'avais testé à la fin de mon précédent post, on le constate aussi :

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210123225715-f4brice-IMG-20210120-220755.jpg) (https://gamoovernet.pixhotel.fr/pics/20210123225715-f4brice-IMG-20210120-220755.jpg)

Et ouais, c'est vicelard, hein ?  8)
Jolie peau de banane lancée par le Démon des Pannes, non ?

Si on repense au pattern de barres verticales quand on démarre le PCB sans aucune ROM, il est impossible de voir ce problème.
En effet, les barres se répètent tous les 16 pixels (16 barres de 16 pixels de large).
Donc visuellement aucun défaut visible même avec ce problème de zones répétées.

Donc maintenant, on sait qu'on a un problème d'image, où des zones sont recopiées.
Plusieurs hypothèses sont possibles :

• le contenu des RAM est bon et c'est un problème d'accès aux RAM lors de la génération du signal vidéo
• c'est un problème d'adressage des RAM par le CPU qui n'arrive pas à écrire où il voudrait ; l'image est juste et ne reflète que ce que le CPU arrive à faire
• c'est un problème à la fois de lecture des RAM pour le signal vidéo et d'accès par le CPU

Je pense que la bonne réponse est soit la #1, soit la #3.
Pourquoi ce n'est pas la #2 ?
Parce que 1 fois durant mes essais, le test RAM a réussi (!?), et la ROM de test est allée plus loin :


On voit que sur la parte droite de l'image est affiché le message "RAM = OK" dans ce que j'appelle la zone 4 ; ce message est visible également dans la zone 3.
Or la ROM de test affiche ce message une et une seule fois.
Si le CPU l'écrivait à l'insu de son plein gré en zone 3 alors qu'il pense le faire en zone 4, on n'aurait pas la duplication visible zone 3 et zone 4.
Le message serait visible en zone 3 seulement et la zone 4 serait vide, ou remplie de caca.

Maintenant, comment se traduit électroniquement ce problème de zones dupliquées ?

L'image de Gun Fight fait 256 x 224 pixels. C'est un choix de conception.
On est en noir et blanc, donc 1 bit = 1 pixel.
On a 1 ligne = 256 pixels = 256 bits = 32 octets.
La zone "1" correspond aux octets d'index 0 à 7, soit des adresses binaires qui finissent par 00000 à 00111.
la zone "2" correspond aux octets d'index 8 à 15, soit des adresses binaires qui finissent par 01000 à 01111.
la zone "3" correspond aux octets d'index 16 à 23, soit des adresses binaires qui finissent par 10000 à 10111.
la zone "4" correspond aux octets d'index 24 à 31. soit des adresses binaires qui finissent par 11000 à 11111.

Vu que d'une part les zones 1 et 2 sont identiques, et d'autre part les zones 3 et 4 le sont aussi, le bit d'address fautif est le bit rouge AD3.
Vu qu'il semble que ce soient les zones 2 et 4 les zones authentiques, et les zones 1 et 3 les erreurs, je pense que AD3 reste tanké à 1 lors de la lecture des RAM pour générer le signal vidéo.

À suivre : on va vérifier tout ça à grands coups d'oscillo dans les dents du Démon des Pannes !

PS : et mon aide de camp dans tout ça ?
D'habitude elle m'aide, mais aujourd'hui elle a voulu jouer.
Elle devient experte en machine à doudous (c'est comme ça qu'elle l'appelle).
Sur la photo, elle vient d'attraper une autre peluche et elle tape de joie dans ses mains !
Elle pose les peluches attrapées à côté sur la borne Quartet.

Salut,

Je suis content que mes travaux précédents servent à quelqu'un !  ^-  :-*

Oui, sur l'image de ton post précédent, je m'étais aussi fait la réflexion des parties d'image dupliquées, et me doutais que tous les 8 octets, un bit d'adresse déconnait :).

Le 74157 en F5 a une bonne tête de coupable non ? :)

Je pense que le composant est moribond, mais pas complètement mort :). Ce qui explique qu'une fois, dans un instant où le composant a trouvé un poil de vaillance, tu as pu passer le test.

D'ailleurs, si on regarde attentivement l'image du test de RAM, on remarque qu'il y a un pixel qui diffère, tout comme certains pixels différaient lors de ton 1er test :D :

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210123232644-Little_Rabbit-IMG-20210123-120242.jpg) (https://gamoovernet.pixhotel.fr/pics/20210123232644-Little_Rabbit-IMG-20210123-120242.jpg)

A+

PS : as-tu bien reçu le schéma de la carte mère Taito mis au propre que je t'ai adressé par email ? :)

Trop fort le post, c'est super intéressant.

En plus c'est attendrissant, entre le petit_lapin ou et la machine à doudou, on a envie de faire des câlins  :D

Citation de: Little_Rabbit le Samedi 23 Janvier 2021, 23:31:37 PM
Je suis content que mes travaux précédents servent à quelqu'un !  ^-  :-*

C'est tout l'intérêt d'un forum et du partage de connaissances !  :-*
Merci à toi !

Citation de: Little_Rabbit le Samedi 23 Janvier 2021, 23:31:37 PM
Le 74157 en F5 a une bonne tête de coupable non ? :)

Oui, sa pin #11 serait morte.
Mais ça peut aussi être le compteur en amont, le 9316 en E5 qui aurait sa pin #12 morte.
Ton hypothèse est quand même la plus vraisemblable.

Citation de: Little_Rabbit le Samedi 23 Janvier 2021, 23:31:37 PM
PS : as-tu bien reçu le schéma de la carte mère Taito mis au propre que je t'ai adressé par email ? :)

Non, rien reçu du tout !  :'(
Je te redonne mon adresse e-mail par MP !

Bonjour,

Je possède une borne Gun Fight depuis le dernier RT effectué avec Sentinelle.

L'ensemble des faisceaux est soudé aux différents peignes du PCB, il faut que j'achète les peignes adéquats.

La borne n'a pas encore été testée, cependant elle a dû rester une paire d'années dans un local d'un exploitant.

Je vais suivre ce WIP avec beaucoup d'intérêts.

Bonjour.

On continue le dépannage de ce PCB Gun Fight.
La dernière fois, j'avais observé que l'image avait un défaut de zones clonées.
Un petit peu de réflexion à tête reposée mettait en cause le bit AD3 du bus d'adresse de lecture des RAMs.

C'est parti à grands coups d'oscillo !

Voici une vue d'ensemble de mon environnement de dépannage :


L'ordi portable me sert à lire les schémas électroniques.
Il est posé sur la valise renforcée dans laquelle je range l'oscillo.
Juste à droite de la valise, il y a le pistolet à dessouder "FR-300" de chez "HAKKO" (lien (https://www.batterfly.com/shop/en/soldering/stazioni-dissaldanti/hakko-fr-301)), conseillé par Petit_Lapinou et c'est un excellent choix.
Au pied de la perceuse à colonne, ce sont les notes de mon aide de camp, qui aime dessiner et écrire.

Revenons à notre bit AD3...
Le bit AD3 qui est envoyé aux RAMs est, comme l'a indiqué dans un message précédent Petit_Lapinou, généré par le composant en F5 :


Ce composant a la lourde tâche de commuter 4 des bits d'adresse envoyées aux RAMs à partir de 2 sources possibles :

• les adresses croissantes générées par le "scan" qui parcourt la RAM vidéo pour lire les pixels et générer le signal vidéo ;
  elles sont connectées sur les entrées "I0n", soit les pins #2, #5, #11 et #14
• les adresses issues du CPU quand il veut lire ou écrire en RAM, peu importe la raison
  elles sont connectées sur les entrées "I1n", soit les pins #3, #6, #10 et #13

Le choix se fait selon la pin #1 "SEL" :

• SEL = 0, on balance aux RAMs l'adresse courante générée par le "scan" vidéo
• SEL = 1, on balance aux RAMs l'adresse voulue par le CPU pour lire ou écrire

Ce qui nous intéresse, c'est le bit AD3 en rouge, issu soit du signal en vert (scan vidéo) ou en magenta (CPU).
Et il faut regarder ce qui se passe quand SEL = 0, c'est à dire que c'est le scan vidéo qui accède aux RAMs.
On doit avoir le signal rouge = le signal vert.

Vu qu'on est sur un bit d'adresse de rang assez faible (comprendre par là qu'il bouge tout le temps : 4 fois par ligne vidéo), je synchronise mon oscillo sur la dernière "RIPPLE CARRY" des compteurs générateurs des adresses de scan vidéo.
C'est ce signal en rouge :


Quand le tout dernier compteur générateur des adresses de scan vidéo a fini de compter, une impulsion sort sur sa pin "RIPPLE CARRY".
Imaginez compter "zéro plus un font un ; un plus un font deux ; deux plus un font trois ; etc...", mais ne pouvoir écrire qu'un chiffre.
Arrivé à neuf, on  dirait, "neuf plus un font dix ; j'écris zéro et je retiens un".
Cette pin "RIPPLE CARRY", c'est le "je retiens un" quand le compteur boucle.
Et celui-là boucle à la toute fin du scan vidéo, juste avant de reprendre au début de l'image et de la RAM vidéo.
Ainsi, j'ai là un top de synchro fiable qui va me permettre d'observer les adresses de scan sans que ça gigote dans tous les sens sur mon oscillo.

Voilà le résultat :

• en jaune, c'est la synchro de l'oscillo, le début de scan d'image
• en cyan, c'est la pin de sélection du chip F5, celle qui dit si on balance aux RAM l'adresse de scan vidéo (SEL = 0) ou l'adresse du CPU (SEL = 1)
• en magenta, c'est le bit AD3 de l'adresse de scan. Déjà on voit qu'elle bouge, donc le compteur E5 en amont semble à priori bon
• en vert, c'est le bit AD3 qui est envoyé aux RAMs. quand on a SEL = 0, on doit retrouver le signal magenta. Quand on a SEL = 1, on utilise l'adresse demandée par le CPU et pour le moment on s'en fout

Voilà l'analyse :


Les 8 premières fois où on a SEL = 0 (scan vidéo) et le signal magenta = 0 (1er quart de la 1ère ligne de l'image vidéo), on voit qu'on balance systématiquement un "1" aux RAMs (signal vert), alors que ça aurait du être un 0 (signal magenta). J'ai entouré ça en rouge.
Ensuite, les fois suivantes (entourées en orange), on a le signal magenta qui vaut 1 (2e quart de la 1ère ligne de l'image vidéo) et on balance bien un "1" aux RAM (signal vert).
CQFD : sur le 1er quart de l'image, on a AD3 qui vaut 1, donc on va lire (et afficher) en fait les pixels présents dans le 2e quart en RAM.

On a notre coupable : le chip "9322" en F5 !

Je le dessoude :


Notez ces tordus de chez Midway qui pliaient les pattes des composants comme des psychopathes avant de les souder :


Il faut vraiment de la patience (un bon outillage aide beaucoup) pour extraire ça sans tout arracher !

Bon, le problème c'est que je viens de dessouder une bouze de machin un peu exotique : un "9322"...  :'(
Je n'ai pas ça en stock et une recherche rapide sur ibé donne des douleurs anales :


Le moins cher est à 9,04 € fdpin les 2 chips, soit 4,52 € l'unité !  (:x

Si on regarde de près, c'est simplement un clone du TTL 74157 avec des caractéristiques dynamiques un peu améliorées :

Le 9322 :


Le DM74157 :


Dans certains cas, le 74157 est un poil plus lent.
Je n'aime pas me faire recto-dilater sur ibé (ni ailleurs, en fait), donc je vais tenter avec mon DM74157 en stock.

Le composant d'origine est testé comme si c'était un 74157 :


Il est effectivement kaput.
Quand on regarde de près l'erreur du testeur, il dit :
EXPECTED: V0002:101L01LGL10L101V
RESULT: V0002:101L01LGH10L101V

Il faut causer un peut le testeur de composant couramment...
"V0002" signifie que c'est l'itération de test n°2.
Ensuite, on a une série de 16 caractères pour les 16 pins du composant.
"L" indique que le testeur doit vérifier que la pin est à 0.
Il dit "H" pour la pin #9 : il la voit à 1.
C'est exactement notre panne qui est identifiée par le testeur !

Je teste le remplaçant :


Il est bon, donc je le soude à la cow-boy, sans support !


Pourquoi sans support, d'autant plus que je ne suis pas sûr de ma substitution ?
Simplement parce que je n'aime pas les supports sur un PCB. C'est moche et source de faux-contacts.
Si jamais mon DM74157 ne fonctionne pas correctement, j'ai de quoi le ressortir sans risquer d'abîmer le PCB.

Il est temps de re-tester le PCB, toujours équipé de sa Sectro-ROM de test :


TADAAAAA !
J'ai corrigé le problème de zones d'écran clonées. Mon DM74157 fait bien le job à la place du 9322 exotique !
Maintenant le résultat du test de RAM s'affiche correctement.
Notez que dans ce que j'avais appelé la "zone 2" de l'image, toutes les RAMs sont vues OK, et c'était cette partie de l'image qui était clonée en "zone 1".

À suivre : on va s'attaquer à ce problème de RAMs !

Salut,

Cool, une panne en moins !  ^-

Pas cool, il y aurait 6 RAM à remplacer ?...  :-\

À voir si les buffers en sortie de RAM pourraient être en cause, mais de mon expérience, ce sont le plus souvent les RAMs qui sont cuites... :'(

Cela dit, as-tu refait le test sans EPROM depuis que le multiplexeur 74157 a été remplacé ? Car je serais curieux de voir la gueule des barres verticales à présent : elles étaient bien régulières, ce qui laissait présager des RAMs plutôt fonctionnelles.

[edit : je m'auto réponds => les lignes verticales ne donnent qu'une indication assez partielle de l'état des RAM, car pas mal de pixels sont à zéro, notamment les 10 bits de poids fort !... =>

Citation de: Little_Rabbit le Vendredi 25 Décembre 2020, 16:54:38 PM
D'ailleurs, si on observe cette valeur $0039 qui est mise en pile, d'un point de vue « pixel », cela donne ça :

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20201226114857-Little_Rabbit-Dites39.png) (https://gamoovernet.pixhotel.fr/pics/20201226114857-Little_Rabbit-Dites39.png)

]

A+

Je suis ce dépannage épique avec délectation.
Encore merci f4brice pour ce partage de ta grande expérience!
^-^

Bonjour.

Voici la suite de ce dépannage de PCB Gun Fight.

La dernière fois, la Spectro-ROM de test m'avait indiqué pas moins de 6 RAM kaput.
Il faut bien comprendre que le test consiste à écrire en RAM, relire, et déclarer une ou plusieurs RAM kaput si la valeur relue n'est pas celle qui avait été écrite.
En réalité, les possibilités de pannes sont très nombreuses :

• la donnée écrite par le CPU n'arrive pas / mal jusque dans la RAM (pb de driver de bus de données CPU => RAM)
• la donnée écrite par le CPU n'est pas écrite au bon endroit en RAM (pb de driver de bus d'adresses)
• la donnée n'est pas écrite du tout (pb de gestion du signal R/W)
• la donnée relue en RAM n'arrive pas / mal jusque dans le CPU (pb de driver de bus de données RAM => CPU)
• problème avec le latch qui contient le STATUS WORD du CPU
• problème de sélection de RAM
• problème avec la RAM elle-même

J'avoue n'avoir pas trop réfléchi à tout ça, et je me suis lancé tête baissée dans le dessoudage des 6 composants de RAM (préparez les tomates)...
Le pistolet à dessouder HAKKO est vraiment une merveille, et fait un travail extraordinaire :


En deux temps trois mouvement, la RAM est extraite :


Bien sûr mon aide de camp est à mes côtés. Elle aussi "réparer des cartes électroniques".
Elle m'a demandé un fer à souder pour faire comme papa.
L'avantage, c'est qu'à cet âge il n'y a pas besoin de réalisme. Le plus important c'est l'imagination.
Je lui donne une carte électronique issue de mon stock de donneurs d'organes, et un tournevis qui "on dit que c'est un fer à souder".
Elle pose l'extrémité du fer à souder sur sa carte et dit "brrrrrrr" pour imiter le bruit de mon outil :


Et voilà, les 6 RAM ont été dessoudées, des supports tulipes soudés et de nouvelles RAM mises en place :


Tout fébrile, je relance la ROM de test...


Bon ben voilà. Ça c'est fait. Absolument aucun changement.
Il est très peu probable que mes 6 RAM neuves soient toutes les 6 kaput en même temps...
Donc il faut arrêter de se lancer tête baissée dans le déssoudage, et réfléchir davantage...
Là vous pouvez me lancer des tomates pour avoir foncé sans réfléchir...

Ce qui est très bizarre, c'est que l'image vidéo n'est pas du tout buggée. Aucun pixel parasite, etc... L'image est nickel.
J'en déduis que le CPU arrive correctement à écrire en RAM, mais que la lecture déconne.
Dépanner ça à l'oscillo n'est pas simple, car durant le test RAM, tous les bus gigotent dans tous les sens et à toute vitesse.
Il est très dur d'arriver à observer LA lecture de RAM qui foire.

Je modifie donc le code assembleur de la Spectro-ROM de test.
Normalement, le test de RAM va jusqu'au bout des tests, puis affiche le résultat.
Ça ne m'arrange pas du tout : j'ai besoin d'observer à l'oscillo le crime au moment où il est commis !
Je modifie chaque test (il y en a 3 différents) pour faire un jump dans du code spécial à moi immédiatement dès la première erreur :


L'idée, c'est d'observer à l'oscillo une écriture et une relecture à la première adresse identifiée KO par la ROM de test.
Pour ça, mon code modifié va réaliser en boucle infinie :

• reset du watchdog, pour éviter que le CPU ne soit reseté par un élément extérieur
• écriture de la valeur 0x00 en RAM à l'adresse fautive
• relecture de l'adresse fautive
• écriture de la valeur 0xFF en RAM à l'adresse fautive
• relecture de l'adresse fautive
• GOTO 1

Ainsi à l'oscillo, dès la première erreur de RAM, je vais pouvoir observer l'écriture et la lecture à l'adresse fautive, alternativement avec des 0 et des 1.
Je flashe mon code modifié dans une EPROM 2716 :


Et voici le résultat :


Hein ? Quoi ? RAM = OK ? WTF ?
Encore une diablerie du Démon des Pannes qui se paye ma tronche ?
Plus AUCUNE RAM en erreur alors que juste avant j'en avais 6 ?
Sachant aussi que dans ce cas là, mon code n'est pas exécuté puisqu'il n'est appelé qu'en cas de pb détecté ?!

Je vérifie mon code assembleur, et il est parfaitement correct...
Finalement la réponse est dans le changelog de la Spectro-ROM de test :


En mars 2019, une personne prénommée "Marc" a identifié et corrigé un bug d'initialisation du test de RAM.
Ce bug provoquait des fausses erreurs sur les RAM d'adresse paire (colonne G).
Cette personne a partagé son travail tout comme Spectroman et moi. La version 1.3 de la ROM de test a été créée pour l'occasion.
Ma Spectro-ROM de test, retrouvée dans mon bazar était sûrement une version 1.1. C'est avec elle que j'ai consaté les 6 RAM en erreur.
Mais pour faire mon hack, je suis reparti de la version 1.3. J'ai donc intégré sans m'en rendre compte le bugfix de Marc.
Et effectivement, le bug corrigé par Marc pouvait provoquer des faux-positifs sur les 8 premières RAM (celles de la colonne G).
Le Démon des Pannes a bien dû savourer son popcorn en me regardant dessouder les 6 chips de RAM !

Donc je reflash une version 1.3 "propre" (sans mon hack destiné à m'aider à utiliser l'oscillo) et je remets aussi toutes les RAM d'origine.


Là, je comprends mieux. Je pense que résultat est fiable et que la RAM #7 est vraiement en erreur, d'autant plus qu'il y a des petits cacas sur l'image.
Je change cette RAM #7 (située en G14) par une neuve, et voilà :


En réalité, je n'avais donc qu'une seule RAM de kaput.
Les 5 autres étaient des faux-postifs dû à un bug présent dans la version 1.1 (ma ROM de test initiale, qui était déjà flashée dans l'EPROM retrouvée dans mon bazard).

Maintenant que les RAM sont OK, je peux poursuivre le dépannge du PCB : le shifter hardware, l'audio et les inputs.
Je ferai l'audio et les inputs plus tard. Je veux d'abord réparer tout ce qui concerne le CPU.
À la fin du test audio, la ROM de test réalise un test de ce shifter hardware du PCB.
Ce shifter hardware est présent pour optimiser le code assembleur du jeu.
En effet cette bouse de CPU 8080 ne sait pas trop faire les décalages binaire. Il sait juste faire 1 bit à la fois.
Pour accélérer les décalages binaire, Taito a ajouté du hardware dédié.
Le CPU balance la data (8 bits) et le nombre de bits à décaler (de 0 à 7), et récupère sur un plateau le resultat calculé par le shifter hardware.
La Spectro-ROM de test vérifie l'exactitude des données calculées par le shifter, et affiche les éventuels écarts.

Voilà :


Ouergl ! Le shifter hardware est vraiment buggé jusqu'à l'os !
Normalement, on ne devrait avoir que des "00"...


À suivre : dépannage du shifter hardware, à partir des résultats affichés par la ROM de test

Salut,

Ah, je ne m'attendais pas à ça, même si j'avais trouvé que 6 RAM défectueuses, ça faisait peut-être beaucoup (quoique, mon PCB Space Invaders en avait 8 de défectueuses !...).

Mais tes résultats me surprennent beaucoup !  :-\

En effet, je m'étais penché de près sur la routine de Spectro, que j'ai utilisé des dizaines (voire centaines) de fois durant le laborieux dépannage de mon pcb Space Invaders :). Et j'avais bien remarqué qu'après un RESET, la routine de test donnait des résultats qui n'étaient jamais les mêmes qu'après une mise sous tension.

J'avais détaillé cela dans ce post (https://www.gamoover.net/Forums/index.php?topic=37683.msg660253#msg660253). La seule différence qu'il y a entre la version 1.2 et 1.3, c'est la bonne initialisation à 0 du registre DE qui sert à stocker les n° de RAM incriminées durant le test. Autrement dit, que tu aies eu des résultats farfelus après un RESET ne m'auraient pas surpris, mais lors du 1er test, à la mise sous tension, la version 1.2 donne un résultat fiable, car à la mise sous tension TOUS les registres du 8080 sont à 0, alors qu'un RESET ne remet que le registre PC à 0 ! :)

À moins que ton PCB soit équipé d'un 8080 un peu holé holé qui ne remette pas ses registres à 0 à la mise sous tension ! :D

Pour ton shifter, tu nous diras comment est ta carte fille, mais sur les 3 que j'ai eu l'occasion de dépanner, les composants utilisés pour mémoriser les valeurs décalées, des 74LS153, ils étaient toujours sur support gris, qui n'agrippent pas très bien les composants qui y sont insérés :

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20200218222634-Little_Rabbit-IMG-20200215-192324.jpg) (https://gamoovernet.pixhotel.fr/pics/20200218222634-Little_Rabbit-IMG-20200215-192324.jpg)

Les bugs détectés par la routine de Spectro ne venaient que de mauvais contacts :). Un peu d'exercice pour étirer leurs gambettes engourdies par des années de repos avait suffit à les remettre d'aplomb. :) J'ai même remplacé ces supports (mais toujours galère, d'autant que les pistes de la carte fille sont encore plus fragiles que celles de la carte mère !).

Un petit détail: pour le shifter, tu parles d'une valeur 8 bits qu'on récupère décalée du nombre de bits voulus => en réalité, c'est une valeur 16 bits à laquelle on applique un décalage pouvant aller jusqu'à 8 bits ;). J'avais détaillé son fonctionnement sur ce post (https://www.gamoover.net/Forums/index.php?topic=37683.msg629080#msg629080) :).

Hâte de voir la suite !  :-)=

A+

Un peu en retard..mais superbe environnement de travail!

Vu les résultats avec des composants pattes pliées je vais investir dans un fer à dessouder HAKKO, ça mettra mon dremel à dessouder au repos.

Tu as un assembleur 8080 ou tu fais "à la main"?

Salut,

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Tu as un assembleur 8080 ou tu fais "à la main"?

Je laisse répondre F4brice car je sais qu'il bosse sous Linux exclusivement :).

Pour ceux qui seraient sous Windows, on peut facilement se créer un environnement similaire, et programmer en assembleur 8080 grâce à Cygwin ! C'est Spectro qui m'avait expliqué tout ça et mis le pied à l'étrier. C'est grâce à cela que j'avais pu faire ma version 1.3 de l'EPROM de test, et même une pseudo démo Gamoover en 8080 sur PCB Space Invaders :D.

Ensuite, grâce à MAME en mode debugger, cela te permet de tracer pas à pas ton programme, comme si tu le testais sur le vrai hardware Midway : c'est top !  ^- J'avais fait ça pour essayer de trouver l'origine des glitches que j'avais sur mon PCB Space Invaders en panne, mais cela n'avait rien donné.

A+

Mame j ai pratiqué  en mode debugger pour modifier/corriger des eproms de flipper et faire mes roms de test (bally et gottlieb).
Le debugger m avait grandement facilité les mises au point.

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Un peu en retard..mais superbe environnement de travail!

Merci.
L'établi a été fabriqué sur mesure par mon Papa !  :-*

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Vu les résultats avec des composants pattes pliées je vais investir dans un fer à dessouder HAKKO, ça mettra mon dremel à dessouder au repos.

Excellent achat, testé et conseillé par Little_Rabbit.
Je me suis laissé convaincre et je ne regrette pas.
C'est le seul outil à aspiration qui fonctionne réellement.
Tous ceux que j'ai pu tester avant étaient de la crotte en barre.
Il est actuellement en promo chez Batterfly (c'est là que j'ai acheté le mien) : lien (https://www.batterfly.com/shop/en/hakko-fr-301).

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Tu as un assembleur 8080 ou tu fais "à la main"?

Comme l'a dit Little_Rabbit, je bosse exclusivement sous Linux.
Mon seul PC sous Zindoz est un vieux portable pour faire fonctionner mon programmateur d'EPROM.
Avant, j'avais réussi à l'utiliser depuis une machine virtuelle via un bridge USB, mais depuis une mise à jour de la machine virtuelle, ça ne fonctionne plus.

Sous Linux, j'utilise :

• pour l'assembleur et l'éditeur de lien : "ASxxxx" d'Alan R. Baldwin : lien (http://shop-pdp.net/ashtml/asxget.php)
  l'outil est dispo pour de multiples plateforme, dont Linux, Zindoz truc, Zindoz machin, etc...
• pour la conversion Intel HEX => binaire de 2kB prêt à écrire dans une EPROM : "hex2bin" de Jacques Pelletier : lien (http://hex2bin.sourceforge.net/)

Je ne me fais pas iéch à lancer l'assembleur en ligne de commande manuellement.
Timothy Shiels héberge sur son site (http://outerworldarcade.com/arcade/space_invaders/space_invaders_test_rom.html) l'archive contenant le code source de la Spectro-ROM de test.
J'y ai complété le makefile et il suffit de lancer "make" pour que tout le boulot soit fait proprement.

Citation de: Little_Rabbit le Mercredi 27 Janvier 2021, 08:45:48 AM
À moins que ton PCB soit équipé d'un 8080 un peu holé holé qui ne remette pas ses registres à 0 à la mise sous tension ! :D

Par acquis de conscience, maintenant que les RAMs sont OK, j'ai reflashé une ROM de test mais en ayant mis en commentaire la correction de bug de la version 1.3 :


Le bug fix était d'effacer le registre "E" du CPU, qui contiendra les RAM en erreur de la colonne "G" (les RAM 1 à 8 ).
J'ai mis en commentaire cette ligne.
Je lance le test, donc sans le fix du bug de la version 1.3 :


Bon, je crois que la réponse est là.

On pourrait croire que mon CPU est buggé, mais il n'en est rien du tout.
Voici un extrait du "User Manual" du CPU :


Il est clairement indiqué que :

• au démarrage (power-up), tous les registres contiennent des données aléatoires (rouge)
• il faut balancer un RESET qui va forcer le PC (program counter) à 0x0000 (vert)
• ce RESET n'a aucun effet sur les autres registres, qui vont conserver leur valeur précédente (magenta)

Notez que sur la photo, la RAM "7" n'est plus vue en panne.
C'est la seule RAM que j'ai changé.

Il y avait bien un "vrai" bug dans la Spectro-ROM de test version 1.2, qui a été corrigée dans la 1.3 !  ^-

Salut,

Citation de: f4brice le Jeudi 28 Janvier 2021, 21:05:51 PM
Il y avait bien un "vrai" bug dans la Spectro-ROM de test version 1.2, qui a été corrigée dans la 1.3 !  ^-

On est bien d'accord ! :)

Oui la routine était bien buggée, car elle n'initialisait que la moitié de la paire de registre DE !

Je m'en suis rendu compte en novembre 2018, et j'ai corrigé le source de façon similaire à la tienne, mais en une seule instruction :).

Ta correction :

;---------------------------------------
; First RAM test
;---------------------------------------
ramtest::   mvi     d,0x00       ; clear the error register
            mvi     e,0x00


Ma correction :

;---------------------------------------
; First RAM test
;---------------------------------------
ramtest::   lxi     de,0x0000    ; clear the error register


On est bien d'accord, cela revient exactement au même ! :D

Mais j'ai dû mal m'exprimer sur ma surprise de ton test au résultat erroné dès la mise sous tension.

Durant mes essais, qui se chiffrent en dizaines et dizaines d'exécution de la routine de test en version 1.2, après une mise sous tension, son exécution donnait TOUJOURS un bon résultat. J'ai bien noté le passage de la doc Intel qui mentionne que les registres ont un contenu aléatoire à la mise sous tension, mais il faut croire que certaines spécimens de 8080 ont leur registre DE déjà à 0 car je t'assure que chez moi c'était le cas :-\ ! Sinon, le bug aurait été démasqué immédiatement :).

Quant aux versions successive du test de RAM, la 1ère que tu as utilisée, celle cachée dans ton bazar, c'était bien une version 1.2 et non 1.1 :).

Souviens-toi, voici l'historique :

version 1.0 => version de Spectro qui affiche 1 code erreur à la fois, avec un zigouigoui derrière le n° de RAM
version 1.1 => version que tu as améliorée en supprimant le zigouigoui de fin de ligne (+makefile, + etc.)
version 1.2 => version de Spectro super améliorée qui affiche d'un coup les erreurs présentes sur les 16 RAM
version 1.3 => identique à la 1.3, avec l'initialisation correcte de la paire de registres DE, qui fonctionne parfaitement à la mise sous tension, et surtout après un RESET

Tout cela n'a aucune importance, je sais, mais c'est juste histoire d'être précis :D.

Comment ça je serais psychorigide ???  :-[

:D

A+

Il est trop bien ce wip, on apprend pleins de truc et le tout avec un ton léger  ^-^

J'ai un pistolet à dessouder sur ma station que j'avais acheté il y a des années chez conrad.

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210128215514-Maitre_Poulpi-image.jpg) (https://gamoovernet.pixhotel.fr/pics/20210128215514-Maitre_Poulpi-image.jpg)

Ça m'avais permis de passer un niveau en m'embêtant un peu moins.
Par contre c'est sûr que je n'arrive pas au même résultat. L'afficheur de droite est hs (je ne peux plus régler la température) et il faut nettoyer souvent parce que ça se bouche. Je recharge en soudure aussi pour arriver à aspirer mieux mais c'est pas toujours aussi évident.
En tout cas, le résultat que tu montres en photo est super propre. Y a bien une raison pour que le budget soit plus élevé  :)

Re,

@Poulpi : oui, et un autre avantage du pistolet à dessouder HAKKO, c'est que c'est très compact ! Tu n'as pas la grosse station à côté, juste le pistolet, ça ne prend pas de place sur l'établi. Moi qui ai un tout petit atelier pour mes bricolages électroniques, j'apprécie. Mais il arrive aussi à ce modèle de se boucher :-\. J'essaye alors de le déboucher en le mettant en chauffe à la position maximale, et j'utilise les tiges fournies avec... Toutefois, une fois je n'y arrivais pas, j'ai essayé avec un tout petit forêt, sauf que maladroitement j'ai fini par casser le forêt dans la buse ! :'( Là c'est mort, impossible de l'en déloger je pense... Il faut d'ailleurs que je rachète cette taille de buse, je n'en ai plus qu'une à présent.

A+

Citation de: Maitre_Poulpi le Jeudi 28 Janvier 2021, 21:58:40 PM
En tout cas, le résultat que tu montres en photo est super propre. Y a bien une raison pour que le budget soit plus élevé  :)

Après avoir dessoudé un composant, je nettoie toujours le reste d'étain avec de la tresse puis je finis en nettoyant le PCB avec de l'alcool à brûler pour enlever certains restes de décapant.
Ainsi le champ opératoire est très propre.

Citation de: Little_Rabbit le Jeudi 28 Janvier 2021, 22:26:29 PM
Mais il arrive aussi à ce modèle de se boucher

Il arrive aussi que mon Hakko se bouche, mais ça reste rare.
Je ne suis pas aussi téméraire que toi pour oser tenter de le déboucher avec un foret.
J'utilise une queue de résistance, la plus petite possible en diamètre.
J'appuie sur le bouton d'aspiration et j'insère la queue (de la résistance, hein) dans le trou (du pistolet à dessouder, je précise).
Ça se débouche en 2 à 3 secondes.
L'aiguille fournie avec le pistolet est à mon avis trop grosse. Je n'ai jamais réussi à déboucher le pistolet avec elle.

Re,

Citation de: f4brice le Jeudi 28 Janvier 2021, 22:49:14 PM
../.. et j'insère la queue (de la résistance, hein) dans le trou (du pistolet à dessouder, je précise).

:)))))

Citation de: f4brice le Jeudi 28 Janvier 2021, 22:49:14 PM
../.. est à mon avis trop grosse. Je n'ai jamais réussi à déboucher le pistolet avec elle.

Ah c'est vrai, il y a ceux/celles qui les aiment plutôt grosses, et d'autres plus fines !... Il en faut pour tout les goûts !

=:))

Je  :fleche:

A+

Citation de: Little_Rabbit le Jeudi 28 Janvier 2021, 21:40:37 PM
Ta correction :
[couic]

En fait, c'est la correction de Marc Deslauriers, pas la mienne !
C'est lui qui est à l'origine de la version 1.3.

Citation de: Little_Rabbit le Jeudi 28 Janvier 2021, 21:40:37 PM
mais il faut croire que certaines spécimens de 8080 ont leur registre DE déjà à 0 car je t'assure que chez moi c'était le cas :-\ !

Mais mon brave monsieur, c'était le cas aussi chez moi, lors de ma précédente réparation d'un PCB Midway à base de 8080 (un Space Invaders) !  :D

Bonjour.

Voici la suite de ce dépannage de PCB Gun Fight.
La dernière fois, j'avais réparé la partie RAM du PCB en utilisant une ROM de test en version 1.3 et en changeant l'unique chip de RAM vu kaput.
Le test de RAM étant OK, je peux enchainer avec la répartion du shifter hardware.
La Spectro-ROM de test indiquait des résultats bien moisis.

Voyons en détail ces résultats :


Quand on a l'habitude de manipuler les nombres hexadécimaux, on voit très vite que la valeur 0x40 est omni-présente dans ce résultat.
Une ligne particulièrement intéressante est l'avant-dernière ligne.
Pour cette ligne, la ROM de test demande au shifter hardware de décaler la valeur 0x00, donc normalement le résultat doit systématiquement être 0x00.
Or le test indique que le résultat est toujours 0x40.
C'est vraiment le signe que le bit #6 du résultat lu par le CPU est scotché à 1 au lieu de 0.

Normalement, ce n'est pas une panne très dure à résoudre.
Voici la partie du schéma concerné :


Le bit #6 du résultat calculé par le shifter hardware (rouge) est issu soit du chip A3 ou A5 selon nombre de bits à décaler.
Les chips utilisés sont des AMD AM25S10. Iils ne savent faire que des décalages compris entre 0 et 3 bits.
Pour un décalage de 0 à 3 bits, on utilise le résultat de 2 chips sur les 4 présents.
Quand le décalage est entre 4 et 7 bits, on utilise les 2 autres chips dont les entrées sont câblées différemment.

Ce bit #6 calculé par le shifter arrive sur le chip D3. C'est un multiplexeur 4 entrées / 1 sortie.
Selon le port lu, le CPU obtient sur son bit #6 l'une des 4 entrées :

• le signal /LG3 (panel)
• le signal /RG3 (panel aussi)
• le signal /COIN (monnayeur)
• le bit #6 du résultat du décalage calculé par le shifter

C'est lui qui nous intéresse.
Quand le port 0x03 est lu, les entrées de sélection du multiplexeur (signal A jaune et B cyan) sont tous les deux à 1, et c'est le bit #6 du shifter qui est envoyé au CPU.
Ce signal passe à travers une porte non-inverseuse du chip C3.
Ce chip C3 a des sorties en collecteur ouvert qui tolèrent jusqu'à 15V.
Sur la partie CPU du PCB, il y a bien des résistances de pull-up.

Je modifie la ROM de test pour qu'elle réalise un décalage de 0 bits de la valeur 0x00.
Je devrais avoir 0x00 mais je sais que le CPU lit 0x40. Je veux voir à quel endroit le bit #6 "0" se change anormalement en "1".
En boucle infinie, mon programme modifié lit la valeur du shifter.
Çà va me permettre de mieux utiliser l'oscillo pour investiguer sur ce bit.


Déjà, je vérifie que tous les latches A6, B6, C6 et D6 ont bien tous leurs sorties à 0 puisque c'est cette valeur qui doit être shiftée.
C'est bien le cas, donc à priori aucun de ces 4 chips n'est en cause.
Ensuite je m'intéresse au multiplexeur D3. C'est lui qui aiguille le bit #6 calculé par le shifter vers le CPU.
Voilà la mesure à l'oscillo :


Les couleurs de l'oscillo sont celles du schéma plus haut.
Le bit #6 du résultat du shifter (rouge) est bien à 0 comme attendu. Jusque là tout va bien.
La sortie du multiplexeur (magenta) est elle aussi à 0.
Par contre, la sortie de la porte à collecteur ouvert (vert) du chip en C3 est foireuse.
Au lieu d'avoir une valeur proche de 0.0V, je mesure une valeur à environ 1,5V qui est interprétée comme un "1".
Son transistor de sortie est sûrement fatigué, et n'arrive plus à vaincre la pull-up de 470 Ω présente sur la CPU board.
C'est là la panne que je cherche.

Je dessoude le chip en C3 (un 7417) (désolé, j'ai oublié de faire la photo) et je le teste :


Il est effectivement kaput.
Notez que le testeur dit que la pin #10 devrait être "L" mais qu'il la mesure à "H".
C'est bien ça que j'ai observé à l'oscillo.

Je teste son remplaçant :


Vu qu'il est OK, il est rapidement soudé, toujours sans support :


Plutôt que de relancer ma ROM de test modifiée, je remets la Spectro-ROM de test non modifiée et je la laisse réaliser son test de shifter :


C'est tip-top, le bit #6 n'est maintenant plus scotché à 1 comme avant.
Un premier problème a bien été résolu.

Reste que le résultat du test n'est toujours pas OK ; il devrait y avoir des "00" partout.
Il reste donc un ou plusieurs problèmes avec le shifter hardware.
D'ailleurs, si on regarde bien, on observe un pattern assez flagrant !

À suivre : suite du dépannage du shifter hardware

Punaise je suis surpris, je crois que j'ai presque tout compris.
Faut dire aussi que c'est super bien expliqué  ^-^

Salut,

Le résultat qu tu obtiens durant le test du shifter est surprenant je trouve : c'est exactement la série de valeurs que le test s'attend à trouver !

Pour que nos lecteurs comprennent mieux, je me permets de citer ce que Spectro disait à propos de sa routine de test :

Citation de: spectroman le Mardi 17 Octobre 2017, 13:14:14 PM
Pour l'analyse de la matrice, n'oublie pas que j'ai fais des modifications sur la dernière version de la rom de test.

La matrice des résultats attendus est celle ci :
01 02 04 08 10 20 40 80
02 04 08 10 20 40 80 01
04 08 10 20 40 80 01 02
08 10 20 40 80 01 02 04
10 20 40 80 01 02 04 08
20 40 80 01 02 04 08 10
40 80 01 02 04 08 10 20
80 01 02 04 08 10 20 40
00 00 00 00 00 00 00 00
FF FE FC F8 F0 E0 C0 80

et le programme affiche le XOR entre cette dernière et celle renvoyée par les registres à décalage.

Et je me permets également de rappeler à nos fidèles lecteurs :D ce que fait une fonction XOR (ou exclusif) :) :

Citation de: Little_Rabbit le Mardi 17 Octobre 2017, 23:01:12 PM
Rappelons la table de vérité d'un OU Exclusif (XOR) :

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171017223232-Little_Rabbit-table-de-verite-du-ou-exclusif.gif) (https://gamoovernet.pixhotel.fr/pics/20171017223232-Little_Rabbit-table-de-verite-du-ou-exclusif.gif)

Le truc à retenir, c'est que 1 XOR 1 = 0 => donc si ce qu'on lit après le décalage est identique à ce qui est attendu, le résultat sera 0 !

Exemple :

    00000100   
XOR 00000100
    ________
=  00000000

Or, comme les valeurs affichée par le test sont exactement celles attendues, j'en conclurais qu'en sortie de shifter, tous les bits sont à 0 ! :-\

Je verrais 3 causes possibles :
- soit les 25S10 sont morts
- soit ce qu'on leur donne à décaler/multiplexer vaut toujours 0, auquel cas ce sont les latches 74175 qui sont morts
- soit les valeurs fournies par les 25S10 ne parviennent pas jusqu'au bus de donnée, auquel cas ce serait les multiplexeurs 74LS153 qui seraient défaillants...

Je dis ça en ayant regardé le schéma un peu en diagonale, je l'avais détaillé en 2017 mais c'est un peu loin :D (et celui que j'avais sur ma Si était la version alternative à base de 74151, un multiplexeur 8 sources vers 1, à la place des 25S10 qui sont des registres à décalage de 4 bits) :).

A+

Bonjour.

Voici la suite de ce dépannage de PCB Gun Fight.
La dernière fois, j'avais réparé le bit #6 en sortie du shifter qui était scotché à 1.
Le nouveau résultat des tests montrait bien que la valeur 0x40 avait disparue.
Néanmoins, le shifter est toujours détecté KO par la Spectro-ROM de test.

Si on regarde le résultat des tests :


Il y a un pattern bien particulier.
Comme l'a judicieusement remarqué Petit_Lapinou, ce sont là exactement toutes les valeurs théoriques que le shifter aurait dû calculer !?
Mais comme est-ce possible que la Spectro-ROM de test affiche les valeurs théoriques et non pas les valeurs réelles ?
En fait, ce sont bel et bien les valeurs réellement lues en sortie du shifter.
La ROM de test, pour aider au diagnostic, indique les bits en erreur mesurés en sortie du shifter.
Elle utilise pour ça un banal XOR (ou exclusif) entre la valeur attendue et la valeur mesurée.

• tout bit identique entre la valeur attendue et la valeur mesurée sera ainsi affiché à 0
• tout bit différent entre la valeur attendue et la valeur mesurée sera ainsi affiché à 1

Petit_Lapinou a tout a fait expliqué plus haut le fonctionnement du XOR.

Sachant que "TRUC XOR 0x00" est toujours égal à "TRUC", la conclusion, c'est que systématiquement, quelque soit la valeur à décaler et le nombre de bits de décalage à réaliser, le résultat du shifter est toujours 0x00 !
Ourgl. Ça craint du boudin.
Ça veut dire qu'il ne calcule rien du tout, quelque soit la valeur à shifter et le nombre de bits ! C'est la grève totale et illimitée.
Les causes sont multiples, et pas que salariales. On va aller jeter un coup d'œil avec l'oscilloscope.

Pour ne pas me battre contre des moulins à vent, je modifie une fois de plus la ROM de test pour lui faire latcher en boucle infinie une demande de décalage de 7 bits :


L'idée, c'est de synchroniser l'oscillo sur la pin #9 du latch et de regarder ce qui rentre (pins #4, #12 et #13) versus ce qui a été latché (pins #2, #10, #15 et accessoirement aussi la #14).
J'ai fait 3 mesures, en observant à chaque fois ce qui rentre (cyan) versus ce qui sort (magenta)...


Bon, c'est sans appel, le latch ne latche absolument pas.
Normalement, sur le front montant du signal jaune, le signal magenta devrait prendre la valeur du signal cyan.
Là, ce n'est jamais le cas.
Ce qui est quand même bizarre, c'est que les 3 bits serait tous les 3 en même temps kaput !?
Il faut regarder le datasheet du 74175 :


La première ligne est intéressante.
Le chip dispose d'une pin "/CLEAR" (la #1) qui, quand elle est active (niveau "L"), force la sortie à 0 et ce quelque soit la clock et les entrées.
On dirait bien que c'est notre symptôme.
Pourtant, sur le schéma Midway, la pin #1 est reliée à une résistance de pull-up, donc à l'état "H" en permanence :


Je fais la mesure :


En effet, il y a bien un problème : le signal /CLEAR (en vert sur ma mesure ci-dessus) est à 0.
Donc le latch est en permanence effacé et les entrées jamais recopiées sur les sorties.

C'est extrêmement rare, mais peut-être que j'ai la résistance de pull-up qui serait cassée ?
Je ne sais pas exactement où est située cette résistance sur le PCB, mais voyant ça...


... je ne serais pas surpris d'avoir ce genre de problème...  :'(

Je décide donc de regarder de près où va la petite piste en cuivre qui part de la pin #1 du latch en E6.
Je veux trouver ladite résistance de pull-up et lui parler de retraite anticipée.
Finalement, j'ai une grosse surprise :


Le latch E6 est le chip entouré en jaune.
La piste qui démarre de la pin #1 (rouge) part vers la gauche et arrive sur le chip en H6, pin #8 (entouré en orange).
C'est la sortie d'une porte inverseuse du chip en H6 (un 7404).
Quand on regarde l'entrée de cette porte (pin #9 en magenta), ça passe via le gros connecteur noir et ensuite ça va :

• à la pin #10 du "power connector", le connecteur d'alim
• et aussi à la pin #12 du CPU (RESET).

Je retrouve bien ça sur le schéma de la partie CPU :


Donc en réalité, le signal RESET issu de l'alim va aussi effacer tous les latches impliqués dans le shifter hardware + compteur de crédit + audio :


Je pense que Midway a dû constater des problèmes avec ces latches qui pouvaient déconner lors de la mise sous tension, et un p'tit coup de reset au démarrage les motive à mieux bosser.
Mon PCB est sûrement d'une révision plus récente que le schéma.

Hum, hum, le "problème" de ce signal RESET se situe entre le sol et l'oscilloscope : c'est... moi qui le fabrique !  ;)
Je n'ai pas d'alim Midway, donc j'utilise une pull-down de 10kΩ, avec un bouton poussoir connecté au +5V :


Au repos, le signal RESET est à 0 grâce à ma pull-down.
Quand j'appuie sur le bouton poussoir, il est à 1.
Je mesure la valeur de mon signal RESET au repos, et il n'est pas à 0V. Il est approximativement à 2V (en vert ci-dessous) :


Ça ne semble pas gêner le CPU pour fonctionner, par contre la porte inverseuse du 7404 en H6, elle n'aime pas.
Ma résistance de 10kΩ est trop grande, et elle ne tire pas assez le signal vers 0.
Cette valeur est typique quand on utilise des 74LSxxx, mais là on est en technologie "pas LS".
Les chips tirent plus de courant sur leurs entrées.
D'ailleurs, Midway utilise des résistances de 470Ω !
Je remplace ma 10kΩ par une 1kΩ :


Je relance une mesure sur le latch en E6 :


C'est bon, il fonctionne correctement, maintenant que son /CLEAR n'est plus actif (signal vert ci-dessus) !

Je relance la Spectro-ROM de test non modifiée :


TADAAAAAAAAA !!!!
C'est nettement mieux !
Je n'ai plus que 2 cas précis où le shifter déconne.


À suivre : suite encore et encore du dépannage du shifter !

Salut,

Bien vu le coup du signal RESET qui ne descend pas assez bas au repos !  ^-^

Du coup, cela m'a fait me poser une question : pourquoi n'ai-je pas rencontré le même problème, alors que mon bouton RESET est de même nature ?

Je viens de vérifier mon harnais bricolé : ma résistance de pull-down est de 4,7 KΩ !

Peut-être que cette valeur deux fois plus petite suffit-elle à me sortir d'affaire !?... :)

Quant à la panne résiduelle, elle montre que cela ne se produit que lorsque le bit de poids faible D₀ est à 1...

Je commencerais par regarder du côté du latch en D6 : sa broche 10 passe-t-elle à 1 quand on lui présente un 1 en entrée sur la broche 12 ? :)

A+

Salut,

La nuit portant conseil :), j'ai réfléchi un peu plus à la panne résiduelle, et je me suis rendu compte que ce que je disais hier soir n'a pas de sens :).

En effet, si le problème se situait au niveau du latch, la valeur erronée de D₀ se constaterait pour toutes les valeurs de décalage !

Or elle n'apparaît que lorsque D₀ vaut 1, et qu'on la décale d'un bit.

Non, le problème ne peut donc se situer qu'en aval des latches, et selon toute vraisemblance sur le 25S10 qui gère D₀...

J'ai examiné le schéma, mais je vous avoue que cette partie du shifter me fait faire un peu des nœuds dans la tête !... :-\

Je vous mets la table de vérité du fameux 25S10, sachant qu'il y en a 4 interconnectés, cela réclame une gymnastique intellectuelle qui je crois n'est plus de mon âge :D...

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210201120612-Little_Rabbit-AM25S10-table-de-vy-rite.jpg) (https://gamoovernet.pixhotel.fr/pics/20210201120612-Little_Rabbit-AM25S10-table-de-vy-rite.jpg)

Je vais attendre l'analyse de F4brice, sans me risquer à un nouveau pronostique ! :D

A+

Citation de: Little_Rabbit le Lundi 01 Février 2021, 12:14:51 PM
La nuit portant conseil :), j'ai réfléchi un peu plus à la panne résiduelle, et je me suis rendu compte que ce que je disais hier soir n'a pas de sens :).

En effet, si le problème se situait au niveau du latch, la valeur erronée de D₀ se constaterait pour toutes les valeurs de décalage !

Je confirme !  ;)

Citation de: Little_Rabbit le Lundi 01 Février 2021, 12:14:51 PM
Non, le problème ne peut donc se situer qu'en aval des latches, et selon toute vraisemblance sur le 25S10 qui gère D₀...

Je confirme aussi !  ;)

Citation de: Little_Rabbit le Lundi 01 Février 2021, 12:14:51 PM
J'ai examiné le schéma, mais je vous avoue que cette partie du shifter me fait faire un peu des nœuds dans la tête !... :-\

Je détaillerai ça dans mon prochain message !  <:)

Bonjour.

On continue le dépannage du shifter hardware de ce PCB Gun Fight.
La dernière fois, je n'avais plus que ces 2 cas en erreur :


Là, je vais m'attaquer à celui de la dernière ligne.
Il correspond au test suivant :

• valeur à décaler : 0xFF
• nombre de bits à décaler : 1
• valeur théorique attendue : 0xFE
• valeur lue par la ROM de test : 0xFE XOR 0x02 = 0xFC
  il d'agit du bit D1 calculé par le shifter qui est vu à 0 alors qu'il aurait dû être à 1
  ce bit D1 du shifter provient du bit D0 de la donnée à décaler, puisque le décalage est de 1 bit

Toujours pour bien synchroniser mon oscilloscope et éviter les problèmes lors de la mesure, je modifie la ROM de test :


Je fais décaler au shifter la valeur 0xFF d'1 seul bit, et je lis en boucle infinie le résultat.

Citation de: Little_Rabbit le Dimanche 31 Janvier 2021, 23:39:39 PM
Je commencerais par regarder du côté du latch en D6 : sa broche 10 passe-t-elle à 1 quand on lui présente un 1 en entrée sur la broche 12 ? :)

Je pense que oui, car la première valeur de la dernière ligne du test du shifter est bonne (décaler 0xFF de 0 bit).
Ca veut dire que le latch D6 propose bien sur ses 3 sorties des données à 1.
Mon regard se porte plutôt sur le shifter en B3...

Voyons comment fonctionne ce shifter et comment Midway les utilise.
Voilà un extrait de son datasheet :


Il dispose de 2 entrées S1·S0 qui lui indiquent le nombre de bits à décaler, soit de 0 à 3 bits.
Il dispose de 7 entrées I3·I2·I1·I0·I-1·I-2·I-3, et de 4 sorties Y3·Y2·Y1·Y0.
Quand on décale de 0 bit, on a Y3·Y2·Y1·Y0 = I3·I2·I1·I0.
Quand on décale de 1 bit, on a Y3·Y2·Y1·Y0 = I2·I1·I0·I-1.
Quand on décale de 2 bits, on a Y3·Y2·Y1·Y0 = I1·I0·I-1·I-2.
Quand on décale de 3 bits, on a Y3·Y2·Y1·Y0 = I0·I-1·I-2·I-3.

Vu qu'il ne calcule que 4 bits en sortie, ce shifter est utilisé par paire, chacun calculant 4 des 8 bits du résultat.
Ensuite, vu qu'il ne sait faire que 0/1/2/3 bits de décalage, Midway utilise 2 paires de 2 paires, soit 4 chips.
La première paire (B3 + A5) est utilisée pour des décalages de 0 à 3 bits, l'autre paire (B5 + A3) est utilisée pour les décalages de 4 à 7 bits.

Le shifter hardware de Midway est à cheval entre du 16 bits et du 8 bits.
On latche 2 valeurs de 8 bits, et on lit un résultat de 8 bits.
La valeur à décaler s'appelle "DS" (Data to Shift).
Elle s'écrit en binaire : DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Selon le décalage à appliquer on va lire :

Donnée en entrée :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Décalage de 0 bit :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Décalage de 1 bit :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Décalage de 2 bits :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
...	...
Décalage de 7 bits :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0

Le décalage "S" est écrit dans le latch en E6 lorsque le CPU écrit sur le port 0x02.
En sortie de E6, on a un mot de 3 bit qui est le décalage "S" en nombre de bits.
Ce décalage "S", en binaire s'écrit en 3 bits S = S2·S1·S0.
Quand on a de 0 à 3 bits à décaler, on a S = 0·S1·S0, soit un décalage de 0, 1, 2 ou 3 bits
Quand on a de 4 à 7 bits à décaler, on a S = 1·S1·S0, soit un décalage de 4 + 0, 4 + 1, 4 + 2 ou 4 + 3 bits.
Midway (Taito) utilise le bit S2 et son complément /S2 pour sélectionner soit la 1ère paire de shifter 2 × 4 bits, soit la 2e paire.

La 1ère paire est active quand S2 = 0. Les inputs de ces shifters sont directement les bits à décaler.
Ainsi le shifter en B3 qui calcule les 4 bits de poids faible reçoit sur ses entrées Y3·Y2·Y1·Y0 = DSB·DSA·DS9·DS8.
Son collègue en A5 qui calcule les 4 bits de poids fort reçoit sur ses entrées Y3·Y2·Y1·Y0 = DSF·DSE·DSD·DSC.
Chacun reçoit sur des entrées Y-1·Y-2·Y-3 les rangs immédiatement précédents.

La 2ème paire est active quand S2 = 1, soit /S2 = 0. Les inputs de ces shifters ne recoivent pas directement les bits à décaler, mais les bits déjà décalés de 4 rangs.
Ainsi le shifter en B5 qui calcule les 4 bits de poids faible reçoit sur ses entrées Y3·Y2·Y1·Y0 = DS7·DS6·DS5·DS4.
Comme ça, s'il doit décaler ses entrées de 0 bits, on a bien le résultat attendu : un décalage apparent de 4 bits.
Son collègue en A3 qui calcule les 4 bits de poids fort reçoit sur ses entrées Y3·Y2·Y1·Y0 = DSB·DSA·DS9·DS8.
Là ausssi, chacun reçoit sur des entrées Y-1·Y-2·Y-3 les rangs immédiatement précédents.

Voilà en résumé :

Nombre de bits à décaler :	de 0 à 3 bits	de 4 à 7 bits
Shifters impliqués :	B3 et A5	B5 et A3
Rôle de B3 :	calculer les 4 bits de poids faible du résultat	non impliqué ; sa pin /OE est à 1
Rôle de A5 :	calculer les 4 bits de fort faible du résultat	non impliqué ; sa pin /OE est à 1
Rôle de B5 :	non impliqué ; sa pin /OE est à 1	calculer les 4 bits de poids faible du résultat
Rôle de A3 :	non impliqué ; sa pin /OE est à 1	calculer les 4 bits de poids fort du résultat

Dans mon cas, j'ai un problème sur un décalage de 1 bit. Donc c'est B3 et A5 qui sont utilisés. B5 et A3 sont au repos.
Mon problème est sur le bit D1 du résultat, donc c'est B3 qui est suspect.


Pour mon test, je veux décaler 0xFF de 1 bit :

• S0 (jaune) = 1
• S1 (cyan) = 0
• DS8 = bit de poids faible de la dernière valeur latchée = 1 (magenta)
• décalage de 1 bit, donc il doit sortir sur Y1 (vert) que je dois mesurer à 1

Voici la mesure :


Désolé, j'ai oublié de faire une copie d'écran "propre" de l'oscillo. Il va falloir regarder sur la photo ci-dessus !

• en jaune, c'est le signal S0 envoyé au shifter ; il est bien à 1 car il faut décaler de 1 bit
• en cyan, c'est le signal S1 envoyé au shifter ; il est bien à 0 car il faut décaler de 1 bit
• non visible, mais vérifié : S2 = 0 car il daut décaler de 1 bit
• en magenta, c'est le bit DS8 envoyé au shifter en I0 ; il est bien à 1 car la valeur à shifter est 0xFF
• en vert, c'est la sortie Y1 du shifter, qui devrait être égale à I0 puisqu'on shift de 1 bit

Je constate que la sortie Y1 du shifter n'a pas la bonne valeur.
C'est bien le shifter en B3 qui est malade.

Pour le vérifier, je vais permuter B3 avec B5, et vérifier que le problème se déplace sur les décalages de 4 à 7 bits.

C'est parti, on dessoude tout le monde :


Pour une fois, je soude des supports tulipes et je remets en place les chips, en ayant pris soin de permuter B3 et B5 :


Je relance la Spectro-ROM de test :


Ouergllll....
Pas cool du tout, je suis revenu en arrière dans ma réparation. J'ai davantage de problèmes qu'avant...
Quand on regarde le problème, on se rend compte que le problème est lié au nibble de poids fort pour des décalages de 0 et 1 bit.
C'est lié à A5. Je vérifie... Hop, une soudure oubliée !!! Je répare...
Je relance le test :


Bon, c'est confirmé, le problème est bien lié à mon AM25S10 qui était en B3.
Il est un peu malade, pas complètement mort. Il doit partir en retraite.
Notez que je n'ai pas la 2e erreur que j'avais au début (dernière ligne).
C'est simplement que le résultat attendu a son bit D1 à 0, donc l'erreur est masquée.

Le problème, c'est que je n'ai pas de chip AM25S10 de remplacement...
Pas facile à trouver à prix raisonnable...
Sur arcadechips.com (https://arcadechips.com/), il apparaît à $2.50 fdpout (https://arcadechips.com/product_info.php?products_id=174)...
Sur ibé, c'est la classique recto-dilatation digne du congrès annuel de la SNFCP (https://www.snfcp.org/) :


Finalement, je suis joueur, j'ai acheté ça :


C'est un lot de 5 chips "DS2510DC" pour environ 10 € fdpin.
Je ne suis même pas sûr que ce soit les bonnes puces, impossible de trouver le datasheet de ces trucs...
Bon on verra bien, c'est p'tet 10 balles de perdues...
Si quelqu'un sait me trouver le datasheet d'un DS2510DC...
À priori, le fabriquant serait RFT MIKROELEKTRONIK (https://en.wikipedia.org/wiki/Kombinat_Mikroelektronik_Erfurt), un fabriquant de composants électroniques en ex-Allemagne de l'Est !
C'est bon, j'ai trouvé ça : lien (https://www.web-bcs.com/js/geoms/RF/DS/DS2510DC.jpg). Ca doit être bon !

J'ai aussi un plan B : faire une carte de substitution à base de 8 chips 74LS151.
Les révisions les plus récentes de Space Invaders ont laissé tomber ces puces exotiques AM25S10, et le même résultat est calculé à partir de 74LS151. C'est bourrin, efficace et parfaitement juste.
Une personne du nom de Grant le détaille un peu sur sa page Space Invaders (http://searle.x10host.com/spaceInvaders/index.html)

À suivre : bah soit réception de mes "DS2510DC" made-in-DDR et peut-être cramage de ma LOGIC board, ou sinon conception d'une petite board de substitution...

Salut,

Cool, ça progresse !  ^-^

Citation de: f4brice le Lundi 01 Février 2021, 22:34:05 PM
Une personne du nom de Grant le détaille un peu sur sa page Space Invaders (http://searle.x10host.com/spaceInvaders/index.html)

Lien intéressant !  Et sinon, une personne du nom de Little_Rabbit le détaille un peu sur son WIP Space Invaders (https://www.gamoover.net/Forums/index.php?topic=37683.msg629080#msg629080).

=:))

A+

Bonsoir.

Un peu de teasing, en attendant de recevoir les composants made in Deutsche Demokratische Republik (https://fr.wikipedia.org/wiki/R%C3%A9publique_d%C3%A9mocratique_allemande)...

Je me suis penché sur mon plan B, au cas où le plan A ne se déroulerait pas sans accroc.
Et puis de toute façon, ce ne sera probablement pas perdu, ça rendra sûrement service à quelqu'un.

Voilà :


Punaise, je me suis fait iéch grave de grave pour le routage.
Les 8 chips 74HCT151 sont en boîtier TSSOP16 (https://en.wikipedia.org/wiki/Small_outline_integrated_circuit#Thin-shrink_small-outline_package_(TSSOP)) pour qu'ils tiennent tous les 8 sur une petite carte qui fait la surface du rectangle délimité par les 4 shifters d'origine.
Chaque puce (sans les broches) fait 5,1 × 4,5 mm. Les broches sont au pas de 0,65 mm, soit environ 4 fois plus petit que les composants d'origine.
Ces trucs sont ultra-petits (j'espère que j'arriverai à les souder), et en plus ça rentre au chausse-pied...
J'ai quand même réussi à rester en 2 couches.

Je vais lancer un batch de 10 cartes, on verra bien...

Salut,

Génial !  ^-^

Oui, je mesure tout à fait la difficulté du routage de ces minuscules composants !... J'ai moi-même dernièrement fait une petite carte avec un TSH73CPT en boîtier TSSOP14 : ces bestioles font 5 x 4,4 mm, avec comme toi des broches distantes de 0,65 mm (soit un vide de 0,46 mm entre 2 broches :-\).

Leur soudure est réservée aux personnes non atteinte de Parkinson ! :D

A+

Salut,

Quelle est l'utilité de cette carte ?

Désolé, c'était évident pour moi alors je ne l'ai pas expliqué.
Les composants "AM25S10" sont exotiques et obsolètes, ce qui les rend pas très facile à acheter aujourd'hui à prix raisonnable.
L'idée, c'est de dessouder les 4 composants lorsque l'un ou plusieurs des quatre sont morts.
Ils sont remplacés par cette carte :


La carte reprend l'emplacement et l'espacement des 4 composants pour s'y fixer à leur place. Elle les substitue par des composants plus faciles à trouver.
Elle a besoin de 8 composants 74HCT151 qui ne sont ni obsolètes ni exotiques.

Citation de: f4brice le Vendredi 05 Février 2021, 20:19:09 PM
Désolé, c'était évident pour moi alors je ne l'ai pas expliqué.
Les composants "AM25S10" sont exotiques et obsolètes, ce qui les rend pas très facile à acheter aujourd'hui à prix raisonnable.
L'idée, c'est de dessouder les 4 composants lorsque l'un ou plusieurs des quatre sont morts.
Ils sont remplacés par cette carte :

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210205190150-f4brice-IMG-20210130-181815.jpg) (https://gamoovernet.pixhotel.fr/pics/20210205190150-f4brice-IMG-20210130-181815.jpg)

La carte reprend l'emplacement et l'espacement des 4 composants pour s'y fixer à leur place. Elle les substitue par des composants plus faciles à trouver.
Elle a besoin de 8 composants 74HCT151 qui ne sont ni obsolètes ni exotiques.

Merci f4brice pour les explications  :-*

Je n'y connais pas grand chose à ces PCB Bally.
Ces shifters font-ils la même chose que le MB14241 sur la Space Invaders?
(je n'ai pas vérifié : à tous les coups, il y a un post hyper détaillé de Little Rabbit là-dessus  :D)

Salut,

Citation de: Franzy2121 le Samedi 06 Février 2021, 21:43:56 PM
Ces shifters font-ils la même chose que le MB14241 sur la Space Invaders?
(je n'ai pas vérifié : à tous les coups, il y a un post hyper détaillé de Little Rabbit là-dessus  :D)

Sur le coup, je n'ai pas compris ta question, et j'avoue tout ignorer de ce MB14241 :).

Du coup j'ai rapidement Googlé, et les deux premiers liens sont très intéressants :

- un site (https://www.historyofinformation.com/detail.php?id=4256) qui décrit ce MB14241 comme historiquement le 1er shifter ou assistant "graphique" (GPU :-\) => mais je ne comprenais pas ce qu'ils voulaient dire, car tous les schémas et PCB que j'ai pu voir de Sea Wolf, Gun Fight ou Space Invaders, n'utilisent pas de MB14241 ! :-\

- et ici (https://www.aussiearcade.com/forum/arcade/arcade-technical-and-repair-questions/pcb-mods-and-hacks/102854-fujitsu-mb14241-ic-replacement) quelqu'un qui a fabriqué un substitut au MB14241 => là c'est très intéressant car sa substitution de MB14241 est en effet exactement le même shifter que celui que F4brice a reproduit, avec la différence que celui de F4brice s'enfiche sur un PCB sans MB14241, et celui du lien ci-dessus sur un PCB qui utilise un MB14241 !

J'en déduis que Taito dans les révisions de ses PCB a dû optimiser cette partie, en utilisant un composant intégré qu'est ce MB14241, quand Midway a continué à utiliser des composants discrets :).

J'ai aussi un PCB Taito de Space Invaders Part II à dépanner (issu de la borne récupérée dans ce roadtrip (https://www.gamoover.net/Forums/index.php?topic=27400.0)), il sera intéressant que je regarde dessus comment est fait son shifter!

Merci Franzy2121 pour cette tranche d'histoire du jeu vidéo que j'ignorais :).

Cela dit, qualifier ce MB14241 de premier GPU me semble aller un peu vite en besogne :D. J'aurais plutôt dit que c'est le 1er chip à combler les carences d'un processeur Intel, qui dans le cas du 8080 en matière de décalage et rotation de bits ne propose que des instructions mal foutues ;).

A+

J'ai une PCB Space Invaders Cocktail Deluxe ou les 8 74157 sont effectivement remplacés par ce MB14241.

Voilà les 2 types (images eBay)

CLASSIQUE
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210206231520-Franzy2121-s-l1600a.jpg) (https://gamoovernet.pixhotel.fr/pics/20210206231520-Franzy2121-s-l1600a.jpg)

MB14241
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210206231605-Franzy2121-s-l1600bb.jpg) (https://gamoovernet.pixhotel.fr/pics/20210206231605-Franzy2121-s-l1600bb.jpg)

D'où ma question naïve sur les shifters de Gun Fight car la petite carte designée par f4brice m'a mis la puce à l'oreille.
:)
Et qui m'intéresse fortement car mon MB14241 est tombé en miettes quand j'ai regardé ma carte.

Salut,

Ah c'est intéressant ! Midway a donc également exploité ce composant !

Je n'en ai jamais vu : 6 PCB Midway de cette génération me sont passés entre les mains (3 Gun Fight et 3 Space Invaders), et aucun d'entre eux n'avait ce circuit Fujitsu MB14241 ! :)

Citation de: Little_Rabbit le Samedi 06 Février 2021, 22:19:03 PM
J'ai aussi un PCB Taito de Space Invaders Part II à dépanner (issu de la borne récupérée dans ce roadtrip (https://www.gamoover.net/Forums/index.php?topic=27400.0)), il sera intéressant que je regarde dessus comment est fait son shifter!

J'ai jeté un œil à mon PCB Taito Space Invaders Part II, et à ma grande surprise, là aussi, point de MB14241, mais encore des 74151 x 8 :).

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210207125856-Little_Rabbit-SI-Taito-74151x8.jpg) (https://gamoovernet.pixhotel.fr/pics/20210207125856-Little_Rabbit-SI-Taito-74151x8.jpg)

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210207125930-Little_Rabbit-SI-Taito-74151x8-GP.jpg) (https://gamoovernet.pixhotel.fr/pics/20210207125930-Little_Rabbit-SI-Taito-74151x8-GP.jpg)

@Franzy2121 : tu devrais contacter le gars qui avait designé le substitut de MB14241, peut-être lui reste-t-il des PCB, ou peut-être pourrait-il te filer le Gerber de son projet pour faire tirer une nouvelle série d'une dizaine de plaques :).

A+

Bonsoir.

Aujourd'hui le facteur a déposé une petite enveloppe dans ma boîte à lettre :


Elle contient 2 CPU clones de l'Intel 8080 :


C'est la classe, c'est vraiment écrit en cyrillique sur la puce.  :-*
Je ne reconnais que "CCCP" qui se traduit en "URSS"...
Comme mon russe est un peu rouillé faute de l'exercer régulièrement, je tente un Gogole translate avec le mode caméra du téléphone portable...
C'est Gogole translate qui incruste la traduction en "réalité augmentée" :


J'adore !!!

Il est temps de tester le clone de technologie made in URSS :


Bon, ben c' est nickel tout ça !
Les 2 CPU fonctionnent parfaitement.
J'ai maintenant 2 CPU en spare qui sont en plus très atypiques !

Salut,

C'est cool que tes 8080 Ruskoff fonctionnent bien  ^-^.

Tu as de la chance, en plus d'être électroniquement et logiquement viables, ils ont l'air en bonne forme physique !

Sur les deux que j'avais commandés, j'en avais un qui était un peu estropié !...

(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20210209213351-Little_Rabbit-IMG-20191127-221853.jpg) (https://gamoovernet.pixhotel.fr/pics/20210209213351-Little_Rabbit-IMG-20191127-221853.jpg)

Il avait les pattes de travers, et surtout une plus courte que les autres !  :-[

Mais pour autant il fonctionnait parfaitement 8).

J'aimerais bien connaître l'histoire derrière ces clones de 8080 fabriqués derrière le rideau de fer !...

Étaient-ils fabriqués sous licence ? S'agissait-il de copies issues de reverse engineering ? Ou bien carrément issues d'espionnage industriel ? :)

A+

Bonsoir.

Il est temps de faire avancer ce WIP un petit peu.

Vendredi 19/02, le facteur a glissé cette lettre dans ma boîte à lettres :


Elle contient ça :


Je commençais à m'inquiéter pour cette commande.  :'(
Elle a été passée le 31/01 via ibé à un vendeur situé en Pologne, qui a été très rapide à faire l'envoi.
Elle aura mis quand même presque 3 semaines pour arriver...  >:D

Il s'agit de 5 composants "DS2510DC" fabriqués par "RFT MIKROELEKTRONIK", une usine située en ex Allemagne de l'Est !
Je les ai achetés dans l'espoir qu'ils soient effectivement le substitut fonctionnel des AM25S10 de chez AMD.
En tout cas, ils étaient présentés comme tels.

J'en installe un en B3 à la place du composant AMD que j'ai identifié comme KO :


En même temps, mon aide de camp (qui est toujours dans la place) a demandé à réparer une carte électronique, et a tenu à la choisir elle-même.
Elle a pris dans ma caisse de cartes donneuses d'organes une carte d'éval inconnue mise au rebus et récupérée par mes soins.
Elle a aussi choisi le "fer à souder" qu'elle voulait (un petit tournevis Philips) :


Elle ballade le tournevis un peu partout, le retire et souffle doucement. Je me demande qui elle peut bien imiter ?  :D
De mon côté, je démarre le PCB avec la Spectro-ROM de test...
Pas d'étincelles, pas de flammes, pas de fumée...
Au moment du test du shifter, je n'ai pas de tableau de chiffres, mais l'indication "SHIFTERS OK" :


Vouééééééé !  :-)=
C'est tout bon. Le test des shifters passe sans problème !  8)
L'échange est donc tout à fait valable !

L'aide de camp a elle aussi réparé sa carte :


À suivre : la prochaine étape, c'est la partie audio du PCB.
Cette partie n'est pas numérique, mais analogique.
L'audio de Gun Fight est biphonique : 2 hauts-parleurs (1 pour chaque joueur) mais pas stéréo.
Chaque côté audio peut sortir 2 sons :

• tir
• joueur touché

Bonsoir.

Encore une mise à jour de ce WIP.
Maintenant que la partie "shifter" est opérationnelle, je m'attaque à la partie audio du PCB.

Pour ce jeu, l'audio est relativement pauvre :


En fait, il n'existe que 2 sons différents "tir" et "joueur touché", et ce pour chacun des 2 joueurs.
Les sons sont démarrés depuis la partie CPU, mais tout est fait en électronique analogique ensuite dans la partie "Sound Generator".
Plus tard, les concepteurs de PCB utiliseront des puces spécifiques "PSG" Programmable Sound Generator, qui produisent ces sons si spécifiques (et que j'adore).
Mais on n'en est pas encore là...

Déjà, je complète mon banc de test pour alimenter les 2 amplis audio, et brancher 2 hauts-parleurs :


J'alimente les amplis audio en 12V, au lieu de 16,5V d'après les schémas Midway.
J'ai regardé le datasheet des amplis, et ils acceptent du 12V.

Ensuite, je modifie la Spectro-ROM de test pour lui faire jouer en boucle les 4 sons possibles.
Je ne connais pas le port utilisé pour commander les sons.
Certes je pourrais regarder le driver Mame, mais le schéma électronique me donne l'info :


Il faut que le signal mauve soit actif (entrée CLOCK du latch 74175 en F6).
Ce signal mauve est la sortie d'une porte AND.
Il faut donc que le signal vert AND le signal rouge soient actifs.
Le signal vert s'active quand on écrit sur un port (peu importe lequel).
Le signal rouge correspond au bit d'adresse A8 du CPU.
En conclusion, il suffit d'écrire sur n'importe quel port impair. Le port 0x01 fera l'affaire.

Maintenant, quelles valeurs écrire ?
Il faut regarder comment est pilotée la partie analogique, et de progresser en marche arrière :


Si je veux le son "L. SHOT", je dois avoir la sortie #1 (pin #2) du 7442 en G6 active (signal rouge).
Pour que cette sortie #1 soit active, je dois avoir en entrée du 7442 A=1 B=0 C=0 D=0 (signaux verts).
Ces signaux verts sont issus des sorties complémentées du latch 74175 en F6 (signaux magenta).
Je dois donc présenter en entrée du latch D4=0 D5=1 D6=1 D7=1.

En résumé, je dois compter de 1 à 4 sur le nibble de poids fort, et envoyer dans le port 0x01 le complément.
Voilà ce que ça donne en assembleur :


Je commence avec 0x10 pour le 1er son.
Je fais un XOR avec la constante 0xFF pour avoir le complément.
La valeur est écrite dans le port 0x01 => le son doit être joué.
J'écris 0xFF dans le port 0x01 => le son s'arrête ?
Je continue ainsi avec les autres valeurs.
Arrivé à 0x50, c'est la fin de la boucle.

Il est temps de tester...
Je me rends compte que tout ce qui concerne le joueur "LEFT" fonctionne très bien.
Par contre, je n'ai absolument aucun son pour le joueur "RIGHT".
C'est une situation qui me facilite la vie.
Les circuits "LEFT" et "RIGHT" sont totalement identiques.
Je peux donc comparer à l'oscillo "LEFT" et "RIGHT" un peu partout et tenter de trouver là où ça coince.

Finalement, je ne trouve pas grandes différences à part quelques pouillèmes assez peu significatifs.
Je décide de changer les aiguillages, et d'échanger les signaux LEFT / RIGHT un peu avant les amplis audio :


Maintenant, j'entends le son correct dans le haut-parleur "LEFT" quand on commande les sons "RIGHT".
J'en conclus que toute la partie analogique LEFT et RIGHT est OK jusqu'à ce point.

J'avance encore un peu plus le point de permutation, cette fois exactement au niveau des inputs des amplis audio :


Toujours le même résultat.
L'ampli audio "RIGHT" semble donc en panne.
Je démonte le dissipateur thermique qui est vissé sur les 2 amplis audios :


Vu qu'ils sont sur support, j'en profite pour les permuter.
C'est confirmé, maintenant j'ai la partie "RIGHT" qui fonctionne, mais plus la partie "LEFT".
L'ampli HS est un TAA-621.
Il se trouve, par je ne sais quel hasard improbable, que j'ai ça en stock...


Je n'ai que 4 références de composants TAA<kekchose>, et le TAA621 en fait partie :


Ouch, il y a un problème, les dissipateurs intégrés à la puce n'ont pas la même forme :


Un coup d'œil sur le datasheet et je comprends :


Midway utilise un TAA621A11 (à gauche), tandis que j'ai dans mon stock un TAA621AX1 (à droite).
D'ailleurs, si on regarde de près le schéma Midway, c'est bien précisé :


Il est indiqué aussi "LM354", mais je n'ai pas réussi à trouver le datasheet de celui-là...
Pour le moment, j'installe mon TAA621 bossu à la place de son collègue kaput :


C'est bon, tout fonctionne.
J'ai les sons corrects à la fois pour LEFT et pour RIGHT.
C'était bien l'ampli audio qui était mort, et en plus mon composant est OK.
Reste à trouver un TAA621A11...

Je vais faire un tour sur ibé...


Bon ben voilà : 3,00 € le composant + 1,08 € de frais de port.
Y'a rien à dire, c'est plus qu'honnête !
Hop ! J'ai commandé les trois disponibles. Comme ça j'aurai un peu de stock.

À suivre : changement de l'ampli audio, test du jeu complet avec les ROM d'origine