[WIP] Midway Gun Fight (1975)

[f4brice]

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.
La borne n'était plus trop d'origine : écran changé, PCB changé, pannel charcuté...

D'autre part, le sieur Sir Kayne vendait depuis juin 2009 le panel de cette borne, semble-t-il sans grand succès (lien).
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 ! 

[Little_Rabbit]

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 ! 

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, 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 ? 

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+

[Maitre_Poulpi]

Ca pleut des wips techniques en ce moment 

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 

[olschool]

Ca pleut des wips techniques en ce moment 

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 

[f4brice]

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_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 ! 

[olschool]

Je te les ai envoyé par MP

[f4brice]

Merci ! 

[Little_Rabbit]

Salut,

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

[f4brice]

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.

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 ! 

[pn_jeux]

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.

[gottlieb]

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 

[pet]

  Belle plume, c est super clair!

[Franzy2121]

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

[Little_Rabbit]

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 :

Oops! We ran into some problems.
You do not have permission to view this page or perform this action.
Please see this post 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 !

A+

[f4brice]

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, 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 :



Et ouais, c'est vicelard, hein ? 
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.

[Little_Rabbit]

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 :



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 ?