SEGA Gee Bee

[maldoror68]

précis. éfficace. über-geek. j'aime et j'en redemande 

[gc339]

Bonjour.

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 :

Deux standards se sont affrontées à l'époque où l'EPROM 4K × 8 est sortie :

• L'Intel avec la configuration 2732.
• Texas Instruments avec la configuration 2532.

Par la suite les boîtiers sont passés de 24 à 28 puis 32 ... broches pour les mémoires de taille supérieure, nombre de fils d'adresses oblige. La compatibilité avec le standard Intel l'a emporté bien que TI ait sorti une 2564 dont les broches A0 à A11 avaient la même disposition que la 2532.

Hitachi (HN462532) et motorola (MCM2532) ont aussi fabriqué des 2532.

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

[Iro]

Superbe comme d'hab.
C'est un rêve de pouvoir dépanner de l'électronique aussi facilement.

[kidicarus]

Impressionné une fois de plus ! bravo

[HerosSuperMan]

En attendant de trouver une solution pour la pisse de chat, je me suis penché sur le PCB.

oui tu as raison , il faut commencer par le plus facile 

mais toujours so impressive 
A comparer de ça, je suis un simple laveur de voiture avec mon wip 

[f4brice]

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 !

[philougames]

Salut F4brice, <:)Je suis sans voie ,
Impressionnant le travail que tu fais,tu y consacre un temps fou ,beaucoup d'énergie , respect
je croie que tu vas finir réparateur de pcb  =:))pour gamoover

[f4brice]

Je suis sans voie ,

En voici une :

je croie que tu vas finir réparateur de pcb  =:))pour gamoover

Je ne crois pas. 

[Wapata]

Mouais...
Mouais mouais mouais.
...
C'est du déjà vu tout ça !

(pfiouu la claque à chaque lecture ! )

[maldoror68]

j'ai toujours l'impression que f4b nous met une pile a distance rien qu'avec ses connaissances en électro.
je suis bluffé

[speedsterharry]

Je ne crois pas. 

C'est plus que tu as envie de garder ton temps libre pour toi ou que les PCBs type CPS2/MVS sont trop complexes à réparer ?

Le jour ou quelqu'un pourra faire quelque chose des CPS3 morts, il aura du boulot !

[pn_jeux]

Salut!  Impressionnant! Voilà plusieurs articles que je suis où tu fais revivre ces anciens jeux n/b (avec des bandes de couleurs collées sur l'écran, qui donne un effet bluffant). Incroyable aussi les prouesses des concepteurs pour pouvoir exploiter les modestes cpu's d'époque (Compteurs rapides, registres à décalage...) pour pouvoir générer un signal vidéo. J'ai moi-même dépanné quelques space-invaders avec le fameux "barrel-shifter" pour les mouvements des ennemis. Il faut avouer que trouver un bug d'usure sur ces "usines à gaz" n'est vraiment pas un cadeau...

[philougames]

En voici une :

A oui en plus elle est belle 

Je ne crois pas. 

c'était pour rire  mais j'avoue que ça me plairai de pouvoir en faire autant ,
Aller a 30e de l'heure ,ça vaudrais le coup pour toi  15heures sur une pcb a 50e ,ça lui ferais prendre une sacré cote argus 
Bon j'arrête de dire des conneries moi ,

[HerosSuperMan]

 
pfff toujours aussi impressionnant


bon c'est pas tout ça mais et la pisse de chat ??hein ?? va falloir y penser 

[BadGuigui]

Oui comme tout le monde j'apprécie toujours autant tes WIP car très précis dans ta méthodologie et ca finit tout le temps bien !!! 

Et bonne chance pour la pisse de chat !

[Bal]

pour la pisse de chat, pas de soucis, un p'tit tour chez HG...

Sinon, de la javel à vaporiser direct, mais ca risque de piquer les yeux...