Salut,
Merci à tous pour vos commentaires !
Tu ne serais un des frères triples de gc 339 et de f4brice 
Oh non, même pas le demi-frère car je n'ai pas la moitié des connaissances et compétences de ces messieurs
.
Suite de mes investigations autour des Motion Objet Line Buffers
.
Pour répondre aux trois questions que je me posais sur l'origine de la panne, j'ai donc observé grâce à l'analyseur logique les signaux de différents composants.
Commençons par quelque chose de simple : les compteurs qui adressent les RAMs fonctionnent-ils correctement ? Mon analyseur logique ne possède malheureusement que 9 lignes d'entrée, ce qui limite souvent l'observation à des sous-ensembles, sans pouvoir voir d'un coup tous les signaux qu'on aimerait étudier. Mais avec 9 lignes, c'est déjà pas mal, on peut voir des tas de choses
.
Une difficulté avec un analyseur logique (ou un oscilloscope) c'est d'observer certains signaux à un instant en particulier. Car durant une trame vidéo, il s'en passe des choses sur un PCB ! Aussi j'essaye de déclencher la capture qui correspond à un moment où il y a assurément quelque chose à l'écran : j'utilise le signal 128V, qui passe à 1 une fois qu'on entame le tracé de la 128ème ligne de balayage. Je l'ai choisi parce qu'il est directement disponible sur une broche de l'un des custom chips Namco. Mais après coup je me suis dit que ce n'était pas génial dans mon cas : sur Pole Position, la ligne 128 correspond je pense à l'horizon. Or toutes les voitures et panneaux sont surtout situés sous l'horizon !... Mais bon, c'est mieux que rien : j'ai fait toutes mes captures à l'analyseur logique sur la grille de départ, quand il y a 8 voitures à l'écran et le portique de ligne de départ. Cela m'assure la présence d'éléments mobiles et zoomés à l'écran
.
Ici, je vais donc observer le bus d'adresse de la RAM en 10F qui est reliée aux 3 compteurs en 10H, 10J, 10L. Le bus fait au total 10 bits (pour adresser les 1024 cellules mémoire de 4 bits de la RAM 2149), je n'en observe que les 8 bits de poids faibles de part les limitations de mon analyseur logique :
On voit tout de suite que les compteurs comptent gentiment
. Les bits s'incrémentent dans l'ordre qu'il faut. Ici on doit être à l'instant où la RAM 10F est en train d'être lu pour afficher une ligne de balayage impaire (1V est à 1). Plus loin dans le chronogramme (pas sur cette capture), on voit que les compteurs partent d'une autre valeur intitiale et comptent moins longtemps : sans doute est-ce une séquence d'adressage de la RAM en écriture.
Conclusion : les compteurs sont présumés en bon état de fonctionnement !
Autre questionnement alors : des données arrivent-elles sur le bus de donnée de la RAM pour y être écrites ?
On voit ici que des données sont bien présentes sur les broches D0-D3, avec le Write Enable qui passe au niveau 0 et qui doit à ce moment provoquer l'écriture dans la cellule de la RAM dont l'adresse était alors désignées sur son bus d'adresse. Mais quand on regarde le chronogramme sur une plus grande durée, ce n'est pas super flagrant : il y a bien des données, mais cela reste un peu sporadique j'ai l'impression.
Détaillons d'où viennent les données écrites dans ces Line Buffers.
Le but de ce circuit est de présenter au Line Buffers les séquences de pixels 4 bits pour les voitures, panneaux et portique. Comment ça marche ?
À gauche, on a une donnée 8 bits DATAT0-DATA7 qui provient de la VRAM. C'est ici un n° de sprite ou brique élémentaire dont sont constitués les voitures, etc. Ces 8 bits servent à adresser les EPROMs contenant tous les graphiques des voitures :
- les bits D5 et D6 sont décodés par le décodeur LS139 en 11K. Les 4 combinaisons possibles de ces 2 bits sélectionnent l'un des 4 bancs d'EPROMs (ici les EPROMs sont associées 2 à 2 pour sortir simultanément 2 octets, soit 16 bits)
- les bits D0 à D4 sélectionnent l'un des 32 sprites
- les signaux LINE0 à LINE4 sélectionne j'imagine une ligne parmi les 32 lignes de haut que doivent faire les sprites
- les signaux 4H/8H/16H comme déjà évoqués viennent du compteur binaire horizontal de n° de pixel => ils sélectionnent 1 pixel parmi les 8 pixels de large que doivent faire les sprites
Adressé ainsi, le banc de 2 EPROMs sélectionné par le décodage du LS139 présente sur son bus de donnée les groupes de 4 bits des pixels voulus. Comme on adresse simultanément 2 EPROMS, on récupère en sorti 16 bits, soit 4 pixels contiguës
Ensuite le custom chip 13H (en bas à droite) dont je ne connais pas le fonctionnement présente j'imagine en sortie 1 pixel l'un après l'autre sur ses broches 12/11/17/18.
Enfin la PROM 12H permet j'imagine de remapper la couleur du pixel en fonction du n° de sprite.
Alors certains d'entre vous se disent peut-être depuis le début : mais pourquoi il ne vérifie pas les EPROMS contenant les bitmaps des voitures ??? C'est vrai, je n'en ai pas parlé, mais c'est un des premiers trucs que j'ai fait !
J'ai remplacé toutes les EPROMs par celle d'un autre PCB Pole Position (j'ai aussi changé le custom chip en 13H) => aucune différence, donc il est peu probable que les EPROMs soient incriminées. J'ai même un instant cru qu'il me manquait deux EPROMS ! Si vous regardez au dessus, il y a 2 supports vides. J'y ai mis les EPROMs d'un autre Pole Po :
Aucun changement, et pour cause car je me suis plus tard rendu compte que sur Pole Position 1, c'est normal que ces supports soient vides !
Ce n'est que sur Pole Position 2 qu'ils sont exploités
.
Bon OK, à présent qu'on voit comment ces EPROMS sont adressées, que voit-on en sortir dans mon cas ?
Observons MP1-MP4 qui sortent de la PROM 12H pour arriver les bascules D du LS174 en 11F (schéma Motion Object Line Buffers)
Il y a bien de l'activité, avec des données qui sortent mais il n'y a pas foule je trouve. En même temps, comme je démarre ma capture au 32ème pixel de la 128ème ligne de balayage, c'est peut-être normal... Je n'arrive pas trop à tirer de conclusion en observant ces signaux.
Retournons observer ce qui se passe autour des RAMs, à présent sur le multiplexeur LS298 en 9D par qui passe tout ce qui sort des RAM, lignes paires et impaires :
Ce plan un peu plus large, représentant plusieurs lignes de balayage est intéressant. Prenez comme unité d'observation le signal 1V (au milieu , entrée 5 de l'analyseur) : quand le signal est à 0 on est en train de tracer à l'écran une ligne paire, quand il est à 1 on trace une ligne impaire.
Petit rappel :
un multiplexeur comme le LS298 possède 2 lots (A et B) de 4 entrées chacune (A0-A3 et B0-B3), et joue le rôle d'un aiguillage : il présente en sortie soit les valeurs de A, soit celles de B selon la valeur de la broche de sélection S.
Sur ce chronogramme, au début à gauche pendant que 1V est à 0, on constate qu'il y a de la vie sur B0-B3, mais qu'au même instant ça ne bouge pas sur Q0-Q3 => B0-B3 représente ce qui doit être écrit dans la RAM des lignes paires, et Q0-Q3 montre que tout est plat, donc qu'on est en train de rien afficher. La ligne suivante, quand 1V passe à 1, ce qui est présent en B0-B3 est ce qui sort de la RAM, et qu'on retrouve en sortie Q0-Q1 : il y a certes de la vie, mais on voit de brefs pixels puis un vide, et à nouveau un pixel puis du vide, etc. Je trouve que ça ressemble pas mal à ce que j'ai à l'écran : quelques pixels éparses avec du vide
.
Observons à présent le même composant, mais avec les entrées A au lieu de B :
Cette fois on voit que durant une ligne impaire (1V est à 1), il y a de la vie sur A0-A1 => ces données sont écrites dans la RAM des lignes paires. Et en sortie Q0-Q1, on retrouve nos zigouigouis de pixels éparses avec du blanc. Puis sur la ligne vidéo suivante (quand 1V passe à 0), c'est le calme plat il ne sort rien de la RAM, et donc on n'a rien en sortie Q0-Q3.
Ces 2 observations conjointes me laissent penser que le problème se situe sur les RAM elles-mêmes ! Manque de pot, alors que j'ai un petit stock de composants pour pcb Pole Position, bien sûr je n'ai pas de RAM 2149 en stock
. Pas grave, j'ai plein de pcb Pole Position en rab, y en a bien un qui peut faire donateur d'organes
.
(on voit à côté les superbes soudures de réparations passées faites par un exploitant...)
Je prélève une RAM sur mon PCB #3, dessoude celle étudiée, et soude un support DIP 19 broches à la place.
Mise sous tension du PCB, et voilà ce que j'ai à l'écran :
YES
j'ai récupéré une ligne sur 2 !!
Petite vidéo du résultat :
Du coup, ni une ni deux je fais la même chose pour la deuxième RAM, en en prélevant une autre sur le même PCB donateur, et voila le résultat :
YES YES YES !!
J'ai à nouveau les voitures, les panneaux et le portique !
Content Rosco : c'est ma première réparation de PCB menée à son terme et qui soit un succès !
Là je n'ai testé que l'attract mode, mais j'espère que le reste fonctionne
.
Il me faut avant de pouvoir tester le PCB dans la borne adresser deux autres pannes :
- une de mes cartes RegAudio II (la carte sur les bornes ATARI qui assure la génération du +5 V et qui fait aussi ampli audio ) est en panne. Il y a un peu plus d'un an, alors que ma borne était encore à Vannes, j'avais testé dessus le PCB que m'avait donné Sushy18. Sauf que l'état du PCB était tel, avec ses broches d'alimentation du connecteur complètement cuites, que cela m'a fait fumer la carte REgAudio II (sous les yeux médusés de Spectroman qui me gronda de faire ce genre d'essai à la va vite sans plus de vérifications
).
- le moniteur fait disjoncter l'installation électrique : il faut que je le répare et trouve où se situe la fuite...
Voilà, je suis super content car avec ce PCB fonctionnel, cela me permet d'une part de refaire partir une de mes bornes, mais cela me donne aussi un exemplaire qui devrait me servir de référentiel pour essayer de réparer d'autre PCB Pole Position (car pour rappel nous avons avec mon frère 3 bornes Pole Position !
).
Merci encore une fois de m'avoir lu jusqu'au bout
.
A+
