Salut,
J'ai profité du 1er novembre férié pour continuer mes recherches de panne sur ce p#@$*& de Line Buffer
.
Comme je vous le disais, je ne savais plus trop où chercher... J'ai vérifié à l'ohmmètre que le routage du circuit imprimé était bien conforme aux schémas auxquels je me référais :
checked, ça correspond bien.
Les 3 compteurs 74S161 qui adressent la RAM 2149 en 9F sont donc bons, et pour autant ce qui y est écrit n'est pas bon ! À l'écran, si on regarde bien, le motif attendu est à peu près là (si on fait exception de certains « trous » ou manques dans les sprites), mais aux mauvaises coordonnées : beaucoup trop à droite. Et plus l'objet est lointain, donc petit, plus le décalage à droite est important. Une fois qu'il est affiché en gros plan, ses coordonnées semblent bonnes. De ce que j'ai compris du fonctionnement de cette partie du PCB, les coordonnées auxquelles une série de pixels d'une ligne de sprite sont chargées dans les compteurs par leurs entrées de pré-chargement, et par l'activation du signal LD actif au niveau bas.
Comme le bug varie en fonction de la distance de l'objet zoomé/réduit, je me suis demandé si cela pouvait avoir un rapport avec le niveau de zoom/réduction. Le niveau de réduction d'un objet est géré par cette partie :
La valeur de réduction SIZE0 à SIZE5 est chargée depuis la VRAM dans le verrou 74LS174, valeur présentée au 7497 qui est un diviseur binaire : à partir du signal d'horloge qui lui est appliqué sur son entrée CK, on retrouve sur sa sortie Z un signal d'horloge dont la fréquence a été divisée par la consigne donnée en entrée.
Lors de l'adressage d'une RAM du Line Buffer pour y écrire des pixels, ce signal active l'entrée EP : le compteur ne comptera que lorsque cette entrée est à un. Quand on lit la RAM, c'est l'horloge pixel qui est appliqué.
Je voulais donc observer ce signal SIZENBL qui arrive depuis la partie « Size Clock Rate Generator » et qui passe par le multiplexeur 74LS158 en 8E : est-il différent selon qu'on adresse une ligne paire ou une ligne impaire ?
Bof, je n'ai rien vu de flagrant : je trouvais que les signaux se ressemblent, qu'on soit sur une ligne paire ou impaire. Encore une piste qui s'envole pensai-je !... Mais c'est seulement maintenant, en rédigeant ce compte-rendu que je m'aperçois que j'ai relevé les signaux du multiplexeur situé en 8D au lieu du 8E : quelle buse je suis, pas étonnant que je ne voyais rien d'anormal!...
J'ai aussi observé les signaux POSI0 à POSI9 qui servent au chargement de la coordonnée,
mais je n'ai pas vu de différence notable entre le traitement d'une ligne paire ou impaire
.
À ce stade, on commence à se poser des tas de questions, plus ou moins logiques ou cartésiennes !
Les composants TTL de la famille S sont très rapides, mais aussi très gourmands en énergie : le découplage de leur alimentation est-il parfait ? Du coup j'ai remplacé tous les condensateurs de découplage électrochimiques à proximité => sans effet.
Quatre des six compteurs 74S161 sont sur support, mis en place par un exploitant : les supports sont vieux, ne se seraient-ils pas oxydés ? Nettoyés, un coup de bombe contact => sans effet !
Il reste 2 compteurs qui ne sont pas sur support : allez hop, je les dessoude, les teste et les mets sur support => sans effet. Tant que j'y suis, je dessoude les 4 anciens supports et les remplace par des neufs :
Toujours sans effet !
Une autre partie du bug qui m'intriguait était le fait que certains morceaux de sprite étaient manquants : en haut à gauche du portique ou de certains panneaux. Mais surtout tout le centre des voitures en gros plan. J'ai du coup essayé de remplacer une à une les EPROMS contenant les briques des sprites en prenant celles d'un autre PCB => sans effet
.
Et j'ai certainement fait encore une dizaines d'autres trucs dont je ne me souviens plus !
Le matin je pensais avoir observé les signaux du 74LS158 en 8E, et plus particulièrement le SIZENBL : les observations n'avaient pas été probantes, mais au point ou j'en étais, je pouvais toujours dessouder ce composant et le tester avec mon VP-280 :
Hey ! Donné comme mauvais !! Serait-ce lui le coupable ??
Je soude un support, et mets à la place un 74LS158 neuf :
Nouveau test et...
Bingo ! C'était ça !
L'analyseur logique c'est bien, mais surtout quand on regarde les signaux sur le bon composant
!
Par curiosité, j'ai à nouveau observé les signaux avec le circuit en bon état de fonctionnement :
et voici ceux que j'ai aussi re-mesuré après coup, avec le composant défectueux :
en zoomant un peu :
Mouais... à présent que je sais que mon observation initiale était fausse, il faudrait que j'épluche à nouveau les chronogrammes à tête reposée !...
Je n'ai donc pas tout compris sur l'impact qu'avait se composant défectueux, notamment les blocs de sprite qui avaient disparu de façon parfaitement reproductible sont tous revenus !
Quoiqu'il en soit, vous pouvez me croire, je suis bien content d'être venu à bout de ce bug ! J'espère qu'un nouveau circuit ne va pas avoir envie de passer l'arme à gauche sitôt j'aurai remis le pcb dans la borne !
Merci de m'avoir lu jusqu'au bout
.
A+
