[WIVSP] Space Invaders upright, Midway 1978

[Little_Rabbit]

Salut,

Ouf ! Merci Spectro d'avoir confirmé mon diagnostique , et me revoilà en deuxième semaine à « Qui veut gagner une SI fonctionnelle ? »

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.



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'abord
On 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



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



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 shifter

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


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



Imaginez un gros switch Peritel qui vous permettrait de choisir entre 8 sources pour n'en sortir qu'une vers le téléviseur . 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, I0 à I7, une sortie Q, et 3 broches de sélection S0 à S2. 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 :



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 à S0, S1 et S2 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 ? 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 .



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.



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 .

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



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 !



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 :





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 !

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 !



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 :



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 :



Puis sur ça !



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



Je mets sous tension pour une Nième fois, et... le test du shifter est cette fois bon ! 



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 :



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+

[olschool]

Passionnant !!!!

je comprend une phrase sur 10

et encore je me vante en fait c'est une sur 20 


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

[Fred G5]

Jolie, pas simple du tout ce genre de panne 

[rygar]

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 

[Fred G5]

Pour les CPU Bally corrodées j'ai fait un beau Tuto dans la section Flipper 

[rygar]

Oui, merci à toi 

http://www.gamoover.net/Forums/index.php?topic=37458.msg621586#msg621586

[Little_Rabbit]

Salut,

Merci pour vos commentaires !

Il y en a au moins deux que cela intéresse !

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 .



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.



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.



Le 260 me semble curieux ! En Googlant rapidement, je suite tombé sur ce site 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 :



Pour adresser 1 ko ; il faut 10 bits d'adresse (1024 = 2¹⁰). 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 A₁₀ (le 11ème puisque le premier est A₀ ) et A₁₁. Le 1er bug apparaît quand pour l'adresse $2800, A₁₁A₁₀ passent de 01 à 10. Mais le bug se répète quand en $3000 les bits A₁₁A₁₀ 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 A₈, A₉ et A₁₀. 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 A₈ 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.



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 A₈, A₉ et A₁₀ .

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 A₈, A₉ et A₁₀ en amont, au niveau du CPU et de ses buffers d'adresse.

Enquête à suivre une fois encore !

A+

[olschool]

Je me répète tant pis

PASSIONNANT

   

[maldoror68]

ça doit être le vin rouge mais vous m'avez perdu 

[f4brice]

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 !

[Maitre_Poulpi]

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  ), c'est super intéressant 

[spectroman]

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!

[rygar]

J'avais quasiment tout compris jusqu'à ce que Spectro intervienne ... 

[f4brice]

J'avais quasiment tout compris jusqu'à ce que Spectro intervienne ...  

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.

[rygar]

Merci d'avoir pris le temps de me répondre f4brice
Je vais me coucher un peu moins bête  
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    mais passionnant !!!! (comme dirait olschool)

La suite la suite !!! 

[Little_Rabbit]

Salut,

Merci à tous pour vos commentaires   !

Je me répète tant pis

PASSIONNANT

   

Merki !  

ça doit être le vin rouge mais vous m'avez perdu  

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

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 .

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+