Bonsoir.
Puisque le pignolage est de rigueur il vaudrait mieux remplacer la verrue avec l'EPROM 2732 par une EPROM 2532 qui devrait être compatible broche à broche avec la ROM 2332
Le problème, c'est que la 2532 semble ne pas avoir de broche « /OE ».
Elle n'a qu'une broche « /CS ».
Or, sur le PCB Gee Bee, les 2 broches /CS et /OE sont utilisées :
- /CS est pilotée par le décodage d'adresse (un simple 74LS42)
- /OE est pilotée par le CPU 8080, signal « DBIN » inversé (Data Bus Input, qui indique que le CPU a passé son bus de données en entrée)
L'utilisation d'une 2532 était bien séduisante car elle réduisait l'aspect verrue de la 2732, malheureusement ça ne peut pas se faire sans l'ajout d'un composant 74LS32 pour piloter l'unique /CS.
L'intérêt s'en trouve donc réduit. Dommage car ça me plaisait bien.
N'y a t-il pas des TMS2532 ou des HN462532 dans le lot d'EPROM's que tu as récupéré quand tu es passé à la maison ? Sinon je peux t'en fournir quelques exemplaires ...
Il n'y en avait pas, mais je suis sûr d'en avoir probablement quelques unes dans mon stock de PCB donneurs d'organes !
Voici la suite de ce WIP.
La dernière fois, j'avais la balle, le décor, mais un comportement complètement aléatoire du jeu...
Après de multiples investigations à l'oscillo, je n'ai rien trouvé d'anormal.
Tout semble fonctionner, sauf que le PCB déconne quand même...
J'ai galéré longtemps à comprendre comment je pouvais avoir sur tous les bits du bus de données du CPU un niveau TTL foireux (environ 2,5 V).
Je pensais vraiment que le problème était là.
Finalement, malgré le fait de ne pas posséder d'analyseur logique, et en utilisant mon oscillo au maximum de ses capacités (déclenchement externe), j'ai fini par comprendre ce qui se passait...
Le CPU 8080 est prévu pour causer à des composants particulièrement lents.
Du coup, quand il doit lire une donnée, il passe dans un état d'attente jusqu'à ce qu'on vienne le secouer pour lui dire que c'est prêt.
Ce signal "ayé c'est prêt" est généré à partir des signaux du compteur de scanline et du compteur de pixels.
Entre le moment où le CPU a demandé une lecture et le moment où le signal "ayé c'est prêt" est actif, il y a un boîtier de ROM sélectionné, mais son bus de données est toujours inactif.
A ce moment là, aucun boîtier n'a le contôle du bus de données, donc il converge vers un état TTL intermédiaire...
J'ai passé du temps à découvrir et à comprendre ce que j'observais pour finalement conclure que le problème n'est pas là...
Il ne reste plus qu'un élement que je n'ai pas pu tester correctement : la RAM à disposition du CPU pour les besoins du jeu.
Je dessoude donc les 2 boîtiers de RAM. Ce sont des RAM référence "2111" :
2 composants de RAM : 256 × 4 bits, soit 128 octets par composant (whouaaaaa !)
J'utilise mon couteau suisse TTL avec un petit programme de mon crû pour tester chacun de ces composants :
Boîtier d'entrées/sorties à usage général
Mon programme de test contrôle tous les signaux nécessaires pour écrire et relire n'importe quoi n'importe où dans le composant.
L'idée, c'est d'écrire des données, de les relire et de comparer avec ce qu'on avait écrit.
Il y a une stratégie à observer pour savoir quelle donnée est à écrire où, pour détecter certains problèmes sioux.
Voir
ce message de GC339.
Dans un 1er temps, je n'ai implémenté que 6 tests :
- écriture de 0x0
- écriture de 0xF
- écriture alternée de 0x0 puis de 0xF
- 1 baladeur
- 0 baladeur
- pattern de 7 données aléatoires
Là, je dois dire que ce fut tellement la fête du slip avec ces composants de RAM que j'étais persuadé d'avoir foiré un truc dans la procédure électronique pour écrire une donnée dans le composant.
Pourtant, j'ai récupéré la doc technique et il me semblait avoir respecté exactement la cinématique requise...
En gros, tous les tests révélaient de gros problèmes un peu partout dans le composant...
A tel point que j'ai réalisé vite fait un petit système de stats qui indique pour chaque adresse mémoire le nombre de tests en échec.
Si par miracle aucun test n'est en échec, il n'est pas affiché "0" mais la cellule reste vide pour que ce soit bien visuel...
Voici ce que j'obtiens pour les 2 composants :
Sur le 1er composant, il n'y a qu'une et une seule adresse (sur les 256 possibles) où la donnée relue correspondait à chaque fois à la donnée écrite.
Sur le 2e composant, il y a 100% des adresses mémoire qui ont foiré au moins 1 test sur les 6...
J'vous dit, c'était tellement le foirage total que j'ai cru que ma procédure d'écriture n'était pas correcte...
Je décide donc de tenter une greffe temporaire de nouveaux composants de RAM au moins pour tester.
Le hic, c'est que je n'ai aucun composant 2111 en stock, ni même vampirisable sur mes PCB donneurs d'organe.
La plus proche en stock, c'est de la 2114 ou 2148 mais elle n'a pas de broche /OE qui est nécessaire, et je n'ai pas envie de me faire iéch avec un 74LS32...
Bon, on va faire le gros sac bourrin.
J'ai de la "M58725P" (2048 × 8 bits) qui va faire l'affaire. Un seul de ces boîtier va me remplacer les 2 boîtiers 2111...
Go !
Moche, temporaire mais devrait fonctionner...
Sur la photo précédente, vous avez l'illustration de ce que donne du travail fait sans réfléchir...
Juste à coté des RAM, il y avait des emplacements pour des boîtiers d'EPROM 2708.
Ces emplacements, à quelques broches près, auraient pu parfaitement acceuillir mon composant de RAM et m'éviter de souder tous ces petits fils...
Bien évidemment, je m'en suis rendu compte
après avoir fini !
Il est temps de tester le PCB...
Juste pour vérifier mon outil de test de RAM, je l'ai relancé pour tester le nouveau composant que j'ai installé :
Lui, il a l'air en bonne santé et ma procédure d'éciture dans la RAM semble bonne...
A suivre : test du PCB dans la borne !
