Salut,
Je ne sais pas si vous avez remarqué, mais Space Invaders est une borne très tendance en ce moment sur Gamoover :) : pas moins de trois WIP en cours ! Chronologiquement : ceux de Spectroman (un poil en standby semble-t-il ;)), jpetit et Sushy18 ! Sans compter le démon des pannes qui pourrait bien s'en prendre une dans la tronche très prochainement du côté de F4brice ;).
On dit que l'union fait la force, aussi je me décide à ouvrir ce post pour vous parler de mon WIP à moi de Space Invaders ! :) En réalité, cela fait un paquet de temps qu'il a démarré, mais comme toujours avec moi, cela n'avance d'aucun bout (j'ai dû être trop marqué par une fable de La Fontaine, vous savez, « Le lièvre lapin et la tortue » :D). Aussi, ce ne sera pas un WIP mais plutôt un WIVSP (Work In Very Slow Progress) :-\. Je vous mets mon billet que Sushy qui a démarré le dernier aura fini bien avant moi !
Pour les plus assidus et anciens de ce forum, vous vous souviendrez peut-être que pour moi l'aventure commença par une nuit sombre le long d'une route solitaire de campagne alors que je cherchais un raccourci que jamais je ne trouvai... Cela a commencé par une auberge abandonnée, et par un lapin resté trop longtemps sans dormir pour continuer sa route, cela a commencé par l'atterrissage d'un vaisseau venu d'une autre galaxie l'apparition d'une annonce sur leboncoin, relatée dans la rubrique « Bon plan sur un autre site » ;) , et qui mena à ce roadtrip (http://www.gamoover.net/Forums/index.php?topic=23596.0), qui se déroula le samedi 30 avril 2011.
Plus de six ans déjà ! :o
Je vous confirme que plus on vieillit et plus on ne voit pas le temps passer :-\ !
Après le roadtrip, la borne fût stockée dans la cave de la résidence où vit mon frère aîné. C'est une résidence moderne, et les caves me semblaient très saines. Mais pour autant, une cave ce n'est jamais une bonne idée !... Elle y est restée presque 4 ans, car pour pouvoir la ramener chez moi, il fallait d'abord qu'aboutisse notre projet de construction de maison, projet qui ne fût pas sans complications et retards divers... Quand je l'ai enfin ramené, elle était toujours en bon état, mais le meuble présentait quand même une forte odeur de moisi, ou du moins de vieille armoire de grand-mère (pour une Mamie, vous me direz que c'est un peu normal !... :D).
Par un bel après-midi fin janvier 2015, mon plus jeune frère m'aida à rapatrier la borne de Vannes à Nantes. On sortit la belle de sa cave :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180317-Little_Rabbit-DSCF9140.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180317-Little_Rabbit-DSCF9140.JPG)
Et on la chargea avec une N'Styl dans une remorque, à la verticale, quelques sangles et roulez jeunesse !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180343-Little_Rabbit-DSCF9143.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180343-Little_Rabbit-DSCF9143.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180357-Little_Rabbit-DSCF9145.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180357-Little_Rabbit-DSCF9145.JPG)
(pas sûr que nous obtiendrions notre diplôme de sanglage... :-\)
Une fois installée dans la chambre d'amis, j'ai pu commencer à m'en occuper. Il s'agissait essentiellement d'enlever la couche de poussière et les traces d'usage et autres moisissures.
Petit état des lieux :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180443-Little_Rabbit-DSCF9331.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180443-Little_Rabbit-DSCF9331.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180609-Little_Rabbit-DSCF9303.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180609-Little_Rabbit-DSCF9303.JPG)
Le control panel est également bien poussiéreux, mais relativement peu usé !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180626-Little_Rabbit-DSCF9326.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180626-Little_Rabbit-DSCF9326.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180642-Little_Rabbit-DSCF9327.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180642-Little_Rabbit-DSCF9327.JPG)
Sur les Space Invaders, la sérigraphie est souvent presque toute effacée, surtout sur la partie inférieure. Ici il n'y a que quelques traces d'usure. Du coup je n'ai pas l'intention de le remplacer.
Le tube qui éclaire la lune et le ciel était bien piqué !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180720-Little_Rabbit-DSCF9340.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180720-Little_Rabbit-DSCF9340.JPG)
L'écran et le miroir sans tain également !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180842-Little_Rabbit-DSCF9342.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180842-Little_Rabbit-DSCF9342.JPG)
(on remarque que les bandes colorées sont encore présentes ! :-* )
Regardez un peu la couche de poussière sur le tube :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180905-Little_Rabbit-DSCF9345.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180905-Little_Rabbit-DSCF9345.JPG)
Par chance, et c'est surprenant, le ciel lui n'est pas du tout impacté, alors qu'il ne s'agit que d'un bout de carton !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180929-Little_Rabbit-DSCF9348.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180929-Little_Rabbit-DSCF9348.JPG)
Le bezel est en assez bon état :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180948-Little_Rabbit-DSCF9353.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180948-Little_Rabbit-DSCF9353.JPG)
Un petit manque en haut à droite (mais qui ne se voit pas quand elle est sur la borne), et de la peinture qui cloque en plein milieu, en haut sous le A :(. On me dit que je devrais « fixer » le processus en appliquant du vernis au dos : quel genre de vernis utilisez-vous ? Acrylique ou classique (qui se nettoie au White Spirit) ? Faut-il tamponner, plaquer la peinture une fois le vernis appliqué ? Le vernis doit-il pénétrer sous la cloque pour recoller la peinture au plexi ? Tout conseil sera le bienvenu car j'ai peur de faire plus de mal que de bien :).
En ce qui concerne le tube fluorescent, outre le fait qu'il est très sale, ce n'est visiblement pas le tube d'origine. Normalement, il faut une tube « lumière noire » blanc (!). Ici c'est je pense un tube tout ce qu'il y a de plus classique, avec la mention « blanc industrie ».
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929180733-Little_Rabbit-DSCF9358.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929180733-Little_Rabbit-DSCF9358.JPG)
Une fois nettoyé c'est déjà mieux :).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181130-Little_Rabbit-DSCF9361.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929181130-Little_Rabbit-DSCF9361.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181238-Little_Rabbit-DSCF9377.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929181238-Little_Rabbit-DSCF9377.JPG)
=> seulement 21466 parties au compteur (qui est bien branché et continue à s'incrémenter) ! Ce n'est pas beaucoup je trouve non ? Peut-être cela explique sont relativement bon état cosmétique.
Pour le nettoyage de la borne, j'ai simplement utilisé de l'eau chaude dans laquelle j'ai dilué du savon noir, et une microfibre, avec ensuite un peu d'huile de coude :). Pour certaines parties plus sales, j'ai parfois utilisé un peu de Cif (légèrement abrasif, mais pas trop pour ne pas abîmer/décaper).
avant :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181353-Little_Rabbit-DSCF9313.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929181353-Little_Rabbit-DSCF9313.JPG)
après :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181414-Little_Rabbit-DSCF9325.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929181414-Little_Rabbit-DSCF9325.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181438-Little_Rabbit-DSCF9312.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929181438-Little_Rabbit-DSCF9312.JPG)
Pour l'odeur de moisi ou « vieux meuble », j'ai lu que du bicarbonate de soude disposé dans une soucoupe devait absorber l'odeur.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181502-Little_Rabbit-DSCF9370.JPG) (https://gamoovernet.pixhotel.fr/pics/20170929181502-Little_Rabbit-DSCF9370.JPG)
J'ai fait l'expérience, et ce n'est pas fulgurant... Sans doute l'odeur s'est-elle un peu atténuée avec le temps... Pour voir si c'était plus efficace, j'ai carrément saupoudré le fond de la borne de bicarbonate...
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181553-Little_Rabbit-20170929-162718.jpg) (https://gamoovernet.pixhotel.fr/pics/20170929181553-Little_Rabbit-20170929-162718.jpg)
Une fois aspirée c'est propre.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181609-Little_Rabbit-20170929-163326.jpg) (https://gamoovernet.pixhotel.fr/pics/20170929181609-Little_Rabbit-20170929-163326.jpg)
Globalement l'odeur est nettement plus discrète 2 ans après l'application du bicarbonate. Mais est-ce son action, ou simplement le fait d'être dans un lieu chauffé et ventilé ? Je viens à nouveau d'en saupoudrer généreusement, me disant que ça ne mangeait pas de pain :).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181802-Little_Rabbit-20170929-163505.jpg) (https://gamoovernet.pixhotel.fr/pics/20170929181802-Little_Rabbit-20170929-163505.jpg)
Mais il faudra un jour que je prenne mon courage à deux mains pour vider le meuble complètement et vraiment lessiver intégralement l'intérieur !
Une fois à peu près nettoyée, elle a pu prendre place dans le salon dès avril 2015 ! :-*
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170929181831-Little_Rabbit-20150409-084516.jpg) (https://gamoovernet.pixhotel.fr/pics/20170929181831-Little_Rabbit-20150409-084516.jpg)
Et ce seulement pour la déco, puisque le PCB est en panne !...
C'est du reste ce dont je vous parlerai dans le prochain post ! :)
A+
Bonjour <:)
courage petit lapin ^-^
c'est sans te mettre la pression (qui a dit 1664)
il faudra qu'on y joue au voyage pour le prochain BGS ;)
A++ <:) <:)
j'ai hâte de voir la suite :-)=
Elle est magnifique. Jalousie! >:D :D
Ah ouais, elle est propre et n'a pas l'air d'avoir été très abîmée.
Bon courage pour la suite ;)
Mon P'ti lapin ;)
Il n'y a pas de date de péremption pour les WIP (heureusement ;D ;D )
La borne est magnifique !! C'est déjà une bonne base ^- ^-
Il va p't'être falloir que je m'en dégotte une à force :-\ :-\
Le plus long était de s'y mettre ^- Y-a plus qu'à garder le cap ^-^ ^-^
Dans la vie de l'arcade, il y a 2 types de personnes...ceux qui on une Space Invaders et ceux qui on Space Attack murale...!
Ou
Si t'as pas une Space Invaders à 40 ans, t'as raté t'as vie...!
:D :D =:))
Très belle borne ^- LA KLASSE !!!
très belle borne et vu son âge, vraiment bien conservée ^- ^-
ça reste un grand classique, y'a pas à dire...
Salut Little,
J'ai l'impression d'avoir déjà vu cette borne quelque part :D
Un Space Invaders de toute beauté <:)
Bon courage pour le pcb en espérant pouvoir le ressusciter...
yo, tu testera le tube de sushy et tu me donnera ton retour ;)
je trouve encore qu'il est trop eclatant et pas assez fluo, mais c'est ptet moi :D
disons que je vois plus mes ET quand je joue dut a la clarté
^-
Borne mythique parmi tant d'autres.
la mienne est aussi en attente de wip ....
succomberais-je à la folie invadiénne qui semble toucher ce forum...
a suivre.
en attendant je me permet d'éclairer ta lanterne concernant l'application de vernis afin de réduire la pelade vidéoludique
:D :D
Citation de: Little_Rabbit le Vendredi 29 Septembre 2017, 18:30:04 PM
de la peinture qui cloque en plein milieu, en haut sous le A :(. On me dit que je devrais « fixer » le processus en appliquant du vernis au dos : quel genre de vernis utilisez-vous ? Acrylique ou classique (qui se nettoie au White Spirit) ? Faut-il tamponner, plaquer la peinture une fois le vernis appliqué ? Le vernis doit-il pénétrer sous la cloque pour recoller la peinture au plexi ? Tout conseil sera le bienvenu car j'ai peur de faire plus de mal que de bien :).
Oui il faut la Fixer
Applique du vernis acrylique (lavable à l'eau chaude) bombe ou flacon
et n'hésite pas a saturer de vernis au point de rendre la couche de peinture souple
(N'hésite pas a charger)
pour pouvoir plaquer ce qui s'est décollé (tamponner)
et oui tu peux en mettre un peu de vernis sous la cloque
;)
je te conseille l'excellent article paru sur mon site au sujet de la résurrection d'une glace de flipper
:D :D :D
WIP BACKGLASS SILVERBALL (http://lejrs.e-monsite.com/pages/content/wip-silver-ball-mania-definitif.html)
<:) <:)
Bon wip a toi je sent que je vais pas tarder a lancer le mien, vous m'avez bien chauffé
:D
je vais lire ca avec attention sachant que les produits ricains ne sont plus exporté ^-
Salut,
Merci pour vos commentaires et encouragements ^- !
Citation de: zebassprophet le Samedi 30 Septembre 2017, 08:45:22 AM
yo, tu testera le tube de sushy et tu me donnera ton retour ;)
Oui, je suis d'accord sur le fait que ce n'est pas encore tout à fait ça. J'en ai touché un mot à Sushy :). Je ferai un test comparatif prochainement.
Citation de: olschool le Samedi 30 Septembre 2017, 09:27:56 AM
Oui il faut la Fixer
Applique du vernis acrylique (lavable à l'eau chaude) bombe ou flacon
et n'hésite pas a saturer de vernis au point de rendre la couche de peinture souple
(N'hésite pas a charger)
pour pouvoir plaquer ce qui s'est décollé (tamponner)
et oui tu peux en mettre un peu de vernis sous la cloque
;)
je te conseille l'excellent article paru sur mon site au sujet de la résurrection d'une glace de flipper
:D :D :D
WIP BACKGLASS SILVERBALL (http://lejrs.e-monsite.com/pages/content/wip-silver-ball-mania-definitif.html)
Merci pour ces explications ! ^-^
Oui, à présent je me rappelle avoir lu ce post sur ton site ! Je le relirai avant de me lancer :).
Comme expliqué juste avant, le PCB est donc en panne (quelle surprise non ?? ;)). Mais avant d'en arriver à cette conclusion, j'ai bien sûr procédé aux vérifications d'usage :
- débrancher l'alim et le PCB
- mise sous tension
- mesure des tensions en sortie d'alim
Premières conclusions :
- à la mise sous tension le marquee s'illumine
- le tube fluorescent qui illumine le ciel et la lune s'allume lui aussi
- le cul du tube rougeoie
- les tensions continues en sorties d'alim sont bonnes
C'est déjà pas mal :). Ne reste plus qu'à rebrancher le PCB alors...
Premier essai et le verdict tombe sans appel : le PCB ne fonctionne pas. J'ai à l'écran des bandes horizontales de pixels figés (pas de photo :-\). Le point positif me direz-vous, c'est que l'écran fonctionne ! Yeah !! Quand on sait que certaines pièces pour ces vieux écrans noirs et blancs sont introuvables, c'est déjà une bonne chose.
Un point qui participa au fait que ce WIP a été particulièrement lent, c'est qu'au mois de mai 2015, en discutant avec aje_fr, il me dit « Ah mais j'ai un PCB Space Invaders original, et depuis que je l'ai réparé, il fonctionne ! Je peux te le prêter si tu veux :) ».
Wouha, quelle aubaine !! J'allais pouvoir jouer à la borne et la rendre provisoirement fonctionnelle sans rien faire ^-^ !
Si tôt proposé, si tôt fait :). Aje m'a prêté son PCB, et il fonctionnait quasi complètement !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184106-Little_Rabbit-20170929-212913.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184106-Little_Rabbit-20170929-212913.jpg)
Seuls certains bruitages étaient absents ou défaillants. Du coup, j'ai utilisé ainsi durant des mois (années...) le pcb d'aje, sans vraiment me faire violence pour réparer le mien !... :-\
En novembre 2015, je me suis tout de même mis au chevet du malade.
Parce que je ne trouve jamais très pratique de dépanner un PCB à même la borne, j'ai bricolé un connecteur encartable pour pouvoir le dépanner dans mon petit atelier. Il me permet d'alimenter le PCB en +5V, +12V et -5V, et de récupérer le signal vidéo composite que j'envoie vers un moniteur N&B.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184147-Little_Rabbit-20170929-222043.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184147-Little_Rabbit-20170929-222043.jpg)
Je peux à présent alimenter le PCB, et voir le résultat sur le moniteur :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184208-Little_Rabbit-P1000748.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930184208-Little_Rabbit-P1000748.JPG)
C'est à dire la même chose que ce que j'avais sur la borne (mais tourné de 90° puisque mon écran ici n'est pas en « tate » comme sur la borne ;)).
Après cette mise en place, je me souviens avoir programmé des EPROM. Avoir modifié les straps pour que le PCB accepte des EPROM 2716 (mais je crois ne l'avoir pas fait comme il faut, le schéma Midway étant confus, et je n'avais pas fait de recherches sur le net...).
Puis je pense qu'il y eu une sorte de trou d'air entre novembre 2015 et mai 2017, date à laquelle je me suis à nouveau penché sur la question ! :-[
Une particularité de la borne Space Invaders (et d'autres bornes Midway de l'époque), c'est que le circuit qui effectue le RESET du PCB à la mise sous tension n'est pas intégré au PCB comme c'est généralement le cas, mais situé sur la carte d'alim ! Pas très pratique car cela interdit le remplacement par une alim lambda (à laquelle il manquerait le fameux RESET !). Dans mon cas, j'ai fait simple : j'ai utilisé une alim arcade classique, et j'ai ajouté un bouton de RESET manuel. Ainsi, après la mise sous tension, il me suffit d'appuyer sur le bouton pour reseter le PCB. Et c'est pratique car cela me permet de reseter à la demande ! ^-
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184321-Little_Rabbit-20170929-222204.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184321-Little_Rabbit-20170929-222204.jpg)
Ce signal de RESET envoyé par l'alimentation est « au repos » au niveau bas (masse ou GND) et passe au niveau haut (+5V) une fraction de seconde à la mise sous tension. En plus de mon bouton poussoir, il faut donc mette une résistance de pull-down qui va fixer le niveau à la masse en l'absence de pression sur le bouton poussoir.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184353-Little_Rabbit-Pull-down-resistor-circuit.png) (https://gamoovernet.pixhotel.fr/pics/20170930184353-Little_Rabbit-Pull-down-resistor-circuit.png)
Si j'appuie sur le bouton RESET, c'est absolument sans effet. Visiblement le processeur est incapable d'initialiser quoi que ce soit du PCB. Mais le CPU fonctionne-t-il seulement ?
En préambule de ce qui suit, rappelons que Space Invaders est animé par un microprocesseur 8080 de chez Intel. Ce CPU n'est pas génial en comparaison de ce qui s'est fait après : nécessité de circuits Intel annexes (pour l'horloge, les drivers de bus, ...) et a besoin de 3 tensions d'alimentation (+5, +12 et -5V ! :o). Mais n'oublions pas qu'il est sorti en 1975, époque où les microprocesseurs 8 bits ne couraient pas les rues :D.
Autre explication préliminaire pour que vous compreniez mon exposé : un PCB de Space Invaders (et d'autres jeu Bally Midway de l'époque) est constitué de deux cartes :
- la carte mère qui contient le CPU, les RAM et ROM, gestion vidéo, etc.
- une carte fille, enfichée perpendiculairement, qui génère les sons, gère le watchdog + RESET, et dans le cas de SI, des registres à décalage
En présence d'un PCB qui ne semble pas du tout booter, je pense qu'on peut commencer par observer à l'oscilloscope les différents signaux vitaux du CPU qui sont ici :
- ses 3 alimentations
- le RESET
- les signaux d'horloge
- l'activité ou non du WR (indique si le CPU écrit en mémoire)
Ici le RESET ne fonctionnait pas.
Détaillons par conséquent le circuit RESET d'un PCB de Space Invaders qui se trouve sur la carte fille :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184603-Little_Rabbit-Circuit-RESET.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184603-Little_Rabbit-Circuit-RESET.jpg)
En 1) nous avons le signal de RESET généré à la mise sous tension par la carte d'alimentation (signal que j'ai moi remplacé par un bouton poussoir). Actif au niveau haut, il passe à travers une porte NON (7404) pour ressortir inversé : il est à présent actif au niveau bas.
En l'état, ce signal va reseter tout un tas de portes logiques de la carte fille (point 3))
Et il est également appliqué au « watchdog ».
Un watchdog (chien de garde en anglais) est un dispositif dont le but est de remettre sur ses rails un système qui aurait planté. Pour comprendre le principe d'un watchdog, on peut faire l'analogie suivante :
- on ouvre un robinet qu'on laisse couler en permanence pour remplir un seau
- le programme qui s'exécute s'engage à venir régulièrement vider le seau pour qu'il ne déborde pas
- si le seau déborde, cela signifie que le programme est planté ou bloqué quelque part et n'a pas pu remplir sa tâche de vidage de seau à temps => ce n'est pas normal, on fait donc un RESET pour relancer le système
Ici le robinet qui coule en permanence, c'est le signal 60 Hz. Il est appliqué à deux compteurs 4 bits montés en cascade : les 74161 situés en E2 et D2.
Un compteur 74161 ça a cette tête :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184742-Little_Rabbit-74161.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184742-Little_Rabbit-74161.jpg)
Les entrées A B C D servent à fixer une valeur initiale au compteur. CLK reçoit un signal carré, et à chaque front montant, le compteur va s'incrémenter d'une unité, valeur qu'on retrouve sur les sorties Qa Qb Qc Qd. La broche CLR permet elle de remettre le compteur à 0. Le comptage n'a lieu que si les 2 entrées ENT et ENP sont à 1.
Un compteur binaire 4 bits, ça compte comme ça :
0000
0001
0010
0011
0100
0101
...
1101
1110
1111
Une fois que le compteur a atteint la valeur maximale (15 ou 1111 en binaire), la broche de retenue (Carry en anglais) passe à 1 pour indiquer qu'on ne peut compter au delà.
Pour en revenir au montage qui nous intéresse, on comprend à présent que les deux compteurs sont initialisés à 15 (1111) par le RESET de l'alimentation. Les broches de Carry passent donc à 1. C'est cette retenue qui déclenche une impulsion qui va servir de RESET initial à la carte CPU, matérialisé sur le schéma par le 5).
Notons que sur un 8080 et d'autres proc Intel, le RESET est actif au niveau haut, alors que sur la majorité des autres fabricants de processeurs c'est au niveau bas (Z80, 6502, 6800, 6809, 68000, etc.).
Ce RESET initial reçu par le 8080 va provoquer le début de l'exécution du code contenu dans les EPROM à l'adresse 0000H. Et s'il veut continuer à exécuter tranquillement son code, il doit venir à intervalle régulier remettre les compteurs du watchdog à 0 (vider le seau) en accédant au CLR des compteurs via le PORT04, identifié plus haut sur mon schéma par le point 4) (port 4 qui en réalité est le port 6, c'est la conclusion à laquelle nous étions parvenus en 2013 lors du WIP de Spectro ;)). L'intervalle maximum dont dispose le CPU pour vider le seau est 16 * 16 * 1 60ème de seconde, soit 4,26 sec :)).
Après la théorie, qu'est ce que j'observe dans la pratique ?
J'ai commencé par regarder ce qui se passait sur les 2 compteurs avec l'analyseur logique.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930185056-Little_Rabbit-P1020617.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930185056-Little_Rabbit-P1020617.jpg)
J'ai constaté que la sortie de la porte NON, le 7404 en F3 était toujours à 0 !
Je l'ai dessoudé,
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930185120-Little_Rabbit-P1020619.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930185120-Little_Rabbit-P1020619.JPG)
Testé => défaillant !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930185147-Little_Rabbit-F3-7404-bad.PNG) (https://gamoovernet.pixhotel.fr/pics/20170930185147-Little_Rabbit-F3-7404-bad.PNG)
Et remplacé (en le mettant sur support).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930185212-Little_Rabbit-P1020626.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930185212-Little_Rabbit-P1020626.JPG)
Ensuite je ne me souviens pas bien :-\... Il me semble que la sortie de la même porte n'était toujours pas bonne. J'avais l'impression qu'un autre des circuits auxquels elle était reliée la tirait vers un niveau intermédiaire (ni haut ni bas).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930185457-Little_Rabbit-P1020629.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930185457-Little_Rabbit-P1020629.JPG)
Je sais que cela m'a amené à dessouder pas mal d'autres portes TTL du voisinage sur la carte fille.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930185524-Little_Rabbit-P1020631.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930185524-Little_Rabbit-P1020631.JPG)
Mais je n'arrive pas à me souvenir si j'ai trouvé un coupable, ou si je m'étais simplement fourvoyé...
Toujours est-il qu'à la mi-mai 2017, le RESET était OK, me permettant de poursuivre les recherches :).
Bon, remplir 4 pages A4 pour parler simplement d'un RESET, il va falloir que je change de méthode ! :-\
La suite sera moins didactique ! :D
Merci de m'avoir lu jusqu'au bout...
A+
(https://media.giphy.com/media/pUeXcg80cO8I8/giphy.gif)
J'ai tout lu :D
la suite !! ;)
Au top
^-
je crois que je vais craquer et me lancer dans la wip d ma SI plus tôt que prévu.....
:D :D :D
Moi j'aime bien c'est histoire de porte logique :) alors je veux bien que ça reste didactique !
J'ai déplacé ton topic au bon endroit ;)
la vache elle est splendide !! juste avec un petit coup de nettoyage ! :o
Re,
Citation de: AsPiC le Samedi 30 Septembre 2017, 22:12:34 PM
J'ai déplacé ton topic au bon endroit ;)
Merci beaucoup ! ^-
C'est vrai qu'elle est plutôt propre :-*, mais en y regardant de près, elle a quand même plein de petits pètes, éraflures, manques de peinture, etc. On dira que c'est de la patine, et je m'en satisfais dans cet état, je n'envisage pas de la repeindre :).
Petit retour en arrière car j'ai oublié de le mentionner dans les épisodes précédents :) : une des toutes premières choses que j'ai faite sur le PCB, c'est remplacer certains des condensateurs tantales gouttes qui servent au découplage près des RAM, car j'en avais au moins un ou deux en court-circuit franc ! Dès que j'allumais l'alimentation arcade, elle couinait de sa façon caractéristique qui signale un court-circuit !
Sinon, pour en revenir à nos moutons, et pour les trois qui suivent, vous savez que le circuit RESET fonctionne à présent ! :D
Pour tout PCB équipé d'un CPU, c'est un préalable incontournable, certes, mais qu'est-ce que cela m'aura apporté ?? => RIEN ! :D
J'ai beau appuyer autant de fois que je le veux sur le bouton RESET, il ne se passe absolument rien :'(.
Continuons l'observation des signaux vitaux du CPU : les signaux d'horloge, qui sont au nombre de 2 sur un 8080 : Φ1 et Φ2
Ils semblent corrects :
Φ1
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233623-Little_Rabbit-P1020634.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233623-Little_Rabbit-P1020634.JPG)
Fréquence 2 MHz, soit une période de 0,5 µs
Φ2
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233640-Little_Rabbit-P1020635.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233640-Little_Rabbit-P1020635.JPG)
Fréquence également 2 MHz, soit toujours une période de 0,5 µs
J'ai alors regardé les autres broches du 8080 à l'oscillo. Je ne vais pas vous les énumérer une à une, mais par exemple, pour les 8 broches du bus de donnée, j'avais 4 bits qui étaient toujours à 1, D5 toujours à 0, D3 et D4 à peu près vivants, et D2 à 1 avec beaucoup de parasites... Une partie du bus de contrôle (que je ne connais pas trop sur le 8080) avait des allures cheloues... En bref, cela sentait plus le sapin que la forme olympique !...
Quelques jours passent, et nous sommes à présent le 27 mai 2017.
Parmi tous les composants que j'avais acheté il y a déjà pas mal de temps, en prévision de ce WIP, je n'avais pas pris de 8080. Dommage. Mais par chance, dans mon stock de vieux PCB, j'ai un Gun Fight, PCB Bally Midway de même génération que Space Invaders, et dont la carte mère est la même que Space Invaders ^- :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233702-Little_Rabbit-P1020647.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233702-Little_Rabbit-P1020647.JPG)
Après vérification, le brochage est identique à Space Invaders : j'ai ainsi pu le brancher sur mon banc de test, et le mettre sous tension. Il est en panne, mais il y avait quand même un affichage avec des choses qui bougeaient cycliquement : on peut supposer que le CPU est bon, et par chance, il est sur support ! ^-^
Comme j'ai pu le lire sur d'autres WIP, les supports d'origine des PCB Midway, à contacts lyres, ne sont pas géniaux, et ont tendance à s'oxyder avec le temps. Il est conseillé de les remplacer par un support tulipe neuf. Allons y ! Bon, 40 broches à dessouder, ce n'est pas de la tarte, d'autant qu'il ne faut pas abîmer le circuit imprimé !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233744-Little_Rabbit-P1020649.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233744-Little_Rabbit-P1020649.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233758-Little_Rabbit-P1020650.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233758-Little_Rabbit-P1020650.JPG)
Malgré tout le soin apporté à l'opération, vous voyez que les pastilles qui ne sont reliées à aucune piste ont tendance à sauter ! :'(
Ce n'est pas dramatique car elles sont ici du côté composant : cela n'empêchera pas de souder correctement le nouveau support tulipe.
Tant que j'y suis, je remplace le support de la première EPROM, celle portant la lettre H, puisque c'est celle qui reçoit l'EPROM de test.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233821-Little_Rabbit-P1020651.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233821-Little_Rabbit-P1020651.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233839-Little_Rabbit-P1020652.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233839-Little_Rabbit-P1020652.JPG)
Voilà les deux supports soudés, respectivement 24 et 40 broches.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233902-Little_Rabbit-P1020653.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233902-Little_Rabbit-P1020653.JPG)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233919-Little_Rabbit-P1020654.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233919-Little_Rabbit-P1020654.JPG)
Mon CPU de remplacement est blanc :), je ne risque pas de le confondre avec le noir d'origine.
Mais pour poursuivre mes tests, et le faire avec la fameuse EPROM de test améliorée et debugguée par spectroman, il faut que je modifie (correctement cette fois !) les straps qui autorisent l'utilisation de plusieurs sortes de ROM/EPROM.
À l'origine, mon PCB était câblé comme ceci :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930233943-Little_Rabbit-P1020615.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930233943-Little_Rabbit-P1020615.JPG)
Et je l'ai modifié comme ceci pour utiliser des EPROM 2716 classiques (attention, pas des TMS2716) :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234011-Little_Rabbit-20170930-214730.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930234011-Little_Rabbit-20170930-214730.jpg)
Cela revient à seulement modifier S2 (dont j'ai surligné sur les 2 photos la position initiale, et la nouvelle).
Je programme ma 2716 de test (toujours avec mon vieil ATARI ST, puisque mon programmateur « moderne » sur PC ne les fait pas :))
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234040-Little_Rabbit-P1000741.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234040-Little_Rabbit-P1000741.JPG)
Nous avons donc de nouveaux supports pour le CPU et la ROM H, un CPU de remplacement et une EPROM fraîchement programmée. Tout est en place pour faire un nouveau test ! ^-^
Mise sous tension et... tadaahh !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234114-Little_Rabbit-P1020659.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234114-Little_Rabbit-P1020659.JPG)
Il y a du nouveau à l'écran ^-^ !
On discerne des lignes verticales, une sorte de chiffre 3 au milieu de l'écran, suivi d'un zigouigoui non identifié :). Et une des lignes verticales est intermittente, avec des pixels tantôt allumés, tantôt éteints :
Comme je suis parfois un peu bête (si si, mais ne dites pas toujours hein ! ;)), il ne m'est pas venu tout de suite à l'idée de chercher à savoir ce que faisait exactement la ROM de test, et si ce qu'elle affichait pouvait avoir une signification, d'autant que c'était assez peu lisible, le tout ressemblant un peu à du charabia... Je sais depuis que le chiffre affiché désigne le n° de la 1ère RAM qui a été détectée comme défectueuse (et que le zigouigoui était un bug que F4brice a depuis corrigé ^- !).
Mais à ce moment ne le sachant pas, j'ai d'abord voulu explorer la piste des lignes intermittentes : je me suis dit que cette RAM était certainement défectueuse, et si je parvenais à l'isoler je pourrais identifier le chip responsable.
En regardant le schéma de la carte mère, on constate que les RAM utilisées sont des Intel 2107 :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234203-Little_Rabbit-RAM2107.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930234203-Little_Rabbit-RAM2107.jpg)
- leur capacité est de 4 kilo bit (4096 x 1 bit)
- il y a 2 broches distinctes pour y écrire une donnée (Din en 6), ou lire une donnée (Dout en 7)
- le bit de sortie est complémenté à 1 (donc inversé, ne me demandez pas pourquoi ! ;D)
En situation, elles sont exploitées comme ça :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234235-Little_Rabbit-sortie-RAM-2107.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930234235-Little_Rabbit-sortie-RAM-2107.jpg)
On constate donc que chaque bit sortant passe au travers d'une porte NON 7404 pour supprimer l'inversion due à la sortie en complément à 1 de la 2107. J'ai pensé que c'était une opportunité pour isoler un à un les différents bits, et identifier le boîtier dont les pixels clignotaient !
J'ai donc dessoudé le 7404 concerné pour le mettre sur support, il est situé en D4 sur la carte mère :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234358-Little_Rabbit-P1020666.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234358-Little_Rabbit-P1020666.JPG)
Ensuite, je relève certaines de ses pattes, bit de RAM par bit de RAM, pour voir quelle ligne de pixel est affectée à l'écran.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234422-Little_Rabbit-20170930-223822.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930234422-Little_Rabbit-20170930-223822.jpg)
Cela m'a amené à dessouder 2 boîtiers RAM :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234438-Little_Rabbit-P1020665.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234438-Little_Rabbit-P1020665.JPG)
Petite anecdote : durant cette partie du WIP, j'avais régulièrement le PCB sous tension, regardant à l'écran les progrès (ou non) que pouvait apporter chaque modif. Quand soudainement, je sens une odeur de cramé ! :(
Je coupe immédiatement l'alimentation, et identifie très rapidement l'origine de l'odeur !...
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234457-Little_Rabbit-P1020661.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234457-Little_Rabbit-P1020661.JPG)
=> un des condensateurs tantale goutte tout neuf, dont je mentionnais le remplacement plus haut, venait de partir en fumée !
Les tantales gouttes sont polarisés, comme les électrochimiques, et je présume que je me suis gouré en le soudant ! :-\
Quoiqu'il en soit, je trouve la photo très belle ! =:))
J'ai remplacé le condo, et voilà où j'en étais à la fin mai, quand le WIP connût une nouvelle petite pause...
La suite au prochain épisode (mais ne vous attendez pas à de gros progrès... c'est plutôt l'inverse !...).
A+
Salut Little_Rabbit !
J'ai une born Gun Fight vide, sans PCB, si tu vois où je veux en venir... ;)
Et la carte avec les 2 câbles en nappe gris est intéressante : elle remplace ces merdes de driver de bus Intel impossible à trouver !
Il serait intéressant de la documenter !
Bon WIP, et évite de fumer le tantale, c'est mauvais pour le poil.
quand je pense qu'a mes debut (y'a au moins 10 ans)
j'achetais des pcb hs dans l'espoir de les reparer ^^
Good luck Little rabbit pour la suite du wip
Passionnant
je boit tes paroles et m'instruit en même temps
<:)
Salut F4brice !
Citation de: f4brice le Dimanche 01 Octobre 2017, 08:06:04 AM
J'ai une borne Gun Fight vide, sans PCB, si tu vois où je veux en venir... ;)
OK, je note ça dans un coin de ma tête pour plus tard ;).
Je viens de regarder de plus près cette petite carte : elle se substitue effectivement à 2 drivers de bus Intel, les 8216.
Le composant Intel 8216 est un quadruple driver de bus bidirectionnel non inversé :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001113438-Little_Rabbit-8216-Intel.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001113438-Little_Rabbit-8216-Intel.jpg)
À ma grande surprise, cette carte est officielle, faite par Bally Midway ! Voici des photos plus détaillées de la carte en question :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001113508-Little_Rabbit-20171001-094603.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001113508-Little_Rabbit-20171001-094603.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001113526-Little_Rabbit-20171001-094842.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001113526-Little_Rabbit-20171001-094842.jpg)
Avec l'intitulé « 8216 BI-DIRECTIONAL DRIVER SUBSTITUTION », ref 80-902.
Il s'agit simplement de deux 7417 (des sextuples drivers non inverseur à collecteur ouvert), et d'un réseau de résistance en pull-up pour les collecteurs ouverts j'imagine.
D'ailleurs sur le schéma de Space Invaders, il y a une note qui évoque l'usage de cette carte annexe :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001113359-Little_Rabbit-mention-8216-remplacy-par-80-902.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001113359-Little_Rabbit-mention-8216-remplacy-par-80-902.jpg)
Car dans ce cas, le driver n'est plus bi-directionnel mais unidirectionnel, ce qui implique quelques modifications.
J'ai rapidement googlé sur cette carte, et je n'ai effectivement absolument rien trouvé ! :o
Citation de: f4brice le Dimanche 01 Octobre 2017, 08:06:04 AM
Bon WIP, et évite de fumer le tantale, c'est mauvais pour le poil.
En effet, si je veux garder un beau poil brillant, vaut mieux éviter :D !
Citation de: olschool le Dimanche 01 Octobre 2017, 10:47:31 AM
Passionnant
je bois tes paroles et m'instruis en même temps
<:)
Merci ^-!
Si cela intéresse quelques personnes, au moins ce n'est pas du temps de perdu :).
A+
nice
encore une SI :D
bon courage pour le dépannage
mais t'es encore en vacance ? ^^
Citation de: Little_Rabbit le Dimanche 01 Octobre 2017, 11:40:49 AM
Merci ^-!
Si cela intéresse quelques personnes, au moins ce n'est pas du temps de perdu :).
A+
Bien au contraire, J'ai une
SI dans la Gaming Room depuis 5/6 mois et j'ai d'abord privilégié des WIP plus "rapide" sur lesquels je savais que je n'aurais pas de gros problème et où le cas échéant je pouvais remplacer l'écran ou le pcb par du spare en ma possession.
là c'est une vrai mine d'or, entre les WIP deF 4brice/spectro/toi et sushi et j'en oublie surement d'autre je me suis fait une "bibliothèque" de lien a consulter avant d'entreprendre quoi que ce soit
^- <:)
je sais exactement quels sont les composant a commander avant d'attaquer les capkit, comment procéder avant toute mise en route, et que tester.
Tous ces wip permettent de répondre a énormément de questions pour toute personne qui désire se lancer dans la restauration d'une SI
Et en plus la rédaction est de qualité, de véritable didacticiel pour les "profanes" comme moi en matière d'électronique :-*
^-^
Il en manquerais plus qu'a créer un sujet en
post it regroupant les wip de gamoo sur ce sujet ainsi que tous le sites de référence ;)
si personne ne s'en charge le le ferais quand j'attaquerais mon wip qui ... grâce ou a cause de toi ne devrai spas tarder :D :D :D
Y en a plus que 3 qui suivent ;)
Bon par contre, à la première lecture, les 2 trucs que je retient c'est le "zigouigoui" et la photo du condo cramé. De là à en tirer des conclusions sur la façon dont fonctionne mon cerveau... :D
Intéressant de voir que déjà à l'époque l'obsolescence de certains composants les ont obligés à "bidouiller".
La "réparabilité" d'un PCB tient principalement à la possibilité de trouver des pièces détachées.
Et toutes les cochonneries de composants propriétaires (les drivers de bus Intel en sont un bon exemple) viennent donc plomber ça.
Autre exemple : mon PCB de Rolling Thunder :
- puce "CUS39" morte, diagnostiquée en septembre 2013 (http://www.gamoover.net/Forums/index.php?topic=21931.msg457683#msg457683)
- puce "CUS39" de remplacement trouvée en septembre 2017 (http://www.gamoover.net/Forums/index.php?topic=21931.msg624979#msg624979)
Re,
Citation de: HerosSuperMan le Dimanche 01 Octobre 2017, 11:49:35 AM
mais t'es encore en vacance ? ^^
Oui :), mais là je ne wipe pas du tout, je ne fais que vous narrer les étapes précédentes de mon WIP ;). Mais c'est vrai que le week-end y sera passé ! Et puis c'est normal que je sois en vacance : j'ai bossé durant tout le mois de juillet et août moi Monsieur ;) ! Il me reste encore une semaine de vacance 8).
Nous voici donc à l'épisode suivant, qui à en juger par la date de mes photos, a dû se dérouler en juillet dernier.
Comme je l'expliquais sur le post à Sushy, au fil du temps, le PCB qu'aje_fr m'avait prêté déconnait de plus en plus : des lignes horizontales traversaient les envahisseurs, et empêchaient de faire une partie normale. Mais comme il m'arrive parfois de mettre le PCB d'aje_fr sur mon banc de dépannage pour comparer certains points, j'avais constaté qu'il fonctionnait mieux (même bien, en attract mode en tous cas) sur le banc que dans la borne !
La première différence à laquelle j'ai pensé, c'était l'alimentation. J'ai donc procédé au remplacement de tous les condo électrochimiques de l'alim (je n'avais toujours pas fait son capkit).
L'alim telle qu'elle était dans la borne :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001190600-Little_Rabbit-P1020708.JPG) (https://gamoovernet.pixhotel.fr/pics/20171001190600-Little_Rabbit-P1020708.JPG)
Petite comparaison générationnelle :)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001190622-Little_Rabbit-comparaison-condo.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001190622-Little_Rabbit-comparaison-condo.jpg)
j'adore les différences de taille ! :-*
Et le capkit mis en place :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001190644-Little_Rabbit-P1020715.JPG) (https://gamoovernet.pixhotel.fr/pics/20171001190644-Little_Rabbit-P1020715.JPG)
Pour le gros condo de 22 000 µF, mon crémier (E44) n'en avait pas avec sorties axiales, j'ai dû me rabattre sur un modèle « radial », ce qui a nécessité des petits modifs sur le PCB car l'empâtement n'est pas du tout le même :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001190719-Little_Rabbit-modif-condo-22K.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001190719-Little_Rabbit-modif-condo-22K.jpg)
(en rouge, le fil et le trou ajouté pour l'empâtement du condensateur radial)
J'ai bien serré le collier de serrage du condo de 22K car il n'a qu'une broche soudée au PCB, la seconde l'étant à un fil (et puis les gros condo comme ça, il est toujours recommandé de les attacher pour ne pas solliciter mécaniquement les soudures).
Après ça, j'ai voulu me remettre au test des RAM. Sauf qu'un PCB Space Invaders même non alimenté, ça demeure une sorte d'entité vivante, ou du moins biodégradable :-\...
Quand j'ai rallumé mon PCB, et ce dans mon petit atelier, sur son banc de dépannage avec la même alimentation arcade qu'avant, donc sans rapport avec le cap kit de la l'alim de la borne que je venais de faire, et bien j'avais une image qui défilait constamment à l'écran !
J'ai comparé avec le PCB d'aje où là l'image était stable (cela ne venait donc pas du moniteur). Bon bah un circuit a passé l'arme à gauche sans crier gare ! >:(
En cherchant un peu sur le schéma, j'ai compris que le signal de synchro composite était généré par cette partie :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001190948-Little_Rabbit-Synchro-composite.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001190948-Little_Rabbit-Synchro-composite.jpg)
On y trouve un ensemble de compteurs 4 bits synchrones (les 9316), quelques bascules D (74LS74) qui fabriquent le timing requis pour les tops de synchro horizontale et verticale. Je n'ai pas parfaitement compris le fonctionnement intime de l'ensemble, mais j'ai l'impression qu'à partir d'un signal d'horloge de fréquence assez élevée, les compteurs sont montés en cascade et jouent le rôle de diviseurs de fréquence, et qu'à l'aide des retenues (Carry) et bascule D, cela forme une sorte d'automate qui change d'état au moment voulu pour le timing des tops de retour du balayage ligne et balayage trame. Le 74LS55 en bas agglomère tout ça en une synchro composite.
J'ai commencé par dessouder ce 74LS55 situé en A6 pour le vérifier. Mais il était bon, ce n'est pas lui le coupable. Je l'ai remis sur support.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171001191100-Little_Rabbit-20171001-175230.jpg) (https://gamoovernet.pixhotel.fr/pics/20171001191100-Little_Rabbit-20171001-175230.jpg)
Pour moins travailler à l'aveugle, j'ai relevé à l'analyseur logique les signaux qui arrivaient sur le 74LS55 et le compteur 9316 situé en E7, et ce à la fois sur mon PCB et celui d'aje. J'ai bien constaté des différences, je touchais donc du doigt la source de ce nouveau petit problème. Mais ainsi va la vie, je n'ai pas pris le temps de les analyser dans le détail ! :-\
Voilà où j'en étais resté fin juillet :). À présent que je suis à jour de mes comptes-rendus de WIP, je vais pouvoir me retrousser les manches et poursuivre mes investigations pour tout d'abord restaurer la synchro composite, puis changer les RAM qui doivent l'être. Et pour ce qui est des pannes suivantes, je ne les connais pas encore ! :D
A+
Je ne comprends toujours rien à tout ça, mais je me laisse toujours autant hypnotiser à lire ^- ;D
Citation de: tikibzh le Dimanche 01 Octobre 2017, 21:28:10 PM
Je ne comprends toujours rien à tout ça, mais je me laisse toujours autant hypnotiser à lire ^- ;D
ca va je suis pas tout seul alors ;D
Citation de: tikibzh le Dimanche 01 Octobre 2017, 21:28:10 PM
Je ne comprends toujours rien à tout ça, mais je me laisse toujours autant hypnotiser à lire ^- ;D
Pareil pour moi.
Quand je serai grand je réparerai les pcb comme little rabbit
Salut,
Merci pour vos commentaires ^-. Ça fait plaisir de savoir que cela permet de faire passer quelques connaissances ou notions dans le domaine :).
Et cela vous permet aussi de vous rendre compte que lorsqu'on n'est pas du métier comme F4brice ou spectroman, ben on en chie un peu pour dépanner ces satanés PCB ! :D
Précédemment, je vous disais qu'il me fallait décortiquer la partie du circuit qui s'occupe de générer le signal de synchro composite.
Avant de vous en parler, je voudrais revenir sommairement sur le fonctionnement d'un tube cathodique, car cette synchro composite en découle directement.
Un tube cathodique est basé sur le principe d'un canon à électron qui vient frapper la face d'un tube recouvert d'une matière électroluminescente. Le faisceau d'électron part de l'arrière du tube cathodique, et vient s'écraser sur le devant du tube (l'écran) en provocant un point lumineux. Ensuite, sur le col du tube sont placées des bobines de déflection qui part le champ magnétique généré sont capable de faire en sorte que le faisceau d'électron atteigne n'importe endroit de l'écran (déflection horizontale et verticale). Une image est dessinée en balayant toute la surface de l'écran. Et c'est la persistance rétinienne qui donne l'illusion à l'œil humain d'une image pleine et entière quand en réalité il n'y a un instant donné que un point d'allumé.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003221401-Little_Rabbit-RASTSCAN.GIF) (https://gamoovernet.pixhotel.fr/pics/20171003221401-Little_Rabbit-RASTSCAN.GIF)
Ce balayage s'effectue ligne horizontale après ligne horizontale. Après la dernière ligne tracée, le faisceau qui se trouve en bas à droite revient en haut à gauche pour décrire la trame suivante.
Quand une ligne vient d'être balayée, le faisceau doit revenir à gauche pour tracer la ligne suivante, un peu plus bas. On l'indique à l'électronique de l'écran à l'aide d'un top de synchro : c'est la synchro horizontale (qui présente souvent la fréquence qui nous est si chère : 15,6 KHz :)).
De la même façon, quand la dernière ligne vient d'être tracée et qu'il faut ramener le faisceau d'électrons en haut à gauche, l'électronique de l'écran en est informée par le top de synchro verticale (dont la fréquence est cette fois de 60 ou 50 Hz, selon les territoires, mais généralement 60 Hz sur la génération de bornes dont nous parlons).
Le diagramme suivant résume ce principe (en le simplifiant puisqu'en réalité on a plus de 250 lignes de balayage ;) :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003221426-Little_Rabbit-raster.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003221426-Little_Rabbit-raster.jpg)
Si on regarde le diagramme tourné à 90°, on retrouve sur l'axe des x le chronogramme des tops de synchro horizontale et verticale, un peu comme on les verrait sur un oscilloscope :).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003221446-Little_Rabbit-raster90-.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003221446-Little_Rabbit-raster90-.jpg)
Après ce petit rappel, venons en au problème qui nous occupe aujourd'hui : mon PCB Space Invaders. En regardant l'image qui défile à l'écran, on constate que l'image est grosso modo là, les lignes semblent tracées, mais par contre nous n'avons aucune stabilité verticale. Je présume donc que la synchro horizontale est bonne, mais pas la verticale.
Voyons ce que l'on a sur mon PCB. À l'aide de l'analyseur logique, j'ai observé les signaux présents sur les broches du 74LS55.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003221529-Little_Rabbit-A6-74LS55-synchro-composite-ligne-tga.JPG) (https://gamoovernet.pixhotel.fr/pics/20171003221529-Little_Rabbit-A6-74LS55-synchro-composite-ligne-tga.JPG)
Ici on voit sur la dernière ligne, en sortie du 74LS55 broche 8, les tops de synchro horizontale. A l'aide du logiciel de l'analyseur logique, on peut mesurer le temps écoulé entre 2 endroits. Ici on a 64,12 µs, ce qui correspond bien à une fréquence de 15,6 KHz ! ^-
Si on prend un peu de recule, c'est-à-dire qu'on regarde la même mesure sur une période de temps plus large, à l'échelle du balayage d'une image complète et non plus seulement de quelques lignes, on constate :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224334-Little_Rabbit-A6-74LS55-synchro-composite-pas-de-synchro-trame-tga.JPG) (https://gamoovernet.pixhotel.fr/pics/20171003224334-Little_Rabbit-A6-74LS55-synchro-composite-pas-de-synchro-trame-tga.JPG)
que le signal sur la broche 1 ressemble à la synchro verticale, mais en mesurant la période et donc la fréquence, on trouve 68 Hz : un peu élevée !...
Comme j'ai la chance d'avoir le PCB d'aje sous la main, j'ai effectué la même mesure sur son PCB.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224400-Little_Rabbit-A6-74LS55-synchro-composite-trame-aje.JPG) (https://gamoovernet.pixhotel.fr/pics/20171003224400-Little_Rabbit-A6-74LS55-synchro-composite-trame-aje.JPG)
On retrouve sensiblement la même chose, mais cette fois la fréquence du top de synchro verticale est bien de 60 Hz. Et si on regarde l'allure de la synchro composite en bas, on voit qu'elle est cohérente : un grand top de synchro verticale, entrecoupé de plein de petits tops de synchro horizontale. Alors que sur mon chronogramme, on ne discerne que des tops de synchro horizontale.
En effet, en mesurant les durées du top de synchro verticale, on a la confirmation qu'ils ne sont pas du tous les mêmes !
- 320 µs sur mon PCB
- 2,73 ms sur celui d'aje
Mon top de synchro est presque 7 fois plus court !... Je pense avoir mis le doigt sur ce qui coince.
Détaillons d'où vient le signal qui arrive sur la broche 1 du 74LS55 :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224439-Little_Rabbit-Dy-tail-synchro-schy-ma-verticale.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003224439-Little_Rabbit-Dy-tail-synchro-schy-ma-verticale.jpg)
J'ai surligné en jaune les parties importantes : la bascule D 74LS74 telle qu'elle est câblée va changer d'état (basculer de 0 à 1 ou de 1 à 0) à chaque fois qu'un front montant sera présent sur son entrée CLK, en broche 11. Ce signal CLK provient de la retenue du compteur 9316 voisin, lui-même impacté par la série des autres compteurs 9316 qui sont en cascade au dessus de lui.
Serait-ce le 74LS74 qui dysfonctionne, ou est-ce le compteur 9316. Quand on regarde les chronogrammes plus haut, je pencherais pour le compteur, car la bascule... bascule (!), mais pas au bon moment :).
Dans ma quête, je dispose depuis quelques jours d'une nouvelle arme : un comparateur de portes logiques qu'on m'a prêté !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224521-Little_Rabbit-20171001-172738.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003224521-Little_Rabbit-20171001-172738.jpg)
Vous en avez sans doute déjà entendu parlé puisqu'aje_fr avait entrepris d'en fabriquer un de son cru, en s'inspirant de cet appareil HP (projet qui me semble malheureusement en standby pour l'instant...).
Première fois que j'utilise ce genre de truc. En théorie, on place dans l'appareil un composant valide du modèle de celui qu'on veut tester in-situ. On configure la carte pour préciser sur quelles broches se trouvent les sorties, on clipse la sonde sur le composant suspect, et une fois le PCB sous tension, les LED de l'appareil nous indiquent si il y a une différence ou pas. Si tout est éteint, c'est que le composant sur le PCB se comporte de façon identique à l'étalon placé dans l'appareil.
Mon problème de synchro est une bonne occasion de tester l'appareil :).
Premier composant testé : le 74LS74 :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224544-Little_Rabbit-20171002-155003.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003224544-Little_Rabbit-20171002-155003.jpg)
Déclaré comme bon !
Second composant à tester, le compteur 9316. Ici c'est plus compliqué, car les 9316 sont obsolètes depuis très très longtemps (j'ai vu sur des databooks du début des années 80 qu'ils étaient déjà déclarés obsolètes !...). Par conséquent je n'ai pas de 9316 dans mon stock de composants neufs. En faisant une recherche d'équivalence, il est censé être identique au 74LS161 (même brochage, mêmes fonctionnalités). J'essaye donc avec un 74LS161 :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224604-Little_Rabbit-20171002-155311.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003224604-Little_Rabbit-20171002-155311.jpg)
Différence détectée ! :)
Je dessoude le 9316 supposé mauvais, et le remplace par un 74LS161 sur support.
Au préalable, je teste le 9316 avec la fonction « Testeur TTL » de mon programmateur d'EPROM, avec 74LS161 comme référence car le testeur ne connaît pas non plus les 9316 =>
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224637-Little_Rabbit-E7-9316-test-OK.JPG) (https://gamoovernet.pixhotel.fr/pics/20171003224637-Little_Rabbit-E7-9316-test-OK.JPG)
le composant est donné comme bon ! Hum... curieux ! :-\
Résultat une fois le 74LS161 sur son support sur le PCB :'(
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224728-Little_Rabbit-20171002-171921.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003224728-Little_Rabbit-20171002-171921.jpg)
Certes cela ne défile plus comme avant, mais l'image n'est pas du tout celle escomptée. Mouais... y a-t-il une autre panne en amont, ou le 9316 n'est-il finalement pas tout à fait substituable par un 74LS161 ? Le seul moyen dont je dispose pour le savoir consiste à dessouder un 9316 supposé bon de mon PCB Gun Fight (désolé F4brice... :-\).
Nouveau test :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171003224806-Little_Rabbit-20171002-171811.jpg) (https://gamoovernet.pixhotel.fr/pics/20171003224806-Little_Rabbit-20171002-171811.jpg)
Ça marche !!! ^-^
On peut donc en conclure que 74LS161 et 9316 ne sont pas substituables !...
Voilà, la synchro composite est réparée. Je vais pouvoir poursuivre le test des RAM. ^-
A+
Et selon toi..... Là t'en chie ??? ::)
En tous cas merci pour ces informations, je bois ces informations, alimente ma curiosité....bref j'adore.
Vivement la suite !!! :-*
Re,
Citation de: sushy18 le Mardi 03 Octobre 2017, 23:37:21 PM
Et selon toi..... Là t'en chie ??? ::)
Bah... heu... comment dire... J'en chie un peu plus que certains qui achètent des PCB "untested" qui fonctionnent parfaitement ou presque dès le 1er branchement... :-\
:D
A+
Non mais comment que ça casse là :D
Ca wip sévère en ce moment ^-
Salut,
Pas beaucoup d'avancées, et pas grand chose à dire !...
J'ai commencé à m'occuper du remplacement des RAMs.
Avec la ROM de test, l'écran affichait ce qui ressemblait à un 3.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234114-Little_Rabbit-P1020659.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234114-Little_Rabbit-P1020659.JPG)
J'ai donc remplacé la RAM de l'emplacement 3.
Pour rappel, les emplacements sont énumérés de la façon suivante :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171004202028-Little_Rabbit-numy-ration-RAM.png) (https://gamoovernet.pixhotel.fr/pics/20171004202028-Little_Rabbit-numy-ration-RAM.png)
Nouveau test :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171004202502-Little_Rabbit-20171002-183928.jpg) (https://gamoovernet.pixhotel.fr/pics/20171004202502-Little_Rabbit-20171002-183928.jpg)
l'écran affiche ce qui ressemblerait à un 7. À vrai dire, je pense qu'il manque des lignes de pixels, ce qui ne facilite pas la lecture du chiffre ou de la lettre correspondant à la RAM incriminée...
Je dessoude donc la RAM située en 7. Une remarque en passant : un peu plus haut je racontais des salades ! Je disais que côté composant, en dessoudant les CI, cela faisait sauter les pastilles qui ne sont reliées à aucune piste. En fait non, pour la bonne et simple raison que côté composant il n'y a pas de pastille aux endroits où il n'y a pas de piste ! :D
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171004202150-Little_Rabbit-20171004-135000.jpg) (https://gamoovernet.pixhotel.fr/pics/20171004202150-Little_Rabbit-20171004-135000.jpg)
Rebelotte : à présent l'écran affiche ça :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171004202222-Little_Rabbit-20171004-170845.jpg) (https://gamoovernet.pixhotel.fr/pics/20171004202222-Little_Rabbit-20171004-170845.jpg)
C'est quel chiffre ou lettre à votre avis ? :-\ Un 4 ?
Mon champ de ruine RAM à cette tête pour l'instant.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171004202258-Little_Rabbit-20171004-173203.jpg) (https://gamoovernet.pixhotel.fr/pics/20171004202258-Little_Rabbit-20171004-173203.jpg)
Mon problème, c'est que je n'ai plus de RAM TMS4060 sous la main. Je pourrais bien dépeupler mon PCB de Gun Fight, mais c'est tellement fastidieux que je préfère en commander en Allemagne sur Ebay. Et j'ai également commandé en Grèce des 9316 (le compteur synchrone remplacé hier), ainsi qu'un pistolet à dessouder, mais en rupture de stock, cette fois-ci en Italie. Vive l'Europe :) !
Du coup de vais mettre en standby mon WIP le temps que tout ça arrive ! ^-
A+
Citation de: Little_Rabbit le Dimanche 01 Octobre 2017, 00:00:18 AM
Sinon, pour en revenir à nos moutons, et pour les trois qui suivent, vous savez que le circuit RESET fonctionne à présent ! :D
Elle est plus facile a suivre quand on dit :"revenons à nos chips" ;D
Je voulais modifier le test des Rams pour qu'il indique en une fois toutes RAM en erreur c'est sur ma TODO list pour la retraite ;)
J'ai regardé le code assembleur pour ça, mais le 8080 manque de registres.
P'tet en copiant la data d'origine dans le registre de stack ?
A voir en effet !
Salut,
Citation de: spectroman le Jeudi 05 Octobre 2017, 08:40:33 AM
Elle est plus facile a suivre quand on dit :"revenons à nos chips" ;D
Alors sur le coup je n'ai pas compris... :-\
Je me suis dit, mais pourquoi diable sprectro me parle-t-il de chips ?? Croit-il qu'il a la classe ?...
:D
Puis j'ai cherché, et j'ai compris !...
Sans doute qu'en anglais méditerranéen, "chips" se prononce comme "sheeps" !... :D
sheeps = moutons,
chips = puces électroniques !
Oui, comprendre l'humour de spectroman peut parfois être un... challenge ! Et pour le coup, c'est un Chip's Challenge
Ok, je :fleche:
Citation de: spectroman le Jeudi 05 Octobre 2017, 08:40:33 AM
Je voulais modifier le test des Rams pour qu'il indique en une fois toutes RAM en erreur c'est sur ma TODO list pour la retraite ;)
Ah ça serait cool ça ! :)
Je me disais que c'est con qu'on ne puisse pas faire comme sur les cartes de flip CPU Bally : faire flasher une LED x fois pour indiquer quelles sont les RAM en erreur ! Comme ça, même si la majorité des RAM sont mortes au point qu'on n'arrive pas à lire ce qu'il y a à l'écran, on saurait lesquelles changer :).
A+
Citation de: Little_Rabbit le Jeudi 05 Octobre 2017, 21:48:07 PM
Je me disais que c'est con qu'on ne puisse pas faire comme sur les cartes de flip CPU Bally : faire flasher une LED x fois pour indiquer quelles sont les RAM en erreur ! Comme ça, même si la majorité des RAM sont mortes au point qu'on n'arrive pas à lire ce qu'il y a à l'écran, on saurait lesquelles changer :).
Tu nous trouves une LED sur le PCB de Space Invaders, et Spectro ou moi te la faisons clignoter ! ;)
Ah ben pour le coup, moi j'avais compris tout de suite pour les moutons.
Moi je dis "chips" à la méditerranéenne alors :D
Faut dire aussi que c'est le prénom de mon chien :D
Citation de: spectroman le Jeudi 05 Octobre 2017, 08:40:33 AM
Je voulais modifier le test des Rams pour qu'il indique en une fois toutes RAM en erreur c'est sur ma TODO list pour la retraite ;)
Citation de: Little_Rabbit le Jeudi 05 Octobre 2017, 21:48:07 PM
Ah ça serait cool ça ! :)
C'est fait :D (8h de boulot étalées sur 3 soirées), alors ca dit quoi ton test ;)
Citation de: spectroman le Samedi 14 Octobre 2017, 16:03:32 PM
C'est fait :D (8h de boulot étalées sur 3 soirées), alors ca dis quoi ton test ;)
^-^
vous voulez vraiment que je wipe ma S
pace I
nvader !!! c'est une coalition
:D :D
Salut,
Citation de: spectroman le Samedi 14 Octobre 2017, 16:03:32 PM
C'est fait :D (8h de boulot étalées sur 3 soirées), alors ca dit quoi ton test ;)
Merci encore pour ce développement et pour les bénéfices qu'apporte cette nouvelle version ! :-)=
Comme vous l'avez compris, j'ai pu tester en avant première la dernière version de la ROM de test que Spectro a développée ^-^.
Mise en place de la nouvelle EPROM sur mon PCB, et voici le résultat :
Le test s'effectue correctement, mais à peine le résultat est-il affiché à l'écran que le PCB reboote, pour afficher à nouveau le test, puis rebooter, etc., à l'infini.
En faisant une pause sur la vidéo, on peut toutefois voir ce que le test affiche :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015185859-Little_Rabbit-Test-RAM-1.2.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015185859-Little_Rabbit-Test-RAM-1.2.jpg)
Y a du boulot en perspective ! :-\
Spectro qui attendait le résultat du test de sa dernière version sur un vrai PCB (et non plus sous MAME) me confirme mon avis : le watchdog ne fonctionne pas correctement !
Pour rappel, le watchdog (chien de garde en anglais) est un mécanisme qui RESET le PCB si le programme en cours d'exécution n'est pas venu le « calmer » à intervalle régulier. En l'occurrence, sur Space Invaders, si le watchdog n'est pas remis à 0 dans les 4 secondes, il génère un RESET. Or, le programme de test de Spectro purge régulièrement le watchdog, cela ne devrait donc pas faire de RESET ! Juste pour vérifier, j'ai remis l'ancienne version de l'EPROM de test, et elle aussi faisant un RESET toutes les 4 secondes.
Quelle est la cause de cette nouvelle panne que je n'avais pas encore identifiée ?
Observons le schéma du watchdog (qui se trouve sur la carte fille) :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190011-Little_Rabbit-Circuit-RESET.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190011-Little_Rabbit-Circuit-RESET.jpg)
J'en ai déjà parlé plus dans un post précédent : les deux compteurs 74161 en cascade comptent les impulsions 60 Hz. Si les compteurs ne sont pas remis à 0 via leur broche 1, le débordement du compteur en broche 15 génère le RESET. C'est en écrivant sur le port 6 que le « clear » devrait se faire, mais ici ne se fait pas. J'ai observé le signal à l'oscillo sur la broche 1 des 74161 : ça ne bouge pas.
Voyons le reste du schéma et remontons la piste :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190050-Little_Rabbit-Output-Ports.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190050-Little_Rabbit-Output-Ports.jpg)
C'est le port 6 qui « clear » le watchdog, partie surlignée en jaune sur le schéma. Ce composant, le 7442 situé en E3, est un décodeur BCD (BCD = Binaire Codé Décimal, c'est à dire du binaire ou 4 bits ne permettent que de compter de 0 à 9) :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190138-Little_Rabbit-7442.gif) (https://gamoovernet.pixhotel.fr/pics/20171015190138-Little_Rabbit-7442.gif)
à partir de la combinaison binaire présente sur ses 4 entrées (A, B C, D), il active la sortie correspondante en sortie (active au niveau bas). Exemple : si les 4 bits en entrées sont 0010, c'est la sortie 2 qui passe au niveau bas, toutes les autres sont au niveau haut. Si les 4 bits en entrées sont 0101, c'est la sortie 5 qui est active, etc.
Dans le cas de l'utilisation qui en est faite ici, on voit que seuls les sorties des broches 3, 4, 5, 6 et 7 sont utilisées. J'ai observé à l'analyseur logique les signaux en entrée et en sortie :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190252-Little_Rabbit-20171014-171955.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190252-Little_Rabbit-20171014-171955.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190322-Little_Rabbit-E3-7442-dy-codage-PORTS.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190322-Little_Rabbit-E3-7442-dy-codage-PORTS.jpg)
On constate que l'entrée D est en permanence à l'état haut, ce qui a pour conséquence de n'activer que les sorties supérieures ou égales à 8 ! Mon port 6 n'est pas près de s'activer...
L'entrée D (broche 12) est celle connectée au 7404 situé en F3. Son entrée quant à lui est toujours à 0 : logique que sa sortie reste à 1.
On continue à remonter la piste et on voit que le signal en entrée sur le 7404 est intitulé « SAMPLE » et provient de la carte mère, via la broche 31 du connecteur carte mère / carte fille.
Localisons sur le schéma de la carte mère ce signal « SAMPLE » :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190403-Little_Rabbit-Sample-signal.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190403-Little_Rabbit-Sample-signal.jpg)
Il est généré par le 74LS86 situé en A4 : il s'agit d'un OU Exclusif. La table de vérité d'un OU exclusif est la suivante : sa sortie est à 1 si l'une ou l'autre de ses entrées est 1, mais pas les deux, et à 0 également si les deux entrées sont à 0. Observons le à l'analyseur logique :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190434-Little_Rabbit-A4-7486-Sample.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190434-Little_Rabbit-A4-7486-Sample.jpg)
Ses deux entrées sont constamment à 1, donc il est normal que sa sortie soit constamment à 0. Nous continuons donc à remonter la piste :).
Juste avant, nous avons notamment la porte NAND du 74LS00 situé en BX. Une porte NAND passe sa sortie à 0 si ses deux entrées sont à 1, sinon elle doit être à 0. À son tour d'être observé :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190512-Little_Rabbit-20171014-175512.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190512-Little_Rabbit-20171014-175512.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015192149-Little_Rabbit-BX-74LS00.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015192149-Little_Rabbit-BX-74LS00.jpg)
Ah, là ça cloche ! On voit sur ce chronogramme que la sortie (br 6) reste constamment à 1, même quand les 2 entrées sont à 1 ! Composant suspect que je dessoude et teste :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190542-Little_Rabbit-BX-74LS00-bad.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190542-Little_Rabbit-BX-74LS00-bad.jpg)
Bingo ! Ce composant est bien défectueux. Je le remplace, remets sous tension, et à présent c'est bon, le watchdog est bien remis à 0 et cesse de reseter à tout va le PCB, le clear qu'effectue le programme de test se suit d'effet ^-.
Je peux à présent facilement voir le résultat du test :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190645-Little_Rabbit-20171014-182341.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190645-Little_Rabbit-20171014-182341.jpg)
Et ce n'est pas joli joli, puisqu'il annonce pas moins de 9 RAM défectueuses ! :'(
Mais j'ai été prévoyant, j'ai acheté un bon petit stock de RAM :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015122615-Little_Rabbit-20171014-115330.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015122615-Little_Rabbit-20171014-115330.jpg)
(8 d'entre elles sont pour F4brice qui wip aussi un PCB de SI en ce moment ;))
Notez qu'il faut normalement des TMS4060, mais en cherchant sur Ebay, je suis tombé sur ces AM9060CPC de chez AMD, qui sont en fait compatibles avec les TMS4060 (et bien moins chères : ici 5 EUR les 8 !).
Pour en revenir à mon dépannage, ce qui me surprend c'est que les RAM 2 et 3 par exemple ont déjà été remplacées !
Comme je suis à présent équipé d'un pistolet à dessouder, j'ai pu dessouder plusieurs des RAM indiquées défectueuses.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190851-Little_Rabbit-20171015-183903.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190851-Little_Rabbit-20171015-183903.jpg)
Je les remplaçais par une RAM neuve, mais souvent la même RAM était toujours indiquée comme mauvaise. À l'emplacement H par exemple, j'ai dû essayer 7 RAM différentes avant d'en trouver une donnée comme bonne ! Il serait curieux qu'autant de RAM neuves soient défectueuses.
Autre chose curieuse, le test me fournit des résultats assez aléatoires :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190721-Little_Rabbit-20171015-183757.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190721-Little_Rabbit-20171015-183757.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171015190736-Little_Rabbit-20171015-184122.jpg) (https://gamoovernet.pixhotel.fr/pics/20171015190736-Little_Rabbit-20171015-184122.jpg)
Pour avoir tant de RAM en erreur, j'ai d'abord pensé aux 7404 qui sont placés au cul des RAM (qui inversent le bit de sortie), mais mon 7404 situé en D4 était déjà sur support. J'ai pu le testé au testeur de TTL et il est bon. Je l'ai même remplacé par un neuf par acquis de conscience mais cela n'a rien changé. J'ai également vérifié les alimentations au niveau des RAM : j'ai bien le +5V, +12V et -5V.
J'en suis là. Le grand nombre de RAM en défaut et le caractère aléatoire du test me pousse à penser qu'il y a un autre problème. Les premiers suspects sont les condensateurs tantale goutte utilisés en découplage à proximité de l'alimentation des RAM (une sur 2). Sushy, grand spécialiste en dépannage de Space Invaders, a même eu la gentillesse de m'appeler pour me demander si je l'es avais remplacés ! <:) Auparavant j'avais changé les 2 plus gros condo tantale de 22 µF, mais pas les petits de 1 µF. Parce que je pensais qu'un condo tantale qui n'était pas en court-circuit était encore bon, je les avais laissés. Je vais les changer et j'espère que les résultats seront meilleurs !
À suivre :).
A+
le chien de garde en image :mrgreen:
(https://gamoovernet.pixhotel.fr/pics/20171015204709-sushy18-AccurateValuableBobolink.gif)
Re,
Excellent ton GIF Sushy ! ^-
Où as-tu trouvé ça ? :)
Il y a juste une petite erreur dessus : ce n'ai pas le port 4 mais 6 qui "clear" le watchdog ! ;)
(erreur qui provient des schémas Midway où ils ont mis "PORT 4" à 2 endroits...)
A+
Citation de: Little_Rabbit le Dimanche 15 Octobre 2017, 19:25:26 PM
Je les remplaçais par une RAM neuve, mais souvent la même RAM était toujours indiquée comme mauvaise. À l'emplacement H par exemple, j'ai dû essayer 7 RAM différentes avant d'en trouver une donnée comme bonne ! Il serait curieux qu'autant de RAM neuves soient défectueuses.
Au vu des points de couleur jaune sur tes RAMs elles ne sont certainement pas neuve ;)
Re,
Ah bon ? Quelle est la signification de ces points jaunes ?
Visuellement en tous cas, on voit bien qu'elles n'ont jamais été soudées, et la courbure des broches est identique à celle de composants neufs (je suis obligé de les plier légèrement avant de pouvoir les faire rentrer dans les supports tulipes :)).
Merci pour tes explications ! ^-
A+
Gamoo va devenir une usine à reparer les SI !
Bravo à tous les acteurs et bon courage surtout ! Vous preservez le patrimoine, respect... <:)
Citation de: Little_Rabbit le Dimanche 15 Octobre 2017, 22:27:00 PM
Ah bon ? Quelle est la signification de ces points jaunes ?
c'est de l'acné?
Citation de: Little_Rabbit le Dimanche 15 Octobre 2017, 22:27:00 PM
Ah bon ? Quelle est la signification de ces points jaunes ?
Probablement une indication que ces RAMs ont été testées avant d'être utilisé dans leurs vies antérieures.
Citation de: Little_Rabbit le Dimanche 15 Octobre 2017, 22:27:00 PM
Visuellement en tous cas, on voit bien qu'elles n'ont jamais été soudées, et la courbure des broches est identique à celle de composants neufs (je suis obligé de les plier légèrement avant de pouvoir les faire rentrer dans les supports tulipes :)).
Fais moi une photo proche de l'aspect des pattes mais si elles ressemblent à celles du composant de gauche, il est clair qu'il ne sont pas neuf :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016110103-AsPiC-Sans-titre.png) (https://gamoovernet.pixhotel.fr/pics/20171016110103-AsPiC-Sans-titre.png)
Salut,
Je me suis à nouveau penché sur mon satané PCB, toujours à me demander pourquoi autant de RAM sont détectées comme défectueuses, quand bien même j'en remplace certaines par des présumées neuves.
Hier, j'évoquais le fait que je n'avais pas changé tous les condensateurs de découplage autour des RAM, notamment les tantales gouttes dont on sait qu'ils ne vieillissent pas toujours bien.
Ce matin j'ai donc été acheté des condensateurs. J'en ai profité pour prendre quelques supports 22 broches supplémentaires pour les RAM (car initialement, je n'avais pas imaginé que j'allais en avoir besoin d'autant !...). Sauf que ces supports ne doivent plus être très utilisés, mon vendeur n'en avait plus que 3 en stock alors que j'en voulais 8 (ces supports DIP de 22 broches on un empâtement de 4 pas au lieu des 3 pas habituels...). J'ai pris les 3 restants, c'est mieux que rien :).
Un fois rentré à la maison, je m'aperçois que les condensateurs tantales gouttes que j'avais demandés sont en fait des condensateurs céramiques :(. Bon, ils sont bien d'1 µF, je ne pense pas que cela ait une incidence. D'ailleurs si quelqu'un sait m'expliquer pourquoi Midway a utilisé des condensateurs tantales pour le découplage, je suis preneur ! ^- Peut-être pour une simple raison d'encombrement... mais pour autant la densité du PCB n'est pas énorme...
En plus des tantales, je voulais remplacer certains des condensateurs céramiques. Ils sont très certainement encore bons mais ils sont hauts, et à chaque fois que je travaille sur le PCB retourné pour faire des soudures, ils tendent à se plier... J'ai mis à la place des polyesters, et par endroit des plastiques que j'avais déjà.
Histoire de voir si mon opération était un peu justifiée, j'ai mesuré la valeur de certains des condensateurs dessoudés :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211550-Little_Rabbit-20171016-122631.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211550-Little_Rabbit-20171016-122631.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211611-Little_Rabbit-20171016-122714.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211611-Little_Rabbit-20171016-122714.jpg)
Les mesures sont tout à fait normales (pour respectivement 1µF et 100 nF)... Pas encourageant pour l'issue de la manip.
Voilà l'ensemble des condensateurs dessoudés :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211651-Little_Rabbit-20171016-125203.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211651-Little_Rabbit-20171016-125203.jpg)
(remarquez en haut à gauche qu'un des condos céramiques avait une patte cassée, à force d'être plié...)
Et le PCB avec ses nouveaux condensateurs :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211716-Little_Rabbit-20171016-145536.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211716-Little_Rabbit-20171016-145536.jpg)
Je remets sous tension, et...
Aucun changement ! :'(
D'une mise sous tension à l'autre, j'ai toujours des résultats variables :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211736-Little_Rabbit-20171016-130330.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211736-Little_Rabbit-20171016-130330.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211754-Little_Rabbit-20171016-130404.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211754-Little_Rabbit-20171016-130404.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211813-Little_Rabbit-20171016-130500.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211813-Little_Rabbit-20171016-130500.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211830-Little_Rabbit-20171016-130535.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211830-Little_Rabbit-20171016-130535.jpg)
Mais toutefois, celles qui restent toujours en défaut sont les RAM 2, 4, 6 et D. Et peut-être y a-t-il un peu moins d'aléatoire, avec souvent ces mêmes RAM 2, 4, 6 et D données comme défaillantes.
Comme je commence à avoir des doutes sur mes tests, et que je me demande si se sont vraiment les RAM qui sont défectueuses, ou si des composants annexes ne seraient pas la cause des défaillances, je teste une permutation sur les RAM 2 et H.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016211716-Little_Rabbit-20171016-145536.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016211716-Little_Rabbit-20171016-145536.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016212227-Little_Rabbit-20171016-145753.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016212227-Little_Rabbit-20171016-145753.jpg)
Avant la RAM H était vue comme bonne, et la 2 mauvaise. Après cette permutation, que dit le test ?
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016212301-Little_Rabbit-20171016-145842.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016212301-Little_Rabbit-20171016-145842.jpg)
Bah ça reste cohérent ! Satanées RAM ! :-((
Je supprime ma permutation et poursuis les tests. La RAM 2 est déjà sur support avec une RAM neuve: je teste plusieurs autres RAM neuves et parvient à en trouver une qui passe comme bonne.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016212616-Little_Rabbit-20171016-150721.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016212616-Little_Rabbit-20171016-150721.jpg)
Ne reste plus que 4, 6 et D. Je dessoude ces 3 RAM, mets en place des supports et m'efforce de trouver encore 3 RAM qui passeraient pour bonnes ! C'est bon pour la D, puis pour la 4, ne reste plus que la 6 ! J'en suis à l'avant dernière RAM sur les 24 achetées !... Suspens... J'allume une énième fois, et...
Tadahh !!!
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016212637-Little_Rabbit-20171016-161556.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016212637-Little_Rabbit-20171016-161556.jpg)
Le test se poursuit !! Les CRC sont calculés (je n'ai que l'EPROM H en place), et les tests de sons sont exécutés ! Comme je n'ai pas encore branché de haut-parleur, je n'en sais pas plus.
J'éteins, puis rallume aussi sec :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016212659-Little_Rabbit-20171016-161707.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016212659-Little_Rabbit-20171016-161707.jpg)
Les 8 RAM des adresses paires sont vues comme défaillantes ! ;D
Il persiste un problème qui fait que des RAM pourtant bonnes sont parfois détectées comme mauvaises... En examinant le schéma, je vois qu'il y a des drivers de bus Intel pour le bus de donnée, et le bus d'adresse. Il va falloir que je me penche sur ces composants je pense... Peut être un problème de sortance (https://fr.wikipedia.org/wiki/Sortance) ? À moins que cela ne soit le temps de réponse des RAM qui soit limite ? Il faut que je détaille les datasheets de cette gamme et vois si elles existent en différentes vitesses...
Mais pour l'heure, vu que le test passe en gros trois fois sur quatre, je me lance à remplacer l'EPROM de test par les EPROM du jeu. Et ça marche ! :-)=
(tiens, je me rends compte que Youtube à mis ma vidéo en mirroir !... :-\)
Ou du moins ça boote, l'attract mode s'exécute normalement, mais fait apparaître de très nombreux problèmes sur les shifters.
Ce sera la prochaine étape de ce WIP ! ^-^
A+
Re,
Citation de: AsPiC le Lundi 16 Octobre 2017, 11:01:08 AM
Probablement une indication que ces RAMs ont été testées avant d'être utilisé dans leurs vies antérieures.
Fais moi une photo proche de l'aspect des pattes mais si elles ressemblent à celles du composant de gauche, il est clair qu'il ne sont pas neuf :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016110103-AsPiC-Sans-titre.png) (https://gamoovernet.pixhotel.fr/pics/20171016110103-AsPiC-Sans-titre.png)
Merci pour ces explications ! ^-
Oui, mes RAM ont leur pattes étamées comme sur ta photo de gauche.
Ne connaissant pas l'industrie électronique, comment des composants peuvent-ils être utilisés, puis remis dans le circuit sans qu'ils présentent des marques d'usure ? Notamment la courbure des pattes est identique à des composants neufs. Ils sont dessoudés d'un PCB puis nettoyés et ré-étamés ?
Et j'imagine que ne sont remis dans le circuit que les composants testés comme bons non ? :D
A+
Citation de: Little_Rabbit le Lundi 16 Octobre 2017, 21:54:22 PM
Oui, mes RAM ont leur pattes étamées comme sur ta photo de gauche.
C'était quasiment sûr vu ta source d'approvisionnement et le Date Code de celle-ci (7924 = 24ième semaine de 1979).
Tes composants ne sont donc pas neuf et probablement issu de cette filière : http://www.smta.org/chapters/files/Uppermidwest_VendorExpo_SMTAI-Upper-Midwest-Presentation-06-09-11.pdf
Et une petite vidéo particulièrement intéressante à partir de 0:55
courage !
Citation de: Little_Rabbit le Lundi 16 Octobre 2017, 21:44:53 PM
Ou du moins ça boote, l'attract mode s'exécute normalement, mais fait apparaître de très nombreux problèmes sur les shifters.
Ce sera la prochaine étape de ce WIP ! ^-^
vas-y, fais pas ta farouche, donne moi ta matrice d'erreur, il faut que je termine ma doc :D
j'ai fait un appel pour avoir des matrices : https://forums.arcade-museum.com/showthread.php?t=414433
Re,
Intéressant tes docs AsPiC !
Ça m'amène la réflexion suivante : moi qui suis pro recyclage, démarche écologique, tout ça, je trouve ça très bien qu'il y ait des filières de recyclage ! Quand tu penses aux tonnes annuelles de déchets électroniques, aux renouvellement de smartphone tous les 6 mois, à l'obsolescence programmée, c'est juste aberrant. Ce qui est naze c'est qu'il ne s'agit pas ici de véritable recyclage mais d'arnaque pour faire passer comme neuf des composants qui ne le sont pas. Mais des composants sont-ils réellement recyclables si c'est dessoudé suivant les règles de l'art, et non au barbecue comme dans la vidéo ? Ce qui est malheureux dans tout ça, c'est qu'il n'y ait pas des filières officielles de vente de composants recyclés/testés (à moins que cela existe ?). La main d'œuvre Européenne est trop chère pour que cela soit viable, et les Chinois le font n'importe comment ! ::) une fois que toutes les ressources de la planète seront épuisées, il sera bien temps de monter de vraies filières de recyclage... >:(
Citation de: AsPiC le Lundi 16 Octobre 2017, 22:09:01 PM
C'était quasiment sûr vu ta source d'approvisionnement et le Date Code de celle-ci (7924 = 24ième semaine de 1979).
Tes composants ne sont donc pas neuf et probablement issu de cette filière :
C'est possible, je n'en sais rien. Mais où je ne suis pas totalement ton raisonnement, c'est que ce genre de RAM n'est plus fabriqué depuis des décennies. La production a due s'arrêter au tout début des années 80 non ? Et je ne suis pas sûr que les Chinois il y a 40 ans s'amusaient déjà à ce genre de pratique :). Et mes composants ne prétendent pas être récents : ils sont de 79, je l'avais bien vu, ce qui me paraît logique pour des composants dont la production a été arrêtées il y a plus de 30 ans. Ils ne sont pas contrefaits au sens où ton pdf en parle (tricher sur la date et l'origine).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016225856-Little_Rabbit-20171016-225053.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016225856-Little_Rabbit-20171016-225053.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016225925-Little_Rabbit-20171016-225158.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016225925-Little_Rabbit-20171016-225158.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171016225946-Little_Rabbit-20171016-225215.jpg) (https://gamoovernet.pixhotel.fr/pics/20171016225946-Little_Rabbit-20171016-225215.jpg)
Verdict du spécialiste ? :)
Mais si tu as une source d'approvisionnement fiable pour des RAM TMS4060/AM9060/Intel 2107, je suis preneur ! :D
Et je ne les ai pas achetées en Chine mais en Allemagne, où le vendeur les prétend NOS :
http://www.ebay.fr/itm/8x-AM9060CPC-4kbit-DRAM-TMS4060-AMD-/311945825851?hash=item48a16b8e3b:g:GwIAAOSwTuVZn0j0
Bon, je ne suis pas naïf, je sais que n'importe quel chinois peut se cacher derrière un compte Ebay Européen... ;)
Je te filerai une RAM pour analyse et inspection ! :D
Citation de: spectroman le Lundi 16 Octobre 2017, 22:59:08 PM
vas-y, fais pas ta farouche, donne moi ta matrice d'erreur, il faut que je termine ma doc :D
Bah si tu relevais ta boîte mail Spectro, je pense que tu devrais être satisfait ;).
A+
Effectivement il y a un marché du "recyclage" maitrisé des composants, c'est d'ailleurs une prestation que j'ai déjà réalisé plusieurs fois.
En ce qui concerne tes composants je n'ai pas d'avis aussi tranché que toi sur le faite qu'ils soit originaux notamment sur l'aspect de la face Top du composant qui me semble présenter des traces de ponçage.
Tu devrais demander à ton vendeur pourquoi ses composants présentent des points jaune, juste par curiosité.
Tu n'as pas de quoi tester les RAMs hors du PCB ?
Je veux bien une de tes RAMs par curiosité ;)
enfin ton minutieux travail apporte des avancées visibles ^-^ good job
(au dela de la technicité et des connaissances deployés, je trouve assez ironique le fait de devoir se battre pour RE-venir au stade précédent du pcb en panne... :D )
pour la RAM
Maintenant, si on est sensé tester les composants vendus pour neuf... j'avoue que ça fausse un peu le taf...
du coup existe il un moyen de s'assurer a l'achat de ne pas avoir du refurbished ?? surtout que dans ton cas ils sont donnés pour NOS "inutilisés" ::)
Citation de: spectroman le Lundi 16 Octobre 2017, 22:59:08 PM
vas-y, fais pas ta farouche, donne moi ta matrice d'erreur, il faut que je termine ma doc :D
j'ai fait un appel pour avoir des matrices : https://forums.arcade-museum.com/showthread.php?t=414433
<:) bravo et merci pour ton travail juste indispensable au dépannage de ces bestioles
j'ai 1 question/suggestion
- tu as posté sur ton topic une photo de la page de la lecture des Rams HS, celle ci a des lignes verticales qui viennent gêner la lecture ( comme par exemple le 6 qui avec la ligne peux etre lu comme un 5 ou le 9 comme un 8...) et sur les photos récentes de littlerabbit on ne les vois plus, mais on on voit par exemple le 4, le 6 et le 8 tronqués comme si une ligne de pixels manquants les traversait ( lié au capkit aux alentours des rams ? ) ces lignes sont volontaires? si oui peut on les désactiver pour aider a la lecture ?
je te fais suivre par MP mon tableau ( sans annotations )des shifters qui designait le 74153 en B3
( d'ailleurs je suis toujours sur le cul :o sur ton "snipage"... il me manque encore beaucoup de visionage de films de boole ::) )
moi je prends mes chips chez http://www.arcadechips.com/
j'ai rarement des problèmes (1 pokey HS et 2 ou 3 rams HS) sur l'ensemble de mes commandes.
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.
Sur ce je pars déjeuner et je te laisse trouver ;)
Citation de: spectroman le Mardi 17 Octobre 2017, 13:14:14 PM
et le programme affiche le XOR entre cette dernière et celle retournée par les registres à décalage.
Merde
si
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171017135326-olschool-esta-Atua-do-spectroman-spectreman-statue-19015-01.jpg) (https://gamoovernet.pixhotel.fr/pics/20171017135326-olschool-esta-Atua-do-spectroman-spectreman-statue-19015-01.jpg)
se fait aider par
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171017135343-olschool-hqdefault.jpg) (https://gamoovernet.pixhotel.fr/pics/20171017135343-olschool-hqdefault.jpg)
XORil va pas en rester grand chose de ton pcb
:D :D :fleche:
Salut,
J'ai commencé à étudier le schéma du shifter, et la matrice magique de Spectro :).
En préambule, et pour que vous compreniez un minimum de quoi je parle, voici comment on peut représenter un nombre sur 8 bits :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171017221923-Little_Rabbit-8-bit-Register.jpg) (https://gamoovernet.pixhotel.fr/pics/20171017221923-Little_Rabbit-8-bit-Register.jpg)
chaque cellule peut contenir un 0 ou un 1, ce qui permet de contenir un nombre entier compris entre 0 et 255 en décimal, ou encore entre 00 et FF en hexadécimal, ou encore 00000000 et 11111111 en binaire :).
Je ne vous livre pas cette fois le détail de mon analyse (car je n'ai pas encore pris le temps de la rédiger), mais comme Spectro est chaud bouillant pour connaître mes premières conclusions, je dirais que je vais commencer par regarder ce que fabrique les 74174 placés en C5 et D5 : ce sont les latches qui verrouillent la valeur 8 bits qui va être shiftée.
Voici la matrice que j'obtiens quand j'exécute la ROM de test :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171017222248-Little_Rabbit-20171016-161635.jpg) (https://gamoovernet.pixhotel.fr/pics/20171017222248-Little_Rabbit-20171016-161635.jpg)
Que remarque-t-on ?
Sur pas mal de ligne, on a les valeurs hexa 0x30, 0x60, xC0, etc.
Pour mieux comprendre, voyons ces valeurs en binaire :
00110000 pour 0 décalage
01100000 pour 1 décalage
11000000 pour 2 décalages
10000001 pour 3 décalages
00000011 pour 4 décalages
00000110 pour 5 décalages
00001100 pour 6 décalages
00011000 pour 7 décalages
Souvenons-nous que le test de Spectro effectue un ou exclusif bit à bit entre la valeur décalée lue, et la valeur décalée théorique qu'on devrait lire.
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
Autrement dit, quand ça foire, ce qui est affiché est uniquement ce qui est mauvais. La partie de ce qui est bon est elle passée à 0 par le XOR. Le but étant de montrer la constance de ce qui déconne.
Dans mon cas, on remarque que la valeur initiale de la valeur qui va être décalée a toujours ses bits D4 et D5 qui sont à 1 ! Ils sont ensuite décalés par les registres à décalage.
Ma première conclusion est donc que la valeur fournie aux registres à décalage est mauvaise : le bit D4 est verrouillé par le 74174 en C5, et le bit D5 est verouillé par le 74174 en D5.
Après, j'avoue ne pas avoir encore bien compris comment le PCB fonctionne pour la lecture de la valeur décalée (multiplexée semble-t-il avec les valeurs de DIP switch et celle du panel !...).
Je vais essayer de vous détailler tout ça un peu plus :).
Vais-je passer en deuxième semaine, ou bien vais-je être éjecté par la sentence de spectro ?? :(
;)
A+
C'est bon tu reste, bravo ;)
voici l'extrait de la nouvelle doc avec ton exemple :
If the matrix looks like that:
30 60 C0 81 03 06 0C 18
30 60 C0 81 03 06 0C 18
30 60 C0 81 03 06 0C 18
30 60 C0 81 03 06 0C 18
20 40 80 01 02 04 08 10
10 20 40 80 01 02 04 08
30 60 C0 81 03 06 0C 18
30 60 C0 81 03 06 0C 18
30 60 C0 81 03 06 0C 18
00 00 00 01 03 06 0C 18
The error bits shift, so this is an input error (before the shift is made). Lines 5 and 6 have fewer error bits than the others, because in these patterns the input bits 4 and 5 are set to 1. Thus, the 74174 @ C5 makes the error on bit 4 and the 74174 @ D5 makes the error on bit 5.
Salut,
Ouf ! Merci Spectro d'avoir confirmé mon diagnostique 8), et me revoilà en deuxième semaine à « Qui veut gagner une SI fonctionnelle ? » :D
Sitôt spectro avait-il posté, sitôt j'avais été voir dans mon stock de composants TTL si j'avais des 74LS174 : j'en avais ! ^-
Et l'opération de vérification allait être encore plus simple que je ne le croyais car ces composants étaient déjà sur support : ils faisaient partie de ceux que j'avais dessoudés au début, quand je me battais avec le circuit RESET.
Mais avant de vous raconter la suite, revenons un peu sur cette partie du schéma que je n'avais pas pris le temps de vous expliquer.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023210958-Little_Rabbit-schy-ma-shifter.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023210958-Little_Rabbit-schy-ma-shifter.jpg)
Ici nous avons 3 sous-ensembles :
1) le décodage des ports d'entrée/sortie (E/S)
2) la capture de la valeur à décaler
3) le registre à décalage (shifter) en lui-même
1) Le décodage des ports tout d'abordOn l'avait évoqué lors de l'étude du watchdog, car la remise à 0 du watchdog se fait via le port 6. Le 7442 utilisé ici est un décodeur BCD. À partir de la combinaison binaire présente sur ses 4 entrées, il active la sortie correspondante de 0 à 9
Exemple : 0101 en entrée activera la sortie n° 5
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211051-Little_Rabbit-E3-7442-PORTES.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023211051-Little_Rabbit-E3-7442-PORTES.jpg)
En entrée nous avons les bits d'adresse A8, A9 et A10. La 4ème entrée reçoit le signal SAMPLE issu de la carte mère. Sans rentrer dans les détails, celle-ci passe à 1 seulement quand le CPU exécute une instruction de type IN ou OUT, c'est-à-dire des instructions réservées à la lecture écriture non pas dans le plan mémoire du CPU, mais dans sa zone d'E/S. Le signal SAMPLE est en général au niveau bas, donc au niveau haut après avoir traversé le 7404. Par conséquent, tant que le CPU n'exécute pas d'instruction IN ou OUT, seules les sorties du 7442 supérieures à 8 sont activées. Mais ces broches ne sont reliées à rien, donc sans effet. Par contre, à l'exécution d'une instruction IN ou OUT, SAMPLE va passer à 1 le temps de l'exécution de l'instruction. Selon l'opérande associé à l'instruction IN ou OUT, le microprocesseur présentera sur le bus d'adresse des valeurs pour les bits d'adresse A8 à A10 correspondant au port que l'on souhaite adresser. La sortie correspondante du 7442 sera activée, et déclenchera telle ou telle opération sur la carte fille selon le n° de port sélectionné. On n'exploite que 5 ports, ceux portant les n° de 2 à 6.
2) La capture de la valeur à décaler(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023213301-Little_Rabbit-Shifter-latch.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023213301-Little_Rabbit-Shifter-latch.jpg)
Elle est confiée à un ensemble de bascules D. Voyez la bascule D comme une cellule mémoire élémentaire d'1 bit. Elle mémorise et présente sur sa sortie Q la valeur qui était présente sur son entrée D au moment où il y a eu un front montant sur sa broche CLK.
C'est en faisant une opération OUT vers le port 4 que le processeur enverra la valeur à mémoriser.
Ici la mémorisation est répartie sur 3 circuits
- D0 et D1 sur le 74175 situé en B5, D2
- D3 et D4 sur le 74174 situé en C5
- et enfin D5, D6 et D7 sur le 2nd 74174 implanté en D5.
Pourquoi 3 circuits qui totalisent 16 bascules D alors qu'on aurait pu imaginer n'en avoir besoin que de 8 ? On remarque un câblage particulier : les bits D0 à D7 provenant du bus de donnée sont réparties une entrée sur deux des bascules, et chaque sortie est bouclée sur son entrée voisine. Ainsi, à l'instant t, les bascules mémorisent les 8 bits provenant du bus de donnée. À l'instant t+1, elles mémorisent la nouvelle valeur, et leur voisine elles mémorisent les 8 bits de l'instant précédent ! Autrement dit, en 2 écritures successives nous aurons mémorisé une valeur 16 bits (en écrivant d'abord les 8 bits de poids fort, puis les 8 bits de poids faible).
3) Le registre à décalage, ou shifterCette partie est un peu plus alambiquée, aussi vais-je la détailler pour essayer de vous l'expliquer le plus simplement possible.
Sur la majorité des schémas de SI qu'on trouve sur le net, et sur la version papier que j'ai achetée, les composants au cœur de cette partie sont des 25S10. Il s'agit d'un quadruple multiplexeur (un multiplexeur peut être vu comme un aiguillage) permettant de choisir 4 fois entre 2 sources. Mais déjà à la fin des années 70 quand Space Invaders a été fabriqué, ce composant devait être difficile à sourcer (aujourd'hui je ne trouve même pas de datasheet sur le net, c'est dire si c'est un composant oublié !...). Aussi Taito et Midway ont planché sur une solution alternative utilisant d'autres composants plus courants.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211410-Little_Rabbit-Shifter-schy-ma-version-74151.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023211410-Little_Rabbit-Shifter-schy-ma-version-74151.jpg)
(ce schéma que j'ai trouvé sur le net correspond à un PCB Taito, mais le principe est identique sur la version Midway).
Sur mon PCB, tout comme sur celui qu'aje m'a prêté, c'est cette version à base de 74151, un multiplexeur 8 sources vers 1.
Je vous l'ai schématisé comme ça :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211446-Little_Rabbit-74151-schy-matisy-.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023211446-Little_Rabbit-74151-schy-matisy-.jpg)
Imaginez un gros switch Peritel qui vous permettrait de choisir entre 8 sources pour n'en sortir qu'une vers le téléviseur :D. Bah c'est un peu ça, si ce n'est qu'en entrée, cela n'accepte pas in signal vidéo mais que du signal TTL qui peut être à 0 ou à 1.
Le 74151 a 8 entrées, I
0 à I
7, une sortie Q, et 3 broches de sélection S
0 à S
2. Selon la combinaison binaire présente sur ces 3 entrées, on retrouve en sortie le signal de l'entrée correspondante.
Comme on le voit sur le schéma plus haut, on n'utilise pas moins de 8 circuits 74151 ! Il y en a un par bit de la valeur décalée qu'on souhaite lire. Le principe de fonctionnement de ce registre à décalage est très simple, mais pas facile à exposer car ça fait un câblage touffu :).
J'ai essayé de le schématiser sur le dessin suivant :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211629-Little_Rabbit-Shifter-schy-ma-de-principe.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023211629-Little_Rabbit-Shifter-schy-ma-de-principe.jpg)
A gauche nous retrouvons nos valeurs de 2 x 8 bits qui ont été verrouillées dans les 174 et 175. Pour cet exemple la valeur mémorisée est 1111001110101110.
- quand la valeur de sélection des 74151 est à 000, on veut la valeur non décalée. Ainsi les 8 bits de poids les plus faibles sont envoyés sur les entrées 0 des huit 74151 (traits noirs sur le schéma).
- quand la valeur de sélection des 74151 est à 001, on veut la valeur décalée d'un cran. Ainsi on oriente vers les secondes entrées des 74151 8 bits en démarrant cette fois avec le bit en deuxième position (traits pointillés marron sur le schéma).
- quand la valeur de sélection des 74151 est à 010 en binaire, soit 2, on veut la valeur décalée de deux crans. Ainsi on oriente vers les 3ème entrées des 74151 8 bits en démarrant cette fois avec le bit en troisième position (traits pointillés rouge sur le schéma).
- et ainsi de suite pour les 8 valeurs de décalage possibles.
(sur le schéma je me suis arrêté à 4 pour ne pas le rendre illisible ;).
La valeur de sélection présentée à S
0, S
1 et S
2 quant à elle est mémorisé par le 74175 situé tout en haut sur le schéma Midway ou Taito.
Donc cet ensemble de composants permet au CPU d'obtenir rapidement une valeur 16 bits décalée de 1 à 8 bits d'un coup. Ceux qui connaissent un peu la programmation assembleur se demandent peut-être pourquoi une telle usine à gaz, alors qu'un microprocesseur possède des opérations de décalage... Hein, pourquoi alors ? :D Et bien la plupart des microprocesseurs possèdent de telles instructions mais pas le 8080 d'Intel ! :-\ En effet, ce processeur est très mal pourvu : il peut effectuer des rotations au sein d'un registre (le bit qui sort d'un côté rentre de l'autre), mais pas de décalages !
Pour en finir avec cet exposé, je vous mets ici un exemple de décalage où j'ai matérialisé les bits du registre à décalage par des points noirs et blancs pour symboliser des pixels :).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211759-Little_Rabbit-Shifter-exemple.JPG) (https://gamoovernet.pixhotel.fr/pics/20171023211759-Little_Rabbit-Shifter-exemple.JPG)
Voilà pour la partie théorique. Qu'en est-il de mon dépannage ?
Pour rappel, mon diagnostique, confirmé par Spectro se situait que le verrouillage de la valeur à décaler. Plus haut je vous disais que par chance j'avais d'autre 74LS174 sous la main, et qu'en plus ceux d'origine étaient déjà sur support.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211836-Little_Rabbit-20171021-192455.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023211836-Little_Rabbit-20171021-192455.jpg)
J'aurais dû aller me coucher mais je ne peux pas m'empêcher de tester tout de suite le remplacement des deux 74LS174 présumés coupables ! J'enlève de leur support les composants originaux, et je mets en place les neufs. Je mets sous tension et ...
Tadhaaa !...
Quoi ?
Rien, que de chi, ça merde toujours, cela n'a rien changé ! :'(
Merde alors, j'étais tellement sûr de mon coup !...
Cela ne m'a pas empêché de dormir, mais vous pouvez croire que j'y ai pensé quand même une partie de la nuit ! Je retournais mentalement le schéma dans tous les sens :D.
À ce moment là, je n'avais pas encore étudié dans le détail la partie shifter exposée juste avant. Je me posais des questions, mais je ne comprenais pas comment cela aurait pu venir d'autre chose que des 74174.
J'ai commencé par examiner à l'analyseur logique ce qui arrivait sur les entrés des 74174 et 74175.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023211943-Little_Rabbit-20171018-074843.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023211943-Little_Rabbit-20171018-074843.jpg)
Mais mes observations étaient pour le moins incohérentes ! J'utilisais le signal du port 4 comme déclenchement de l'acquisition des données, mais curieusement cela se déclenchait dès le calcul du CRC des ROM ! :-\
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212113-Little_Rabbit-BCD5-latch-shifter-input-001.JPG) (https://gamoovernet.pixhotel.fr/pics/20171023212113-Little_Rabbit-BCD5-latch-shifter-input-001.JPG)
Du coup j'ai détaillé le décodage des ports me demandant si cela ne venait pas de ça, et qu'on écrirait plus souvent qu'il ne faut dans les 74174 :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212403-Little_Rabbit-20171018-214701.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212403-Little_Rabbit-20171018-214701.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212336-Little_Rabbit-E3-7442-dy-codage-PORTS-02.JPG) (https://gamoovernet.pixhotel.fr/pics/20171023212336-Little_Rabbit-E3-7442-dy-codage-PORTS-02.JPG)
Rien de flagrant par ici...
Ces ports sont aussi utilisés pour déclencher tel ou tel bruitage sur la carte fille. J'ai donc relié le PCB à un ampli pour écouter le sound test de l'EPROM de test : ce n'est pas gagné !... Les sons démarrent dès la mise sous tension, et lors du sound test, des bruits indistincts qui ne varient pas vraiment d'une ligne à l'autre...
Là je commençais à patauger et ne plus trop savoir où chercher.
J'aurais bien aimé savoir si le problème venait de la carte fille ou de la carte mère. Vous pensez que j'aurais pu facilement pu tester avec la carte fille d'aje... Oui en théorie, sauf que son PCB ne fonctionne plus non plus depuis des mois !... C'est même ce qui m'a poussé à faire le capkit de mon alim, pensant que l'alim avait peut être flingué son PCB ! :-\
Je ne m'en étais pas venté, des fois qu'aje passe par ici ! :D
Je me suis donc retroussé les manches, et j'ai aussi cherché à dépanner son PCB qui ne donnait plus aucun signe de vie : bouillie de pixels fixe à la mise sous tension. J'ai commencé par regarder le circuit de RESET : bingo, il est HS !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184603-Little_Rabbit-Circuit-RESET.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184603-Little_Rabbit-Circuit-RESET.jpg)
J'ai d'abord cru que c'était les 74161 qui ne comptait plus. Sauf qu'une fois dessoudé, il était en fait bon !... Ah, mais il y a le 7404 en F3 qui provoque le chargement de la valeur à décompter. J'observe ce signal : il est toujours à 0 et bloque les compteurs ! Je le dessoude, le remplace et nouveau test :
ÇA MARCHE ! Curieusement, le composant est pourtant donné comme bon par le testeur de composants ! (ne pas s'y fier à 100% !)
Ouf, gros soulagement, ce n'était que ça ^- ! À noter que c'était le même composant qui était HS sur mon PCB... Comme il est relié au RESET de l'alim, peut-être que celle-ci tend à envoyer des pains dans la tronche à la carte fille à la mise sous tension ?...
Me voilà à nouveau avec un second PCB fonctionnel : bien pratique pour faire des comparaisons ! Je teste donc avec la carte fille d'aje : le test du shifter passe sans problème ! À noter toutefois que le sound test ne fonctionne pas vraiment mieux avec la carte fille d'aje. À creuser plus tard. Si je teste ma carte fille sur le PCB d'aje, le jeu se lance, mais affiche de grosses barres blanches en travers des envahisseurs.
Bon, c'est donc bien ma carte fille qui déconne, mais d'où ?!?!
Ne sachant à nouveau plus où chercher, vendredi dernier j'ai utilisé le comparateur de portes TTL HP prêté par mikebrandt. J'ai comparé plein de composants :
- 7442 en E3 => OK
- les 74174 en D5 et C5 => OK
- le 74175 en B5 => OK
- les 74151 en A4, A4', A5 et A5' => tous OK
- les 74153 en A3, B3, C3 et D3 => pareil, OK !...
Bon, et bien je n'y arrive pas, je vais me coucher :'(
La nuit portant conseil, et ayant encore retourné le problème dans tous les sens, je me dis qu'il faut tracer le signal entre la carte mère et les 74174 de la carte fille. J'avais déjà vérifié minutieusement le connecteur, mais je le fais à nouveau : bah non, tout est bon. Ensuite je teste à l'ohmmètre la continuité entre le peigne de la carte fille et les 74174, tout particulièrement les bits de données D4 et D5. Mais ce n'est pas aisé car les via de ma carte fille sont un peu oxydés... Ah, ici l'ohmmètre ne bipe pas !
Je scrute le pcb à la loupe :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212648-Little_Rabbit-20171021-092812.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212648-Little_Rabbit-20171021-092812.jpg)
Je croyais avoir un piste coupée ici, mais non, ce n'était qu'une saleté sur la piste.
Je continue à regarder de très près toutes les pistes, quand je tombe sur ça :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212715-Little_Rabbit-20171021-093349.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212715-Little_Rabbit-20171021-093349.jpg)
Puis sur ça !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212743-Little_Rabbit-20171021-093416.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212743-Little_Rabbit-20171021-093416.jpg)
En fait, dans les deux cas, il s'agit de pastilles qui ont été abîmées par mon dessoudage des 74174 fait il y 5 mois ! :-\
Je refais les pistes en soudant un petit bout de fil de cuivre
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212806-Little_Rabbit-20171023-205830.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212806-Little_Rabbit-20171023-205830.jpg)
Je mets sous tension pour une Nième fois, et... le test du shifter est cette fois bon ! :-)=
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212857-Little_Rabbit-20171021-192830.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212857-Little_Rabbit-20171021-192830.jpg)
Quand je pense que je me suis échiné durant des jours à chercher un composant coupable !... :? L'erreur de débutant quoi !...
Je vous poste une petite vidéo de ce que cela donne avec les ROM du jeu :
On peut voir que tout n'est pas encore bon : il y a ces pixels parasites à l'écran à plusieurs endroits !... L'intervalle est régulier : tous les 4 envahisseurs. J'ai testé ma carte fille sur la carte mère d'aje : ça ne le fait pas. C'est donc un problème lié à ma carte mère. Cela aurait-il un lien avec mes RAM détectées une fois sur 4 comme mauvaises, cela ne m'étonnerait pas...
Un gros plan sur les parasites :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171023212936-Little_Rabbit-20171021-193202.jpg) (https://gamoovernet.pixhotel.fr/pics/20171023212936-Little_Rabbit-20171021-193202.jpg)
Si vous avez des pistes, je suis preneur, car là je ne sais pas trop où chercher pour l'instant (enfin si, je vais me pencher sur les buffers du bus d'adresse et du bus de donnée). Mais à part les remplacer par d'autres pour comparer, je ne saurais pas comment observer ce genre de défaillance à l'analyseur logique !
Merci de m'avoir lu jusqu'au bout (je sais, je suis toujours trop long... :-\)
A+
Passionnant !!!!
je comprend une phrase sur 10
et encore je me vante en fait c'est une sur 20 :D
mais c'est bien mieux qu'un polar !
du suspense, de l'enquette mais où se trouve donc le coupable et est t'il seul ?
le mystère du PCB de SI sera t'il résolu par le petit lapin ?
en tout cas je suis admiratif et fan de tes exploits
encore encore
^-^
Jolie, pas simple du tout ce genre de panne ^-
Entièrement d'accord avec oldschool ^-^, c'est super bien expliqué, j'arrive à comprendre quelques trucs, cela prouve une chose; l'aventure existe encore en 2017 :-)=
Merci à toi mon little de prendre le temps de rédiger de beaux articles ^-
J'aimerai pouvoir faire de même ... Je me suis lançé dans le sauvetage (l'essai tout du moins) d'une CPU bally qui a subit les outrages du temps et de la batterie :'(
Il y a un début à tout !!!
Bon courage pour la suite ^-
Pour les CPU Bally corrodées j'ai fait un beau Tuto dans la section Flipper ;)
Oui, merci à toi ^-
http://www.gamoover.net/Forums/index.php?topic=37458.msg621586#msg621586
Salut,
Merci pour vos commentaires ! ^-
Il y en a au moins deux que cela intéresse ! :D
Je n'ai pas progressé dans le dépannage, mais j'ai commencé à réfléchir à partir des indices fournis par l'image.
Tout d'abord, il faut se souvenir que Space Invaders est en « tate », donc pour analyser l'image, et s'imaginer comment la mémoire vidéo est organisée, mieux vaut tourner l'image de 90 ° pour revenir à du classique ;).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025221524-Little_Rabbit-analyse-bug-glitch01.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025221524-Little_Rabbit-analyse-bug-glitch01.jpg)
En comptant le nombre de lignes entre 2 défauts, on tombe pile poil sur 64 ! Une puissance de 2, quelque chose de sympathique si on réfléchit en terme de bus d'adresse :). J'ai également relevé que les pixels corrompus ne durent que pendant 8 lignes de balayage.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025221547-Little_Rabbit-analyse-bug-glitch02.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025221547-Little_Rabbit-analyse-bug-glitch02.jpg)
Et en regardant l'ensemble de l'écran, on constate que le bug se répète toutes les 64 lignes de balayage. On remarque aussi des bugs de tir situés sur d'autres lignes à gauche de l'image, mais je pense qu'ils sont eux aussi espacés de 64 lignes, et pour simplifier mon raisonnement, j'en fais abstraction pour l'instant ;).
En lançant MAME, on apprend que l'écran aurait une définition de 260 x 224 pixels.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025221654-Little_Rabbit-ry-solution-y-cran-selon-MAME.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025221654-Little_Rabbit-ry-solution-y-cran-selon-MAME.jpg)
Le 260 me semble curieux ! En Googlant rapidement, je suite tombé sur ce site (http://www.emutalk.net/threads/38177-Space-Invaders) qui donne 256(x)*224(y) @ 60Hz, ce qui me semble bien plus logique. Comme l'écran est à l'horizontal d'un point de vue programmation et balayage, cela donne 256 pixels par ligne, et 224 lignes par image.
Le jeu est monochrome : 1 bit suffit à stocker l'état d'un pixel, il est soit allumé, soit éteint. Cela fait donc huit pixels par octet. Donc une ligne de pixels « consomme » 256/8 = 32 octets.
L'écran complet lui tient dans : 32 octets par ligne x 224 lignes = 7168 octets, soit 7 ko.
Mon bug graphique se répétant toutes les 64 lignes de balayage, on en déduit que deux bugs sont distant de 32 * 64 = 2048, soit 2 ko !
Plus haut, je disais que le bug durait 8 lignes avant de disparaître : 32 octets par ligne x 8 lignes = 256 octets !
Ensuite, où se trouve la RAM vidéo (VRAM) dans l'espace adressable par le CPU 8080 ? Le même site donné plus haut nous renseigne : elle démarre à l'adresse $2400 (le symbole '$' devant un nombre signifie qu'il est en notation hexadécimale ;)).
On note aussi que le bug ne démarre pas sur les premières lignes, mais grosso modo à la moitié de la hauteur qui sépare 2 bugs. Cela donnerait donc je pense à partir de la 32ème ligne de balayage. Soit 32 lignes de 32 octets = 1 ko après le début de la VRAM.
Si on résume, on a :
- VRAM démarre en $2400
- 1er bug à la 32ème ligne, soit en $2400 + $400 = $2800
- Bug qui s'étale sur 8 lignes soit 256 octets ($100) puis s'arrête
- Bug se répétant tous les 2 ko ($800)
En compilant ces informations, j'ai pu dresser le « mapping » mémoire de la RAM vidéo de Space Invaders :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025222011-Little_Rabbit-analyse-bug-glitch02-avec-adresses.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025222011-Little_Rabbit-analyse-bug-glitch02-avec-adresses.jpg)
Pour adresser 1 ko ; il faut 10 bits d'adresse (1024 = 210). Pour 2 ko, il faut donc un bit de plus : 11 bits. Serait-ce le 11ème bits qui serait « chancelant » ou pas très franc, et ferait qu'on ne lit/écrit pas là où l'on devrait ?
J'ai donc commencé par regarder le bit A10 (le 11ème puisque le premier est A0 ;)) et A11. Le 1er bug apparaît quand pour l'adresse $2800, A11A10 passent de 01 à 10. Mais le bug se répète quand en $3000 les bits A11A10 passent de 10 à 00... L'autre point qui est curieux, c'est que le bug ne dure que durant 256 octets. Du coup j'ai plus particulièrement regardé les bits d'adresse A8, A9 et A10. Cette fois, le point commun que je trouve à chaque apparition du bug, c'est que ces 3 bits d'adresse sont à 0, et que le bug disparaît quand on bascule à 001, c'est-à-dire que A8 repasse à 1...
Tout ce rapport est assez hypothétique : je ne suis pas certain de ce que j'avance. Et je n'ai pas d'explication sur la raison du phénomène.
J'ai brièvement regardé le schéma de la carte mère : on remarque que les RAM sont adressées tantôt par le CPU quand il veut lire ou écrire en VRAM (pour y dessiner les envahisseurs, tirs, score, etc.), et tantôt par la circuiterie qui balaye la VRAM pour en extraire les octets qui vont être transformés en pixels pour l'affichage vidéo.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025222231-Little_Rabbit-Multiplexage-adressage-RAM.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025222231-Little_Rabbit-Multiplexage-adressage-RAM.jpg)
Ce partage du bus d'adresse des RAM est réalisé par 4 multiplexeurs (vous vous souvenez, les fameux aiguillages ;)) de type 74157. Chaque 74157 gère 4 bits du bus d'adresse : à eux 4 ils gèrent les 16 bits du bus d'adresse. Ceux qui m'intéressent sont ceux entourés : ils s'occupent notamment des bits A8, A9 et A10 :).
Je vais donc commencer par examiner ces circuits, c'est la seule piste que j'ai pour l'instant. Si cela ne donne rien, j'irai voir A8, A9 et A10 en amont, au niveau du CPU et de ses buffers d'adresse.
Enquête à suivre une fois encore ! ;)
A+
Je me répète tant pis
PASSIONNANT
<:) <:) <:)
ça doit être le vin rouge mais vous m'avez perdu ;D
Très bonne piste, et ça explique pourquoi le test de RAM intégré à la ROM de test est OK, alors qu'il y a des bugs graphiques à l'écran !
Si ça c'est pas du détail !
Punaise y a de quoi lire et même s'il faut s'y prendre à plusieurs fois (pour au final ne pas être sur d'avoir tout compris :D ), c'est super intéressant ^-
Citation de: f4brice le Mercredi 25 Octobre 2017, 23:39:13 PM
Très bonne piste, et ça explique pourquoi le test de RAM intégré à la ROM de test est OK, alors qu'il y a des bugs graphiques à l'écran !
Oui, mais en plus la couverture du test ram n'est pas complète.
Pour tester les 8 bits de data les classiques motifs 0xAA et 0x55 sont utilisés.
Pour tester les 13 bits du bus d'adresse, une donnée incrémentale est utilisée, mais elle ne fait que 8 bits (0x00 ... 0xFF).
La donnée se répète donc 1 fois toutes les 256 fois. Les bits A8..A12 ne sont donc pas testés ;)
Bizarre vous avez dit bizarre?... Comme c'est bizarre!
J'avais quasiment tout compris jusqu'à ce que Spectro intervienne ... ;D
Citation de: rygar le Jeudi 26 Octobre 2017, 07:29:54 AM
J'avais quasiment tout compris jusqu'à ce que Spectro intervienne ... ;D
Le PCB dispose de 8 kB de RAM, accessible de 0x2000 à 0x3FFF.
La RAM est 8 bits, répartie sur 16 composants de 2 kbit chacun.
- 8 des 16 composants accueillent chacun 1 bit de donnée écrit à une adresse paire.
- les 8 autres composants accueillent chacun 1 bit de donnée écrit à une adresse impaire
Le test de RAM va faire plusieurs procédures pour tenter de vérifier si les 16 composants sont bons :
- il écrit partout la constante 0x55 et s'attend à relire 0x55 partout ; donc on écrit un "1" dans 8 composants, et un "0" dans les 8 autres
- il écrit partout la constante 0xAA et s'attend à relire 0xAA partout ; donc on écrit un "0" dans 8 composants, et un "1" dans les 8 autres
- ensuite, plutôt que d'écrire des valeurs constantes, le test va écrire une valeur <N> qui s'incrémente ; vu que la valeur <N> est sur 8 bits, <N> reboucle toutes les 256 fois.
Le gros problème de ce test, c'est que la valeur <N> est écrite à 4 endroits différents dans la RAM, et ces 4 endroits sont très corrélés :
- <N> est écrit à l'adresse <A>
- <N> est écrit à l'adresse <A+256>
- <N> est écrit à l'adresse <A+1024>
- <N> est écrit à l'adresse <A+1280>
Electroniquement, les adresses <A>, <A+256>, <A+1024> et <A+1280> sont très proches.
Elles ont au plus 2 bits de différence, voire 1 seul.
Ainsi, si une panne fait que la valeur de <N> devant être écrite à l'adresse <A>, l'est en réalité écrite en <A+256>, <A-256>, <A+1024>, <A-1024>, ..., la procédure de test ne le détectera pas !
Et comme l'a parfaitement résumé Spectro, les 5 bits de poids fort du bus d'adresse ne sont pas testés.
Merci d'avoir pris le temps de me répondre f4brice ^-
Je vais me coucher un peu moins bête ;D
Je ne regrette qu'une chose, c'est d'avoir fait le zouave en cours de physique avec l'oscillo, les petites plaques d'électronique ... Il faudrait être vieux avant d'être jeune.
La recherche de panne c'est digne d'un épisode de Colombo :-X mais passionnant !!!! (comme dirait olschool)
La suite la suite !!! :-)= :-)= :-)=
Salut,
Merci à tous pour vos commentaires <:) !
Citation de: olschool le Mercredi 25 Octobre 2017, 23:09:04 PM
Je me répète tant pis
PASSIONNANT
<:) <:) <:)
Merki ! ^-
Citation de: maldoror68 le Mercredi 25 Octobre 2017, 23:13:08 PM
ça doit être le vin rouge mais vous m'avez perdu ;D
Essaye peut-être d'y ajouter un peu de vin vert, puis du vin bleu, ça devrait te donner du vin blanc ! Y verrais-tu plus clair ?? :D
Citation de: f4brice le Mercredi 25 Octobre 2017, 23:39:13 PM
Très bonne piste, et ça explique pourquoi le test de RAM intégré à la ROM de test est OK, alors qu'il y a des bugs graphiques à l'écran !
Je ne sais pas comment interpréter ta remarque, mais je précise les points suivants (qui vont peut-être plus ou moins contredire mon hypothèse d'hier ;)).
Le test de la RAM effectué par la ROM de test ne passe pas toujours, et le bug ne me semble pas graphique. Je veux dire par là que l'écran affiche réellement ce qui est en mémoire. Le problème se situe bien quand le CPU accède à la mémoire. Si on regarde bien la vidéo postée un peu plus haut, on y voit que les bugs ne sont pas graphiques mais "fonctionnels". Si on regarde particulièrement les tirs, on s'aperçoit qu'ils laissent des traces derrière eux, et que ces traces engendrent des collisions pour les tirs suivants. C'est donc bien ce que le CPU a lu/écrit en mémoire qui est vérolé, et pas ce que la circuiterie vidéo envoie à l'écran qui me semble être le reflet réel de la VRAM.
Autre remarque : si on regarde l'écran titre, il n'y a pas de bug. Je pense que c'est parce que l'écran est fixe. J'en déduis, mais peut-être me trompe-je :), que l'écriture en VRAM d'un motif fixe est OK. Autrement dit, l'écriture serait bonne. Par contre, à partir du moment où il y a de l'animation, ça part en sucette. Mon hypothèse est la suivante : pour quelques chose d'animé, le CPU commence par écrire en VRAM le premier motif qui est bon. Puis pour la frame d'animation suivante, il va relire ce qu'il avait précédemment mis en mémoire, avant de le réécrire un peu plus loin pour obtenir le déplacement (ou animation) voulu. Et ce serait lors de cette lecture qu'il n'irait pas piocher au bon endroit, du fait de la défaillance de certains bits du bus d'adresse...
Tout ça pour dire que plus je considère la chose, et plus j'ai l'impression que le problème serait en amont des 74157 dont je parlais hier soir... À tester très rapidement :).
Citation de: f4brice le Jeudi 26 Octobre 2017, 08:15:31 AM
Le PCB dispose de 8 kB de RAM, accessible de 0x2000 à 0x3FFF.
La RAM est 8 bits, répartie sur 16 composants de 2 kbit chacun.
Je me permets une micro correction pour la bonne compréhension de nos fidèles lecteurs ;) => chaque composant Intel 2107 (ou TMS4060 ou AM9060) fait
4 kbit chacun, et non 2 kbit ;).
Huit circuits de 4096 x 1 bit nous font les 4 ko aux adresses paires, et les huit autres circuits de 4096 x 1 bit nous font les 4 ko aux adresses impaires, ce qui nous donne bien les 8 ko ^-.
A+
J'ai tout lu de bout en bout, c'est passionnant et impressionnant. Et ça me confirme que je suis un ignare en électronique :D
Moi qui suis du métier j'arrive encore à suivre, même si l'électronique numérique c'est un peu loin pour moi.
Je trouve cette analyse très intéressement et perso je n'aurai pas spontanément pensé à décripter l'image pour détecter la redondance du problème.
Pour moi tu es très certainement sur la bonne piste. Hâte de lire là suite ^-
Salut,
Citation de: Fred G5 le Samedi 28 Octobre 2017, 10:10:41 AM
Moi qui suis du métier j'arrive encore à suivre, même si l'électronique numérique c'est un peu loin pour moi.
Alors moi c'est l'inverse ! :D
En électronique analogique, je suis une quiche, alors que j'ai quelques restes en numérique :). Et j'ai acquis ces connaissances il y a plus de trente ans ! ;) Mais ça doit être comme le vélo, ça ne s'oublie pas (ou du moins, tout cela m'a suffisamment passionné à l'époque pour que je ne l'oublie pas 8)). Et là aussi à l'inverse de toi, ce n'est pas mon métier (et cela ne l'a jamais été), mais la passion fait le reste :).
Je m'en vais vous conter mais dernières tentatives...
Mes premiers suspects étaient donc les deux multiplexeurs du bus d'adresse des RAM (2 composants TTL type 74157) évoqués la fois précédente.
Je les ai testé au comparateur TTL HP, et il ne trouvait pas d'anomalie (mais j'ai une confiance limitée en cet appareil...). J'ai également fais des mesures à l'analyseur logique :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029121751-Little_Rabbit-P1030103.JPG) (https://gamoovernet.pixhotel.fr/pics/20171029121751-Little_Rabbit-P1030103.JPG)
J'ai comparé les bits d'adresse A
10 A
9 et A
8 en sortie du CPU avec ceux qui se retrouvent en entrée des multiplexeur. J'ai ajouté à l'acquisition les bits de poids fort de l'adresse des RAM, pour pouvoir identifier les endroits ou on accéderait bien aux zones buggées ($2800, $3000 ou $3800).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029121035-Little_Rabbit-F6F7-74157-A10A9A8.JPG) (https://gamoovernet.pixhotel.fr/pics/20171029121035-Little_Rabbit-F6F7-74157-A10A9A8.JPG)
Le problème avec ce genre d'acquisition (ici faite sur 2 secondes), c'est qu'il y a des millions d'échantillons, et qu'il n'est pas aisé de trouver l'endroit qui montrerait une défaillance. J'avais pourtant paramétré le déclenchement de l'acquisition (trigger) sur A
13 A
12 et A
11 = 101.
Comme je ne voyais rien, j'ai tenté une fonction d'export CSV du soft de l'analyseur logique. Ainsi je peux récupérer les données sous Excel, et à l'aide de filtres ne garder que les points signifiants. Le problème, c'est que le fichier CSV fait 2,4 millions de lignes (!), or un fichier Excel ne peut excéder 65535 lignes... J'ai quand même essayé sur le début du fichier, pour voir.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029121455-Little_Rabbit-Analyse-Excel-mesures.jpg) (https://gamoovernet.pixhotel.fr/pics/20171029121455-Little_Rabbit-Analyse-Excel-mesures.jpg)
Et je trouvais de rares différences ! Dans l'exemple au dessus entouré en rouge, le CPU doit être en train de lire ou écrire vers $3000. Les bits A
10 A
9 et A
8 en sortie de CPU sont à 000, alors que ceux en entrée de multiplexeur sont à 100 ! Cet événement c'était produit à 17,86 ms environ. Mais quand j'allais observer cet instant sur les chronogrammes de l'analyseur logique, je ne voyais rien d'anormal ! Puis j'ai fini pas comprendre : il faut zoomer fortement l'instant en question pour se rendre compte que très brièvement (durant quelques nano secondes) les valeurs sont différentes. Mais c'est simplement dû au temps de propagation du buffer du bus d'adresse ! C'était donc une fausse piste. Excel ne me permettra pas d'isoler des cas signifiants.
Ensuite j'ai fait des mesures et comparaisons entre ce qui rentre sur le multiplexeur et ce qui en sort.
Mais là aussi, je ne suis pas parvenu à voir des anomalies à l'analyseur logique.
N'ayant aucune preuve d'une défaillance, je me suis résolu à dessouder les multiplexeurs. Je l'ai sans doute déjà dit, mais les composants de ce PCB Midway sont une plaie à dessouder ! À l'époque avant de passer le PCB à la soudure à la vague, on pliait les broches des composants pour les maintenir en place :-(( !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029122113-Little_Rabbit-P1030107.JPG) (https://gamoovernet.pixhotel.fr/pics/20171029122113-Little_Rabbit-P1030107.JPG)
Il faut du coup commencer par déplier les broches avant de les dessouder. Et cela ne facilite pas l'extraction !
Je les remplace par des neufs :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029122133-Little_Rabbit-P1030111.JPG) (https://gamoovernet.pixhotel.fr/pics/20171029122133-Little_Rabbit-P1030111.JPG)
Résultat : rien, le bug est toujours présent ! :'(
Mon deuxième suspect se situait au niveau des buffers de bus d'adresse.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029121847-Little_Rabbit-buffer-bus-d-adresse.jpg) (https://gamoovernet.pixhotel.fr/pics/20171029121847-Little_Rabbit-buffer-bus-d-adresse.jpg)
J'avais eu l'occasion d'en discuter avec Spectro au téléphone, et le 7408 situé en F2 nous semblait un bon candidat : il buffurise précisément les bits d'adresse A
8, A
9, A
10 et A
11 ! Mais en même temps, je n'étais pas pleinement convaincu puisque ce buffer sert également à l'adressage des EPROM qu'on voit à côté sur le schéma. Or le CRC des ROM est bon lors de l'exécution de la ROM de test...
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029122157-Little_Rabbit-P1030110.JPG) (https://gamoovernet.pixhotel.fr/pics/20171029122157-Little_Rabbit-P1030110.JPG)
Je l'ai tout de même dessoudé, remplacé par un neuf, et...
Bah que dalle ! :'(
Avant tout cela, j'avais aussi testé avec le CPU du PCB d'aje, pour être sûr. Mais cela ne changeait rien. J'ai aussi regardé à l'oscilloscope la gueule des bits d'adresse au niveau des RAM. Mais avec un vieil oscillo analogique comme le mien, observer des signaux apériodiques comme un bus d'adresse, c'est un peu mission impossible, on ne voit rien.
Car je soupçonne la panne d'être plus un problème « électrique » que purement logique. Je veux dire par là que j'ai l'impression que pour une certaine combinaison de niveaux électriques d'entrées ou sorties sur le bus d'adresse, le bus se met à ne pas fonctionner normalement (notamment quand beaucoup de bits sont à 0 !). Je parlais plus haut de « sortance », mais se pourrait aussi être un signal qui rebondit avec une oscillation, de l'oxydation, un emballement thermique, ou que sais-je... Mais pour autant, le problème est tout à fait reproductible, donc je n'en sais rien à vrai dire...
Tirant leçon de l'épisode précédent où le shifter dysfonctionnait non pas en raison de composants défaillants mais des pistes du PCB abîmées, j'ai ensuite inspecté le PCB. J'ai refait quelques soudures sur le support du CPU.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171029122443-Little_Rabbit-P1030106.JPG) (https://gamoovernet.pixhotel.fr/pics/20171029122443-Little_Rabbit-P1030106.JPG)
J'ai testé la continuité de tout le bus d'adresse sur les 16 RAM (et vérifié aussi qu'il n'y aurait pas un court-circuit entre 1 broches et ses voisines immédiates, ou voisines de la rangée de broches d'en face.
Mais rien n'y fait, le bug est toujours là !...
J'avoue être un peu sec sur où chercher à présent... Les image et vidéo du bug déjà postées renferment toutefois d'autres indices : je vais examiner les tirs et les traces qu'ils laissent. Ensuite, je ne sais pas si vous avez remarqué, par moment certains envahisseurs montent de presque leur hauteur dans la zone de bug. Pour l'instant je ne sais pas pourquoi ni ce que cela signifierait en terme d'adressage erroné (bug situé sur les bits de poids faibles du bus d'adresse ??)...
Tout ça pour ça me direz-vous !... Et oui, dans un WIP, on cherche : parfois on trouve, et parfois pas :-\.
Si vous avez des idées, je suis preneur ! ^-
A+
Bon courage pour la suite; je ne vais pas te donner la solution (ce serait trop facile ...)
Néanmoins, plus tu avances dans la recherche de panne et moins tu auras de mal à trouver; tous les composants vont finir par être montés sur support :D
le processeur est définitivement mis hors de cause? j'ai lu sur les xx posts du web que le processeur est souvent montré du doigt ( genre ils séchaient...et en désespoir de cause il le remplacent )...un remplacement par celui de la pcb voisine est possible ?
@rygar : oui, si ça continue, je vais en avoir pour plus cher de support que de borne ! :D
@sushy18 : il faut bien tout lire (je sais, y en a des tartines :-\ ...) =>
Citation de: Little_Rabbit le Dimanche 29 Octobre 2017, 12:33:08 PM
Avant tout cela, j'avais aussi testé avec le CPU du PCB d'aje, pour être sûr. Mais cela ne changeait rien.
;)
A+
Salut Little_Rabbit,
Merci pour ton WIP il est extrêmement pédagogique et agréable à lire.
Pour ma part je n'ai pas avancé d'un iota sur mon WIP mais j'ai bien l'intention de m'y remettre très prochainement.
Pour rappel, j'en suis au stade où je cherche à obtenir les lignes verticales, que tu obtiens page 2 de ton WIP :
https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234114-Little_Rabbit-P1020659.JPG
Question : tu dis mettre l'EPROM de test en H avant de mettre sous tension et de voir ces lignes. Je pensais que l'on verrait ces mêmes lignes, sans aucune EPROM. Tu penses que l'EPROM de test est obligatoire si on veut voir les lignes verticales ?
Question bonus : si je veux forcer le Power On Reset, je dois mettre à la masse la patte 6 du connecteur 16 pattes (http://www.brentradio.com/images/Other/Docs/SpaceInvaders/midwayconnectorpinouts.txt) ? euh... de quel connecteur on parle ? j'ai un de 18 pattes (où y a la nappe +5 -5 +12, etc), et 2 petits (sur des pates metaliques en relief reliés aux boutons et ecran je pense)
Merci
jpettit
Salut,
Merci jpettit pour ton appréciation <:).
Citation de: jpettit le Mardi 07 Novembre 2017, 11:40:48 AM
Pour rappel, j'en suis au stade où je cherche à obtenir les lignes verticales, que tu obtiens page 2 de ton WIP :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930234114-Little_Rabbit-P1020659.JPG) (https://gamoovernet.pixhotel.fr/pics/20170930234114-Little_Rabbit-P1020659.JPG)
Tout d'abord, j'apporte une petite précision : ces lignes verticales que l'on voit à l'écran sur ma photo ne sont pas de même nature que celles que tu cherches à avoir. Dans mon cas, les lignes sont dues à des RAM défectueuses : certains boîtiers étant morts, leur bit de sortie sort toujours un 1, quelque soit l'adresse consultée, et quelque soit ce que l'on a pu y écrire avant.
Citation de: jpettit le Mardi 07 Novembre 2017, 11:40:48 AM
Question : tu dis mettre l'EPROM de test en H avant de mettre sous tension et de voir ces lignes. Je pensais que l'on verrait ces mêmes lignes, sans aucune EPROM. Tu penses que l'EPROM de test est obligatoire si on veut voir les lignes verticales ?
Je ne connaissais pas ce point de test, et n'avais jamais essayé de mettre sous tension sans aucune ROM. C'est dans la procédure de dépannage Bally Midway qu'ils évoquent cette étape non ?
Du coup je viens de faire le test : j'ai mis sous tension sans EPROM, et on obtient effectivement des lignes verticales :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171107211011-Little_Rabbit-SI-boot-sans-ROM.jpg) (https://gamoovernet.pixhotel.fr/pics/20171107211011-Little_Rabbit-SI-boot-sans-ROM.jpg)
Citation de: jpettit le Mardi 07 Novembre 2017, 11:40:48 AM
Question bonus : si je veux forcer le Power On Reset, je dois mettre à la masse la patte 6 du connecteur 16 pattes (http://www.brentradio.com/images/Other/Docs/SpaceInvaders/midwayconnectorpinouts.txt) ? euh... de quel connecteur on parle ? j'ai un de 18 pattes (où y a la nappe +5 -5 +12, etc), et 2 petits (sur des pattes métaliques en relief reliés aux boutons et écran je pense)
Le Power on Reset ne se trouve pas sur le connecteur encartable 2 x 18 broches, c'est effectivement un des connecteurs en haut de la carte fille. J'en parlais page 1 de mon WIP (http://www.gamoover.net/Forums/index.php?topic=37683.msg627079#msg627079) :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184321-Little_Rabbit-20170929-222204.jpg) (https://gamoovernet.pixhotel.fr/pics/20170930184321-Little_Rabbit-20170929-222204.jpg)
en expliquant qu'il fallait mieux mette une résistance de pull-down qui va fixer le niveau à la masse en l'absence de pression sur le bouton poussoir :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20170930184353-Little_Rabbit-Pull-down-resistor-circuit.png) (https://gamoovernet.pixhotel.fr/pics/20170930184353-Little_Rabbit-Pull-down-resistor-circuit.png)
Mais je me rends compte à l'usage que ce Power on Reset n'est pas du tout indispensable : si ton watchdog fonctionne bien, il fera de lui-même un reset 4 secondes après la mise sous tension. Car dans la pratique, entre le moment où j'actionne l'interrupteur de mon alimentation arcade, que je cherche le bouton, le saisisse et que j'appuie sur le bouton, et bien bien souvent, le watchdog a déjà fait le RESET :).
Une piste que je te recommande d'explorer d'ailleurs, c'est de tester le 7404 situé en F3 sur la carte fille : c'est par lui que passe le POWER on Reset en provenance de l'alim. Et dans mon cas il était mort, et sur le pcb aje_fr que j'ai remis en route, là aussi c'était ce 7404 qui bloquait le RESET et empêchait le PCB de booter !
Je crois me souvenir que tu as accès à un oscillo : je te recommande de regarder les signaux qui arrivent sur les 2 74161 qui gèrent le watchdog. Regarde si le 60 Hz arrive bien dessus, si les sorties s'activent selon le comptage binaire, et si la retenue du second compteur se manifeste toutes les 4 secondes. Et commence par regarder la sortie du 7404, pour voir si elle ne bloque pas le chargement des compteurs :).
A+
Merci, je vais regarder tout ça et te tenir au courant :-)
Pour l'écran avec les lignes verticales, c'est en effet dans la procédure de test Midway (chapitre 3.3 case B)
Salut,
Pour cause d'année sabbatique dirons-nous ;), cela fait plus d'un an que je ne vous ai pas raconté la suite de ce WIP !...
À vrai dire, il est longtemps resté un peu au point mort.
Si vous vous souvenez, en novembre 2017, j'en étais au point où le PCB bootait, fonctionnait, mais les tests mémoire demeuraient un peu aléatoires, et j'avais de satanés bugs graphiques dont je ne parvenais pas à trouver l'origine :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025221524-Little_Rabbit-analyse-bug-glitch01.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025221524-Little_Rabbit-analyse-bug-glitch01.jpg)
Ces bugs n'étaient pas seulement graphiques car ils provoquaient des collisions avec les tirs et rendaient le jeu injouable :'(.
Plus je cherchais, notamment autour de l'adressage mémoire lié aux bits A8, A9 et A10, et plus je devais bien admettre que je me trouvais face à un mur, dans une impasse ! :'(
Histoire d'essayer de mettre en évidence l'origine du bug, ou comprendre dans quelles circonstances il se produisait, j'avais commencé à programmer des petites routines graphiques en assembler 8080, routines qui s'exécutaient sur un PCB Space Invaders :) (avec l'aide de spectroman sur la mise en place de l'environnement de développement, j'essayerai de vous raconter un jour la "démo" que je voulais faire ;)).
Ces routines montraient bien quelques glitches à l'écran, mais sans que cela ne soit révélateur de quoi que ce soit de concret :'(...
Toujours dans l'impasse, j'ai essayé quelques trucs sans grande conviction.
J'ai d'abord regardé le générateur d'horloge Intel 3245 :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190303151248-Little_Rabbit-Intel3245.jpg) (https://gamoovernet.pixhotel.fr/pics/20190303151248-Little_Rabbit-Intel3245.jpg)
car quand on voit comment les pistes sont routées sur le circuit imprimé, on se dit que ses concepteurs y ont apporté une attention toute particulière :-\ :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190303151759-Little_Rabbit-P1030125.JPG) (https://gamoovernet.pixhotel.fr/pics/20190303151759-Little_Rabbit-P1030125.JPG)
Est-ce un rappel des figures de Nazca au Pérou ? La forme particulière des pistes le protège-t-il des rayonnements cosmiques (ou de signaux radio extra-terrestres ?? :-\), je n'ai pas la réponse :D (bon, plus sérieusement, j'imagine que c'est une histoire d'immunité au bruit, ou sensibilité des signaux d'horloge perturbation radio/électromagnétique ? Les pros de l'électronique nous le diront peut-être :) ).
Je l'ai remplacé par celui d'un PCB Gun Fight donneur provisoire de composants, mais cela n'a rien changé.
Ensuite, comme j'avais toujours un doute sur les RAM foireuses commandées sur Ebay en Allemagne, et qu'entre temps j'avais reçu un lot venant des US d'une source plus fiable (Arcade Chips), je me suis résolu à remplacer 100% des RAM, même celles qui passaient le test de la ROM de débug.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190303151848-Little_Rabbit-P1030270.JPG) (https://gamoovernet.pixhotel.fr/pics/20190303151848-Little_Rabbit-P1030270.JPG)
Ici, toutes les RAM d'origine sont dessoudées, et je suis en train de souder les supports qui vont accueillir les RAM présumées plus fiables.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190303151906-Little_Rabbit-P1030274.JPG) (https://gamoovernet.pixhotel.fr/pics/20190303151906-Little_Rabbit-P1030274.JPG)
Toutes les RAM sont à présents neuves, sur supports contact tulipe !
Résultat : bha rien de nouveau, j'ai toujours les mêmes bugs :'(. Découragé, j'ai lâché l'affaire pendant un temps.
Puis début novembre 2018, Matled est passé à la maison avec son PCB de Space Invaders Midway pour un rapide diagnostique :). Comme j'ai le harnais adéquat dans mon atelier, on a pu le brancher facilement, et on a rapidement constaté qu'on n'avait aucune image en sortie. Quelques investigations plus loin, il s'avérait que plusieurs des compteurs 9316 qui servent à générer les tops de synchro verticale et horizontale étaient morts. Nous n'avons pas pu aller plus loin car je n'ai pas assez de 9316 en stock, et ça ne court pas les rues comme vous le savez (composant obsolètes et difficile à trouver à prix raisonnable de nos jours).
Mais cette visite de Matled a été salutaire, car elle m'a incité à m'y remettre :).
Étant dans l'impasse sur ma carte mère, je voulais essayer de réparer un de mes PCBs Gun Fight qui utilise la même carte mère.
Cette décision s'avéra payante, et c'est ce que je vais vous raconter dans ce WIP (https://www.gamoover.net/Forums/index.php?topic=41253.msg657828) :).
A+
Salut,
Vous l'aurez compris si vous avez lu le WIP du PCB Gun Fight, en un rien de temps je me suis retrouvé avec une carte mère qui semblait bien fonctionnelle ! ^-^
Qu'en était-il une fois utilisée avec la carte fille et les ROM Space Invaders ?
Je prends donc la carte mère du Gun Fight, je place dessus la carte fille de Space Invaders, je place les 4 EPROM de Space Invaders :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155510-Little_Rabbit-20181111-192613.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155510-Little_Rabbit-20181111-192613.jpg)
Et je mets fébrilement sous tension...
...
Verdict ?
...
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155532-Little_Rabbit-20181111-193353-001.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155532-Little_Rabbit-20181111-193353-001.jpg)
Ça marche, les bugs graphiques ne sont pas présent avec cette carte :-)= !
Génial ! Depuis le temps que je galérais avec ma carte mère originale, j'en avais enfin une de substitution qui elle fonctionnait ! Je suis super content, vous pouvez me croire !
Du coup, je vais pouvoir me lancer sur le test et dépannage des sons, car jusqu'à présent j'avais travaillé sans alimenter la partie ampli de la carte fille, et sans brancher de haut-parleur.
Je modifie donc un peu le harnais de la carte fille pour lui ajouter du 12V sur les broches 10 et 11, en lieu et place du 18 V indiqué sur le schéma (j'ai vérifié la plage de fonctionnement de l'ampli LM377, il devrait tout à fait se satisfaire de 12V), et je branche également un haut-parleur sur les broches 8 et 9 du connecteur.
Je remets sous tension et constate que les sons fonctionnent partiellement :
- son faible et volume inopérant
- son des tirs absent
- son de l'explosion absent
Pourquoi le volume ne fonctionne-t-il pas ? Petit examen du schéma pour voir qui s'en charge :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155619-Little_Rabbit-Volume-ampli.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155619-Little_Rabbit-Volume-ampli.jpg)
Je vérifie le potentiomètre R106 et constate que sa résistance varie normalement : il est bon. Je me souviens que dans son WIP de Space Invaders, spectroman mettait en avant que ces LM3900 aimaient bien passer l'arme à gauche, et qu'il avait dû en changer un paquet ! Du coup, je change ce LM3900.
=> c'est bon, je récupère un son avec du volume, et réglable ! ^-
Pour tester ensuite les sons séparément, il y a certes la possibilité de la ROM de test qui déclenche en séquence et deux fois de suite tous les sons. Mais quand on veut se concentrer sur un son donné, ce n'est pas des plus pratique, ou du moins c'est un peu long quand on doit attendre qu'il refasse toute la séquence pour rejouer une fois le son qui nous intéresse. D'autant qu'une fois la boucle finie, il faudrait faire un reset pour redémarrer toute la séquence de test, et que dans ce cas, le Reset ne permet pas de passer le test des RAM, nous reviendrons là-dessus plus tard ;).
Cherchons une solution alternative :).
Rappelons également que sur Space Invaders, les sons ne sont pas issus d'un chip son piloté par le microprocesseur. Non, chaque bruitage est issu d'un petit module analogique qui le joue quand il reçoit une impulsion de déclenchement.
Comment sont déclencher ces bruitages ?
Un registre 74174 reçoit l'ordre de déclenchement d'une bonne partie des bruitages :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155655-Little_Rabbit-Dy-clenchement-sons.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155655-Little_Rabbit-Dy-clenchement-sons.jpg)
Pour plus de commodité, je décide d'enlever ce registre 74174, pour déclencher manuellement un à un les sons. Opération d'autant plus simple qu'il est déjà sur support ! :D
Test... et le résultat n'est pas vraiment celui escompté puisque tous les bruitages sont joués simultanément dans une belle cacophonie ! :-\ En effet, le potentiel des broches de sortie n'étant plus fixé, cela déclenche tous les sons. Pour y remédier, il me faut mettre toutes les sorties à la masse et ne changer qu'une sortie à la fois pour isoler chaque bruitage. Je remarque en faisant cela que le bit D1 de ce registre a une fonction particulière : fonction « Mute », à savoir couper tous les sons d'un coup, ou les autoriser (note pour plus tard : garder ça dans un coin de la tête !...).
En testant ainsi un à un chaque son, cela me confirme que les sorties 5 et 7 n'ont respectivement aucun effet sur le déclenchement des sons de tir (« Missile ») et Explosion.
Génération du son « Missile » :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155721-Little_Rabbit-Son-Missile.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155721-Little_Rabbit-Son-Missile.jpg)
Les amplis opérationnels (abrégé par ampli-op ;)) LM3900 sont des quadruples ampli-op. C'est-à-dire que dans un même boîtier DIP14, on y trouve 4 amplis-op indépendant.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155752-Little_Rabbit-Schy-ma-bloc-LM3900.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155752-Little_Rabbit-Schy-ma-bloc-LM3900.jpg)
Pour le son « Missiles » deux LM3900 sont à la manœuvre: la moitié de M4, et les 3/4 de P4. Je regarde à l'oscillo les signaux en sortie de l'ampli op M4. Je n'y trouve aucun signal tangible (alors que l'autre moitié de ce LM3900 est utilisée pour le « Invader Hit » qui lui fonctionne) ! En sortie de P4, je trouve que les signaux à l'oscillo ne sont pas super parlant... Je tente le changement du LM3900 M4, mais sans résultat :'(.
Du coup je me rabats sur l'autre LM3900 impliqué, celui référencé P4 : ça marche, je récupère le son « Missile » ! ^-^ Pour vérification, je remets en place le LM3900 M4 remplacé juste avant et cela fonctionne toujours : il n'était donc pas responsable de la panne, et encore bon !
Génération du son « Explosion » :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190304155811-Little_Rabbit-Son-Explosion.jpg) (https://gamoovernet.pixhotel.fr/pics/20190304155811-Little_Rabbit-Son-Explosion.jpg)
Je tente ici le remplacement du LM3900 K3 => c'est bon, cela me restitue le son manquant ! ^-^
Vous voyez donc que la réparation des sons sur une carte fille de Space Invaders se résume souvent à remplacer le LM3900 gérant tel ou tel son (notez qu'il y a une partie génératrice de bruit blanc à base de 4006 et ou exclusif qui peut aussi poser problème : elle est responsable de la « salissure » du bruit d'explosion et du tir, mais dans mon cas, ce module était bon :) ).
Hey !? Mais attendez là un peu ! N'aurais-je pas franchi une étape décisive ? :)
Oui oui, ça y est j'ai un PCB Space Invaders 100% fonctionnel ! 8)
Cela mérite bien une petite partie !
(avec les travaux en cours dans la maison, et le déménagement que cela a imposé, impossible de mettre la main sur le pied d'appareil photo !... du coup j'ai fait la vidéo à la tablette, désolé pour les petits flous de mise au point qu'elle opère...)
Vous aurez peut-être remarqué que sur mes harnais de dépannage, je câble de quoi brancher un joystick ATARI CX 40 ! :D :-*
Grâce au dépannage de la carte mère du Gun Fight, me voilà avec un ensemble fonctionnel ! Comme quoi il ne faut jamais désespérer, il existe toujours une solution à un problème ;) !
Mais ce n'est pour autant pas fini, le meilleur est pour bientôt ;) !
A+
putain tu me donne envie de trouver un Space Invaders pour me lancer dans sont dépannage aussi ^-
j adore ces vieux circuit tout ttl
Citation de: lencouet le Lundi 04 Mars 2019, 21:23:39 PM
putain tu me donne envie de trouver un Space Invaders pour me lancer dans sont dépannage aussi ^-
j adore ces vieux circuit tout ttl
Tu sais maintenant qu'il y a des cartes plein de TTL pas loin..SI...PONG. =:))
yes :-)=
Salut,
Merci pour vos commentaires :).
Citation de: lencouet le Lundi 04 Mars 2019, 21:23:39 PM
j'adore ces vieux circuits tout ttl
Heu... Space Invaders comporte beaucoup de TTL sur sa carte, mais il n'est pas "tout TTL" ;)
Il est architecturé autour d'un microprocesseur Intel 8080, avec de la RAM, des ROMS, etc. :)
Pour du tout TTL, il faudrait effectivement taper dans du Pong et ses clones, Breakout, Missile-X, etc.
A+
Félicitation pour ta persévérance mon little ^-^
Je n'ai pas tout compris mais c'est superbement bien expliqué ^-
Ta Space Invaders upright enfin fonctionnelle va pouvoir retrouver sa place définitive dans votre salon, surveillée de près par ton Close Encounters And The Third King datant également de 1978 ;)
Bravo c'est assez passionnant à lire !
J'aime bien les histoires qui se finissent bien
:-*
Salut,
Merci pour vos commentaires qui sont encourageants :), car avec la fréquentation en baisse de Gamoo, je me dis parfois que personne ou presque ne doit lire les tartines que je mets à chaque fois :D. Est-ce bien utile du coup ?... mais je me dis que Google peut toujours nous amener de nouveaux lecteurs.
@Rygar : en effet ! D'autant que cela fait 5 mois déjà que la Space Invaders n'est plus dans le salon, nous l'avons viré pour cause de travaux (travaux qui n'ont finalement commencé qu'en février !...).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306134853-Little_Rabbit-dy-my-nagement-SpaceInvaders.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306134853-Little_Rabbit-dy-my-nagement-SpaceInvaders.jpg)
(Là elle prenait un bain de soleil début septembre, mais rassurez-vous elle n'est pas restée dehors, elle était stockée dans la salle de jeux ! ;) et puis elle est revenue dans le salon pendant les fêtes, pour le côté festif ;) )
Mais pas sûr qu'elle se retrouve dans le salon quand les travaux seront finis car il y a de la négociation dans l'air pour que je trouve une autre borne, plus petite... ::) Comme si c'était encombrant une Space Invaders ! Et puis son extrême élégance et sa beauté intemporelle gomment complètement ses dimensions généreuses non ? :D
Citation de: olschool le Mercredi 06 Mars 2019, 09:52:32 AM
J'aime bien les histoires qui se finissent bien
:-*
Moi aussi ! :) Mais l'histoire n'est pas finie ! En effet, j'ai eu droit à un rebondissement inattendu après ce premier succès 8). Je vais essayer de vous raconter ça ce soir (attention, le récit sera une fois encore un peu long ! ;) ).
A+
Citation de: Little_Rabbit le Mercredi 06 Mars 2019, 13:54:35 PM
Salut,
Merci pour vos commentaires qui sont encourageants :), car avec la fréquentation en baisse de Gamoo, je me dis parfois que personne ou presque ne doit lire les tartines que je mets à chaque fois :D. Est-ce bien utile du coup ?... mais je me dis que Google peut toujours nous amener de nouveaux lecteurs.
C'est ce que je me dis également... ::)
Citation de: Little_Rabbit le Mercredi 06 Mars 2019, 13:54:35 PM
Comme si c'était encombrant une Space Invaders !
N'importe quoi ! c'est tout petit tout mignon Une
Space Invader et puis elle est si belle .... :-*
Faut vraiment que je m'attaque à la mienne.. :D
Citation de: Little_Rabbit le Mercredi 06 Mars 2019, 13:54:35 PM
Mais l'histoire n'est pas finie ! En effet, j'ai eu droit à un rebondissement inattendu après ce premier succès 8). Je vais essayer de vous raconter ça ce soir (attention, le récit sera une fois encore un peu long ! ;) ).
A+
La suite la suite j'ai hâte de lire ça ce soir :-)=
Citation de: Little_Rabbit le Mercredi 06 Mars 2019, 13:54:35 PM
Mais pas sûr qu'elle se retrouve dans le salon quand les travaux seront finis car il y a de la négociation dans l'air pour que je trouve une autre borne, plus petite... ::)
Mais qui a demandé une chose pareille ... (j'ai ma petite idée là dessus ... ;) ) Quoiqu'il en soit, la Space Invaders de mon Little doit rester dans le salon, rien que pour l'hygiène de l' oeil ^-^
Bon allez, la suite !!!! :-)= :-)= :-)=
Salut,
Oui hein, comment peut-on trouver une SI encombrante ?! ;)
Super content de mes dernières avancées, j'étais curieux de voir comment les sons se comportaient quand la carte fille était à nouveau mise sur la carte mère originale, celle avec ces satanés bugs graphiques.
Je réinstalle le tout sur mon banc test.
Je remets sous tension, et presque tout de suite, le haut-parleur gueule à tout va ! Mais je vous assure, un volume énorme et des sons stridents, genre scie circulaire ! J'ai même cru que cela allait avoir péter mon haut parleur !
Je coupe aussitôt l'alimentation et m'interroge sur la raison de ce vacarme. Je vérifie mes branchements, mais ne trouve rien d'anormal. À chaque nouvelle mise sous tension, ça gueule de la même façon, et plus surprenant encore, quelque soit le réglage du potentiomètre censé réglé le volume du son, le son restait toujours aussi fort :-\ !
La vidéo suivante vous montre le phénomène, sans restituer la violence du volume que le micro a minoré :
Mais pourquoi cette carte fille qui fonctionne parfaitement sur l'autre carte mère ici provoque un vacarme pareil ??
Je reprends les schémas, celui de la carte fille notamment :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195136-Little_Rabbit-Daughterboard.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195136-Little_Rabbit-Daughterboard.jpg)
Récapitulons tous les modules que comporte la carte fille Space Invaders :
- les multiplexeurs qui permettent de lire les boutons du panel et les options définies par les DIP switch
- le shifter
- le watchdog
- la génération de tous les bruitages (avec en plus la commande de « Mute » pour couper tous les sons)
- l'ampli audio
- et enfin le registre faisant office de port d'adressage ou sélection de ces modules distincts.
Je regardais donc en détail le schéma avec perplexité... quand soudain je vois un truc qui m'interpelle ! Mais bon sang et si c'était ça ?! =>
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195213-Little_Rabbit-Adressage-carte-fille.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195213-Little_Rabbit-Adressage-carte-fille.jpg)
Le zoom sur cette partie du schéma montre comment tout ce petit monde est piloté/adressé par le microprocesseur.
Ce sont les bits d'adresse A8, A9 et A10, ainsi que le signal « Sample » qui vont permettre de sélectionner soit la lecture du panel, soit la purge du watchdog, soit la lecture/écriture vers le shifter, ou encore déclencher les sons et la fonction Mute !
A8, A9 et A10, cela ne vous rappelle rien ?? :)
Mes bugs graphiques se produisaient justement sur certaines combinaisons de A8, A9 et A10 !
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20171025222011-Little_Rabbit-analyse-bug-glitch02-avec-adresses.jpg) (https://gamoovernet.pixhotel.fr/pics/20171025222011-Little_Rabbit-analyse-bug-glitch02-avec-adresses.jpg)
Quand j'ai vu sur le schéma A8, A9, A10 cela a fait tilt dans ma tête !
Si vous avez écouté la vidéo postée juste au dessus, vous aurez remarqué que le vacarme commence dès le test mémoire, partie du code où l'on se contente de lire et écrire en RAM (et purger il est vrai le watchdog, mais globalement une partie du code qui n'est pas censé adressé quoi que ce soit lié au son).
Mais pourquoi la carte se met-elle à gueuler alors ?
Pour que vous compreniez mieux, je me permets une petite explication sur l'architecture des systèmes à base de microprocesseur :
Tout microprocesseur dispose d'un bus de donnée qui va lui permettre de dialoguer avec son environnement : les données sont lues ou écrites sur ce bus. Le bus d'adresse quant à lui détermine la zone où se dialogue va se tenir. Enfin le bus de contrôle précise si on lit ou on écrit, gère les interruptions, le RESET, reçoit les signaux d'horloge qui vont cadencer le tout, et précise enfin la nature du dialogue qu'opère le microprocesseur :
- le microprocesseur dialogue-t-il avec la mémoire (RAM ou ROM) ?
- ou bien, le microprocesseur dialogue-t-il avec les composants périphériques ?
En effet, la plupart des microprocesseurs dispose de deux plans d'adressage :
- le plan mémoire
- le plan des entrées/sorties (E/S) dédié à l'adressage par exemple d'un port parallèle (PIO/PIA), un port série (SIO/6850), un chip audio, un contrôleur de lecteur de disquette, etc.
Cette distinction est faite d'une part pour que les E/S n'empiètent pas sur la zone mémoire qui s'en trouverait réduite d'autant sinon, et aussi parce que les composants périphériques gèrent des événements souvent plus lents que les échanges avec la mémoire.
Par voix de conséquence, le microprocesseur possède des instructions qui sont propres aux échanges avec la mémoire :
LD A, (2000H) ; charge dans l'accumulateur A l'octet situé à l'adresse 2000H
et d'autres instructions dédiées au dialogue avec les composants périphériques :
IN A, (10H) ; lit le registre d'un composant périphérique à l'adresse 10H
OUT (24H), A ; écrit le contenu de l'accumulateur sur port situé en 24H
Dans le cas des microprocesseurs 8 bits, le bus d'adresse fait généralement 16 bits permettant d'adresser 64 Ko, alors que le bus d'adresse pour adresser les périphériques ne fait plus que 8 bits, permettant d'adresser 256 registres de périphériques différents.
Si je vous explique tout ça, c'est parce que dans le cas de Space Invaders, la carte fille s'adresse uniquement avec des IN et des OUT, c'est-à-dire dans le plan des E/S.
Or le test mémoire de la ROM de test passe le plus clair de son temps à lire et écrire uniquement en mémoire, donc à adresser le plan mémoire et pas le plan d'E/S !
Je tenais donc là une excellente piste d'investigation ! ^-^
Reste à comprendre comment le 8080 d'Intel gère ses accès soit en mémoire, soit en E/S.
Sur des microprocesseur comme le Z80, c'est simple : le bus de contrôle dispose de broches qui vont directement indiquer dans quel plan d'adressage on se trouve :
- si la broche MREQ est activée, on dialogue avec la mémoire (MREQ pour Memory REQuest)
- si la broche IORQ est activée, on dialogue avec les périphériques (IORQ pour Input/Output ReQuest)
N'ayant jamais étudié le 8080, et après examen de son bus de contrôle, je n'avais pas la moindre idée de la façon dont il gérait ça. J'ai trouvé sur le net le livre complet d'Intel expliquant dans le détail l'architecture des systèmes à base de 8080 : « Intel 8080 Microcomputer Systems User's Manual, September 1975 »
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195424-Little_Rabbit-8080UsersManual.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195424-Little_Rabbit-8080UsersManual.jpg)
Comme le bouquin fait 260 pages, je ne l'ai parcouru qu'en diagonale très rapide :D. Mais on y trouve des trucs amusants comme ça :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195444-Little_Rabbit-8080PunchCard.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195444-Little_Rabbit-8080PunchCard.jpg)
La façon dont les cartes perforées sont organisées pour un système 8080 ! ;D Nous sommes assurément en des temps bien lointains que même moi n'ai pas connus ! :D
Revenons-en à nos E/S sur 8080. À la lecture rapide de l'ouvrage, je comprends que le 8080 utilise en fait un registre externe au microprocesseur pour consigner l'état dans lequel il se trouve ! C'est le rôle de son « Status Latch » :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195503-Little_Rabbit-8080StatusLatch.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195503-Little_Rabbit-8080StatusLatch.jpg)
Une instruction donnée du microprocesseur est décomposée en plusieurs cycles, et une fois que l'instruction est décodée, et sa nature connue, le microprocesseur présente sur le bus de donnée le « Status » associé à cette instruction. Le registre externe mémorise cette valeur pour être exploitée par l'électronique de la carte.
Les différents états sont donc définis selon cette table :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195525-Little_Rabbit-8080StatusWordChart.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195525-Little_Rabbit-8080StatusWordChart.jpg)
J'ai surligné le bit D4 qui est celui qui m'intéresse puisqu'il est responsable des écritures vers les périphériques !
Comment cela est-il mis en place sur le carte mère de Space Invaders ?
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195558-Little_Rabbit-StatusLatchSpaceInvaders.jpg) (https://gamoovernet.pixhotel.fr/pics/20190306195558-Little_Rabbit-StatusLatchSpaceInvaders.jpg)
C'est le 74174 qu'on voit en haut à gauche qui joue le rôle de Status Latch. Il est ensuite combiné à d'autres portes logiques pour générer le signal « Sample » qu'on a vu tout à l'heure sur la carte fille, et qui sert à capturer la valeur des ports adressés sur la carte fille.
Maintenant que je sais comment est fait le distinguo entre un accès mémoire ou accès E/S, il ne reste qu'à observer les composants impliqués. On va commencer par le fameux Status Latch :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306195813-Little_Rabbit-P1030488.JPG) (https://gamoovernet.pixhotel.fr/pics/20190306195813-Little_Rabbit-P1030488.JPG)
À l'analyseur logique, voyons ce que l'on observe :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306202802-Little_Rabbit-D7-74174-status-en-Q4.JPG) (https://gamoovernet.pixhotel.fr/pics/20190306202802-Little_Rabbit-D7-74174-status-en-Q4.JPG)
Bingo ! Le bit D4, mémorisé par le registre et présenté en Q4, censé n'être activé que lors d'opération de type OUT est à 1 en permanence !! Cela veut dire que n'importe quelle instruction exécutée par le processeur déclenchait un accès à la carte fille ! Du coup, le registre des ports de la carte fille était activé en permanence, avec des valeurs qui ne lui étaient pas destinée, provocant un comportement erratique, et cela se traduisait par deux conséquences fâcheuses :
- le bit de la commande « Mute » était activé à haute fréquence ! Si vous écoutez bien la vidéo du post précédent, celle où je fais une partie, quand on presse START, le CPU déverrouille la commande Mute, et cela provoque un « POC » assez fort dans le haut-parleur. Générez ainsi des centaines de POC par secondes, et vous obtiendrez le son de scie circulaire que j'ai observé !
- la carte fille agissait comme si le processeur voulait y lire certaines valeurs et présentait sur le bus multiplexé des données, données qui venaient parasiter le bus de donnée lors des accès mémoire correspondant aux zones d'adressage de A8, A9 et A10 ! Voila l'origine des bugs graphiques observés !
Je dessoude le 74174 et le test sur mon testeur :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306202841-Little_Rabbit-74174-OK-alors-que-mauvais.JPG) (https://gamoovernet.pixhotel.fr/pics/20190306202841-Little_Rabbit-74174-OK-alors-que-mauvais.JPG)
Gné ?? :-X WTF ??? :?
Comment pourrait-il être bon alors que la sortie Q4 est à 1 en permanence ? :-X
Je change quand même ce registre par un neuf :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190306200156-Little_Rabbit-P1030489.JPG) (https://gamoovernet.pixhotel.fr/pics/20190306200156-Little_Rabbit-P1030489.JPG)
Eurêka !! Adieu bugs graphiques, et adieu bruit de scie circulaire ! :-)=
Cela prouve qu'il ne faut pas se fier à 100% à ce que diagnostique un testeur de composants, et qu'en matière de dépannage, il est bon de faire appel à tous ses sens : ouvrir les yeux, mais aussi les oreilles ! ;)
Content Rosco : le démon de pannes s'est pris une nouvelle raclée !
Bon, force de reconnaître qu'il m'en a fait baver, qu'il m'a parfois démotivé au point d'être à deux doigts de lâcher l'affaire. Mais le démon des pannes ne savait sans doute pas combien un Breton peut être têtu ! :D Quoiqu'il en soit, il est cette fois-ci bien à terre et KO ! J'espère qu'il ne se relèvera pas de si tôt ! :)
Autre conséquence de cette victoire : j'ai pu restituer à Gun Fight sa carte mère puisque Space Invaders est à présent 100% fonctionnel, avec ses cartes d'origine ^-^ . Cela m'a motivé pour poursuivre le WIP Gun Fight, qui fera l'objet d'un autre exposé ;).
Merci à ceux qui m'auront lu jusqu'au bout ^-.
A+
Salut.
J'adore ton sujet, je trouve ça passionnant, et pourtant je ne comprends que 20% de ce que tu dis,
Alors même si il y a moins de monde sur le forum, continue ^-^, j'ai l'impression de me coucher un peu moins con dans ce domaine.
Super bravo
Et merci pour ces explications Je viens comprendre pas mal de truc je me bat depuis quelques jour avec un moon patrol et un soucis avec le z80
Tu viens de m ouvrir de nouvelles pistes
Felicitation pour ce travail de recherche
Petite question dans le tableau qui présente ses états je vois qu'il ne vient jamais lire dans la mémoire
C'est normal?
Re,
Merci pour vos encouragements :) !
Citation de: lencouet le Mercredi 06 Mars 2019, 20:55:56 PM
Et merci pour ces explications Je viens comprendre pas mal de truc je me bat depuis quelques jour avec un moon patrol et un soucis avec le z80
Tu viens de m ouvrir de nouvelles pistes
Félicitation pour ce travail de recherche
Attention, dans mon exposé si dessus, j'explique les principes génériques du fonctionnement de nombreux microprocesseurs, dont parfois le Z80 de chez Zilog. Mais le cas détaillé appliqué à Space Invaders ne s'applique qu'au 8080 de chez Intel qui est très différent du Z80 ! ;)
Citation de: lencouet le Mercredi 06 Mars 2019, 20:59:45 PM
Petite question dans le tableau qui présente ses états je vois qu'il ne vient jamais lire dans la mémoire
C'est normal?
Si, dans le tableau "Status word chart" tu as l'état "Memory Read" en n°2. Mais attention, encore une fois cela s'applique au 8080 et ne t'aidera pas à dépanner un Moon Patrol architecturé autour d'un Z80 ;). D'ailleurs tu devrais ouvrir un post spécifique à ton dépannage, comme ça tu pourrais nous expliquer le problème rencontré, et peut-être pourrons-nous t'aider à le résoudre :).
A+
Oui je sais que ce n est pas la même architecture mais ce qui m'intéresse c est ton approche
Oui. C'est pas la lecture mais l écriture numéro 3 tous les bites sont à zero
Génial
ça pour une victoire c'est une victoire, le démon des pannes en a pris plein la gueule, bien fait pour lui.
toujours aussi passionnant a lire, même si je ne comprend pas tout, tu décrit de bien belle manière et réussi a rendre intelligible aux néophites
bravo ^- :-*
Superbe effort de vulgarisation dans la rédaction de tes posts ! Merci ^-^
Et bien content que le démon des pannes ce soit pris une grosse tatane en pleine poire :D
Citation de: Little_Rabbit le Mercredi 06 Mars 2019, 13:54:35 PM
Salut,
Merci pour vos commentaires qui sont encourageants :), car avec la fréquentation en baisse de Gamoo, je me dis parfois que personne ou presque ne doit lire les tartines que je mets à chaque fois :D. Est-ce bien utile du coup ?... mais je me dis que Google peut toujours nous amener de nouveaux lecteurs.
Merci Little_Rabbit pour ce partage de ton WIP. ^-
Je fais partie de tous ceux qui lisent régulièrement les nouveaux posts sur Gamoo, mais qui ne postent pas à chaque fois (sûrement pas assez souvent :-\)
Je suis partisans du maximum de détails. Grâce à tes posts détaillés, et surtout complétés avec de nombreuses photos, j'apprends beaucoup de choses. Et notamment sur les indices qui te permettent d'avancer sur une panne.
Et c'est en lisant tous ces récits de victoires sur le démon des pannes (de mémoire c'est sur les posts de F4brice que j'ai lu, pour la première fois cette expression, mais elle est peut-être apparue avant ;D) que j'essaie de me motiver pour commencer mon WIP.
Encore merci. ^-^
J'ai hâte de lire les autres WIP
PS : Quand je souris en lisant :
Citation de: Little_Rabbit le Mercredi 06 Mars 2019, 20:31:19 PM
Content Rosco : le démon de pannes s'est pris une nouvelle raclée !
Je prends un coup de vieux. :-((
mais en même temps je suis content =:))
bien joué, little rabbit.
j'avoue que je n'aurais sûrement pas ton obstination à dépanner
ma SI de la sorte. Même s'il faudra bien un jour :D
Il te manque plus que le mug qui t'est promis
Salut,
Merci à tous pour vos retours ^-^ : ils font chaud au cœur et m'encouragent alors à poursuivre ces récits wipesques à rallonge ! :D
@vaes : oui tout à fait, "démon des pannes" est une expression © F4brice que j'ai réutilisé sans vergogne ! :) Je n'ai pas la prétention d'égaler f4brice, mais le démon des pannes se matérialise à toutes sortes d'échelles, je m'attaque à celles qui peuvent être à ma portée ;).
@funkycochise : je n'ai pas compris à quel mug tu faisais allusion ! :D J'ai bien un mug Pacman, mais pas encore de SI :)
Si tu as un PCB Space Invaders en rade, fais péter le WIP ! Je commence à bien le cerner ce PCB, ce peut-être l'occasion de faire voir au démon des pannes de quel bois on se chauffe sur Gamoo ! 8)
A+
Pareil, je ne réponds pas toujours, mais je lis tout ce qui est publié sur Gamoo :) Je suis impressionné et bien souvent ça me dépasse complètement en terme de technique, mais j'adore. Faut pas lever le pied !
Citation de: Little_Rabbit le Jeudi 07 Mars 2019, 23:08:44 PM
le démon des pannes se matérialise à toutes sortes d'échelles, je m'attaque à celles qui peuvent être à ma portée ;).
Si tu as un PCB Space Invaders en rade, fais péter le WIP ! Je commence à bien le cerner ce PCB, ce peut-être l'occasion de faire voir au démon des pannes de quel bois on se chauffe sur Gamoo ! 8)
Heu, en ayant bien lu tout ton post, je ne vois pas quelle panne peut te résister ... Tu sembles même être chaud patate dans le wip en ce moment; ça fait plaisir ...
Pour le bruit de la scie circulaire; à bien y réfléchir, ce sont surement les ouvriers qui sont chez toi en ce moment et qui changent ton parquet ... :D =:))
Bref, ta Space Invaders est repartie pour 20 ans au moins ...
Je me pose une question; sur un pcb en panne, tu dessoudes tout, tu testes chaque élément, tu montes tout les supports après contrôle visuel approfondi de la carte et ça devrait fonctionner ... ;)
Citation de: Little_Rabbit le Jeudi 07 Mars 2019, 23:08:44 PM
Salut,
Merci à tous pour vos retours ^-^ : ils font chaud au cœur et m'encouragent alors à poursuivre ces récits wipesques à rallonge ! :D
@funkycochise : je n'ai pas compris à quel mug tu faisais allusion ! :D J'ai bien un mug Pacman, mais pas encore de SI :)
Si tu as un PCB Space Invaders en rade, fais péter le WIP ! Je commence à bien le cerner ce PCB, ce peut-être l'occasion de faire voir au démon des pannes de quel bois on se chauffe sur Gamoo ! 8)
je me souvenais que tu étais un des destinataires des mug SI dénichés chez noz il y a une année ou 2
oui je crois même avoir au moins deux pcb SI
Salut petit lapin =:)), ça fait un petit moment que je suis pas venu sur le forum, je viens de parcourir ton wip , un truc de fou ^-^ tu as du en passer du temps , je comprend pas tout mais c'est un vrai plaisir de te lire. Merci.
Salut,
@philougames : merci, ça fait toujours plaisir de savoir cela intéresse certaines personnes ! ;)
À présent que ma borne fonctionne depuis plusieurs mois, je voulais faire un petit bilan de ce dépannage :).
En ce qui concerne le PCB, ce WIP démarra en novembre 2015, pour s'étaler jusqu'en novembre 2018 ! Trois ans !... :-\
Un WIP, c'est facile à démarrer, mais c'est autre chose de s'y tenir et aller jusqu'au bout :D. Et c'est encore pire pour ce qui est de s'astreindre à rédiger son WIP et continuer à le partager avec la communauté !... :-\
Bon, ce WIP a certes été très long (et n'est pas fini sur le plan cosmétique !), mais il faut dire que c'était le premier PCB auquel je m'attaquais véritablement avec persévérance, et puis les pannes étaient multiples !
Voyons l'étendu de ce qui était HS :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190505234403-Little_Rabbit-20190505-182613.jpg) (https://gamoovernet.pixhotel.fr/pics/20190505234403-Little_Rabbit-20190505-182613.jpg)
- le microprocesseur 8080
- 2 condensateurs tantale goutte en court-circuit (j'ai aussi remplacé pas mal d'autres condensateurs, dont tous ceux de la carte alimentation ;))
- 8 RAM sur les 16 présentes
- 4 circuits TTL : le 7404 lié au RESET, le 9316 des tops de synchro vidéo, le 7400 lié au signal Sample, et le fameux 74S174 qui sert de Status Register et qui m'a donné tant de fil à retordre !
- 3 LM3900 sur la partie son
- Et 4 ROM sur les 5 présentes ! :-\
Parlons de ces ROM justement. Une fois que le PCB était dépanné et fonctionnait avec les EPROM 2716 programmées, j'étais curieux de voir si les ROM d'origine étaient bonne ou pas. D'autant que j'avais remarqué qu'il y en avait 5 et non 4 comme c'est normalement le cas sur un PCB Space Invaders ! S'agissait-il d'une version Deluxe ?
Comme j'avais déjà dessoudé/ressoudé plusieurs fois les « jumpers » qui permettent de changer la configuration entre ROM ou EPROM, cette zone du PCB commençait à être fragilisé. Ne voulant pas l'abîmer d'avantage, j'ai décidé d'ajouter un commutateur permettant facilement de passer instantanément de ROM à EPROM :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190505234102-Little_Rabbit-P1030494.JPG) (https://gamoovernet.pixhotel.fr/pics/20190505234102-Little_Rabbit-P1030494.JPG)
J'ai ensuite pu mettre en place les 5 ROM d'origine :).
Mise sous tension, et... rien ! :'(
Le PCB ne boote pas. Je voulais en savoir un peu plus, et étais curieux de dumper ces ROM pour voir ce qu'elles pouvaient contenir. Mais mon programmateur ne les connaît pas, et leur brochage étant différent d'une EPROM, ce n'était pas possible directement. Du coup je me suis fabriqué un petit adaptateur. Les brochages sont très proches :
9316
A7 1 +-v-+ 24 Vcc
A6 2 | | 23 A8
A5 3 | | 22 A9
A4 4 | | 21 CS/
A3 5 | | 20 CS/
A2 6 | | 19 A10
A1 7 | | 18 CS
A0 8 | | 17 D7
D0 9 | | 16 D6
D1 10 | | 15 D5
D2 11 | | 14 D4
GND 12 +---+ 13 D3
2716
A7 1 +-v-+ 24 Vcc
A6 2 | | 23 A8
A5 3 | | 22 A9
A4 4 | | 21 Vpp
A3 5 | | 20 OE/
A2 6 | | 19 A10
A1 7 | | 18 CE/
A0 8 | | 17 D7
D0 9 | | 16 D6
D1 10 | | 15 D5
D2 11 | | 14 D4
GND 12 +---+ 13 D3
-------------------------------------------------------------------
Broche | 9316 | 2716 | Câblage sur PCB Midway
--------+--------+--------+----------------------------------------
18 | CS/ | CE/ | Chip Select du boîtier
--------+--------+--------+----------------------------------------
20 | CS/ | OE/ | Toujours à la masse
--------+--------+--------+----------------------------------------
21 | CS/ | Vpp | +5V pour EPROM, à la masse pour 9316
-------------------------------------------------------------------
|
Pour lire une 9316 sur un programmateur réglé sur le type 2716, il suffit donc de détourner la broche 21 vers la 20 :)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190505234336-Little_Rabbit-20190505-182657.jpg) (https://gamoovernet.pixhotel.fr/pics/20190505234336-Little_Rabbit-20190505-182657.jpg)
Ainsi j'ai pu tenter de dumper mes 5 ROM « mystère ».
Résultat :
- ROM D => HS !
- ROM E => HS !
- ROM F => dumpée
- ROM G => HS !
- ROM H => HS !
Sur les 5 ROM, 4 s'avéraient mortes :'( ...
Mon fichier binaire de la ROM F allait-il tout de même m'en apprendre un peu plus et révéler le mystère ? Bah même pas ! La ROM F s'avéra tout à fait identique à la ROM F d'un Space Invaders de base ! Mais pourquoi y avait-il 5 ROM au lieu de 4 ? Je ne le saurai peut-être jamais :D. Si vous avez un PCB Space Invaders à 5 ROM, je suis curieux de savoir ce qu'elles contiennent ! ;)
Et pour l'anecdote, dernier point que je voulais approfondir : le programme de test corrigé par f4brice et surtout grandement amélioré par spectroman. Vous savez combien ce programme fût précieux, et je les remercie encore une fois pour leur superbe travail !
Souvenez-vous, j'ai terriblement galéré autour du dépannage des RAM :
- j'en avais 8 de défectueuses sur les 16
- sur les 24 RAM soit disant NOS achetées sur Ebay, 17 s'avérèrent HS ! :-((
- et ce satané Status Register en panne qui venait parasiter le bus de donnée pour certaines combinaisons de A8, A9 et A10 me fit longtemps douter de la viabilité des RAM installées
Ces difficultés m'ont fait exécuter un paquet de fois le programme de test. Et comme je faisais cela avec mon banc test et non dans la borne, j'avais la possibilité d'appuyer sur mon bouton RESET pour exécuter encore et encore ce programme, sans éteindre et rallumer l'ensemble. Mais curieusement, j'avais remarqué qu'après un RESET, une bonne moitié des RAM étaient presque toujours détectée comme mauvaises :'(. Tant que le PCB était en panne, on pouvait trouver cela normal, mais une fois apparemment fonctionnel, un RESET du programme de test provoquait toujours la détection de RAM défectueuses !
Du coup je me suis penché sur la routine de test dont je vous livre le début :
;---------------------------------------
; First RAM test
;---------------------------------------
ramtest:: mvi d,0x00 ; clear the error register
mvi c,0x03 ; We'll do the ram tests three times - keep track in c
;---------------------------------------
;Store #0x55 in all memory 0x2000 - 0x4000
;---------------------------------------
ramtest1: mvi b,0x55
lxi h,0x2000
rmtst1: mov m,b
inx h
mov a,h
cpi 0x40
jnz rmtst1
;---------------------------------------
;Check each stored value 0x2000 - 0x4000
;---------------------------------------
lxi h,0x2000
rmtst2: mov a,m
xri 0x55
jz rmtst2_cont ; no error, test next byte
mov b,a ; save A in B
mov a,l ; YES- load L into A
rrc
jc rmtst2_bad_odd
mov a, e
ora b
mov e, a
jmp rmtst2_cont
rmtst2_bad_odd:
mov a, d
ora b
mov d, a
rmtst2_cont:
inx h
mov a,h
cpi 0x40
jnz rmtst2
...
Comme je n'avais pas écrit cette routine, il me fallait comprendre pas à pas ce qu'elle faisait. Je comprends que les registres D et E de huit bits chacun, qui forment le registre 16 bits DE sont utilisés pour stocker les n° de RAM détectées comme mauvaises. OK.
Mais à la 1ère lecture un truc m'interpella : la ligne de code suivante remettait bien à 0 le registre D avant de commencer le test :
;---------------------------------------
; First RAM test
;---------------------------------------
ramtest:: mvi d,0x00 ; clear the error register
mais je ne trouvais pas trace d'initialisation du registre E ! Serait-ce aussi simple ? J'ai remplacé cette première instruction par la suivante :
;---------------------------------------
; First RAM test
;---------------------------------------
ramtest:: lxi de,0x0000 ; clear the error register
cette fois, c'est la paire de registres DE qui est mise à zero. J'assemble le code, le « link » et programme une nouvelle EPROM. Je test sur mon PCB, et... ça marche ! ^-^ Même après un RESET, toutes les RAM sont bien détectées comme bonnes ! :-)=
On peut en conclure qu'un microprocesseur 8080 remet à 0 tous ces registres à 0 à la mise sous tension, mais que ce n'est pas le cas après un RESET ! Voilà pourquoi cela fonctionnait la première fois, mais pas les suivantes en cas de RESET ;).
J'ai donc corrigé ce petit bug dans la routine de spectroman, et il existe à présent une version 1.3 de la ROM de test qui fonctionne dans toutes les circonstances :).
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190506080637-Little_Rabbit-20181119-124415.jpg) (https://gamoovernet.pixhotel.fr/pics/20190506080637-Little_Rabbit-20181119-124415.jpg)
Ça c'était en novembre 2018, et je viens de constater que le gars qui héberge la ROM de test et les sources a déjà une autre version 1.3 faite par un Canadien en mars 2019 ! Merde, moi qui pensais passer à la postérité en matière de restauration d'arcade avec mon débuggage, me suis fait griller par un Québécois :D ;).
Les leçons que je retirerai de ce dépannage :
- être persévérant, même si les impasses dans lesquelles on se trouve parfois sont décourageantes ^-
- ne pas toujours se focaliser sur la recherche d'un composant coupable, parfois ce peut être une piste coupée ou abîmée
- ouvrir les yeux ET les oreilles : le son fourni par un PCB peut aussi être source d'indices qui mèneront à la résolution de la panne
Comme le disait si bien La Fontaine, "Patience et longueur de temps font plus que force ni que rage" 8) !
A+
Comme toujours, c'est vraiment super intéressant, bien écrit et documenté, merci beaucoup de ton partage ! Il doit y avoir pas mal de monde qui lit sans commenter et c'est dommage, pour ma part et en tant que complet béotien en électronique, tes sujets sont toujours un plaisir à lire et me donnent l'impression que je pourrais même le faire moi-même ! Ce qui bien évidemment est faux puisqu'il me manque les bases les plus élémentaires en cette matière :D
Et encore félicitations pour la résurrection de cette vénérable grand-mère ^-
Félicitations pour ce dépannage de cette pcb de SI ^-^ ^-^
J espère que les pcbs de SI ne sont pas dans le même état que la tienne :-[
bravo surtout pour le travail de redaction et de vulgarisation ^-^
quand j'ai commencer dans le depannage mon pere me disait toujours "explique si tu ne peux pas c'est que tu n'as pas compris "là on peux dire que tu as bien compris le fonctionnement
Merci Little_Rabbit, comme d'hab c'est agréable et utile à lire :20: Un WIP de longue haleine qui ce fini, ça fait quoi ?
Citation de: lencouet le Lundi 06 Mai 2019, 21:57:17 PM
mon pere me disait toujours "explique si tu ne peux pas c'est que tu n'as pas compris "
Ton père avait tout à fait raison ^-^
Salut,
Merci à tous pour commentaires et encouragements, c'est super sympa et motivant ^-^.
Oui, ton père avait raison lencouet, c'est exactement ce que je viens de me dire en finissant de rédiger mon compte-rendu de WIP pour Gun Fight ! ^-
Parfois on a fait le dépannage, on sait en gros pourquoi ça marche, mais en rédigeant dans le détail le WIP, cela m'oblige à approfondir certains points et finalement cela amène une meilleure compréhension qu'avant d'avoir publié le WIP ! ;) Donc allez y, racontez aussi vos WIP dans le détail ! C'est vrai que ça prend un peu de temps (voire beaucoup :-\), mais vous verrez que c'est utile aux lecteur et au rédacteur :) !
@AsPiC : bah disons qu'on est content d'en voir le bout, mais en même temps ce n'est jamais fini : il me reste des détails cosmétiques à améliorer, et puis ça peut retomber en panne ! :D
Mais cela reste pour moi très positif car cela motive pour en attaquer d'autres : après des années d'échecs, avoir enfin une victoire est valorisant, renforce sa confiance en soi, etc. ^-^
A+
Superbe
une histoire qui finis bien ^-
J'ai suivi avec attention et a n'en pas douter lors de la remise en route de la mienne ce wip sera plus qu'utile ^-
PS:pense a le sauvegarder dans un doc style word avec les photos pour en avoir ne sauvegarde ;)
Salut,
Merci olschool :).
Citation de: olschool le Mardi 07 Mai 2019, 10:37:23 AM
PS:pense a le sauvegarder dans un doc style word avec les photos pour en avoir ne sauvegarde ;)
Oui pas de soucis, je rédige toujours mes WIP sous Word avant de les poster (plus pratique je trouve, correcteur orthographique, etc.), et j'ai les photos à part :
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/20190507112249-Little_Rabbit-Organisation-WIP.jpg) (https://gamoovernet.pixhotel.fr/pics/20190507112249-Little_Rabbit-Organisation-WIP.jpg)
;).
A+