Salut,
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 !
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
). 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 :
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).
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.
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
!
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 :
Résultat : rien, le bug est toujours présent !
Mon deuxième suspect se situait au niveau des buffers de bus d'adresse.
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...
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.
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+
