Arrrrrrggggglllllllllllllllllllllllllllll....
La poisse a frappé :
![](http://img1.uplood.fr/free/t1hq_20090815_113144_4861_img.jpg)
Samedi matin, je me suis dis : "et si je faisais un partie de GTI Club, histoire de faire descendre mon record de 2'12 réalisé sans forcer ?".
J'allume le twin, et là c'est le drame...
Le PCB réparé il y a même pas 48h ne passe à nouveau plus le boot-check...
Le composant
26V est une puce de 256 kbits de SRAM classique : une Cypress CY7C199 en boîtier DIP28 étroit (= traversant, pas CMS).
Je l'ai changée samedi matin sur le champ (par 3 puces prélevées sur l'autre PCB), mais le problème persiste.
Soit les 3 puces prélevées sont toutes les 3 HS, soit le problème est autre.
Samedi après-midi et dimanche toute la journée, je n'étais pas chez moi, j'ai ruminé la panne tout le temps.
![Cry :'(](http://www.gamoover.net/Forums/Smileys/guntar/cry.gif)
J'ai procédé à quelques tests & investigations.
Lorsque le PCB démarre avec la puce
26V complètement retirée, le boot-check indique alors un problème avec les puces
36T et
36V.
Il faut interprêter ça comme un échec de communication entre le PowerPC et le DSP.
J'en déduis que le DSP n'a pas pu booter et donc que la puce 26V bien que vue
BAD par le PowerPC est quand même indispensable au DSP.
En fliquant les signaux importants (/CE, /OE, /WE) de la puce de RAM, ça passe dans tout une bordèlerie de circuits logiques 74CBT3383 "FET bus exchange switches".
Ces puces servent à permutter 2 bus logiques. Je n'ai pas trop compris en lisant la doc technique, mais je crois que ces "FET bus exchange switches" sont bi-directionnels.
Tout ce bin's serait totalement inutile si les puces de RAM étaient "dédiées" à un seul processeur et réservées à son usage exclusif.
À mon avis, les puces de RAM 25S, 25V, 26S et 26V constituent la zone de RAM partagée entre le PowerPC et le DSP, comme visible dans les sources du driver
gticlub.c de Mame :
static ADDRESS_MAP_START( gticlub_map, ADDRESS_SPACE_PROGRAM, 32 )
[...]
AM_RANGE(0x78000000, 0x7800ffff) AM_READWRITE(cgboard_dsp_shared_r_ppc, cgboard_dsp_shared_w_ppc)
[...]
ADDRESS_MAP_END
Chose non expliquée, il y a 4 puces de 256 kbits, soit 1024 kbits, soit
128 ko. Or dans les sources de Mame, la zone de RAM partagée fait 0x10000 octets, soit
64 ko.
Il y a plusieurs possibilités :
- je suis à coté de la plaque et les 4 puces ne sont pas cette RAM partagée (=> pourquoi le bordel de bus exchange ? Dans Mame, il n'y a aucune zone mémoire de 128 ko)
- la zone de RAM partagée est organisée en 16 bits et non pas 32 bits, et 2 des 4 puces réalisent la zone de RAM partagée vue dans le code source de Mame, les 2 autres servent à autre chose
- la zone de RAM fait physiquement 128 ko, mais le jeu n'en utilise que 64 ko
- les personnes qui ont travaillé sur le driver de Mame n'avaient pas tout à fait le même PCB que moi (plausible, car ils ont indiqué que les 4 puces sont en boîtier SOJ28 (un truc CMS) alors que moi ce sont des DIP28 (traversant)
J'ai l'impression que le DSP arrive à accéder à la puce de RAM 26V, mais pas le PowerPC (ou de manière imcomplète).
Je vais donc me taper le reverse-enginering en partant de la puce 26V et voir où ça mène.
La tâche est chiante : les pistes sont microscopiques et passent sans arrêt d'un coté et de l'autre du PCB.
Voici une photo du 2e PCB où j'ai prélevé 3 puces de RAM.
Il va me servir pour le reverse-engineering car je peux maintenant voir les pistes sous les composants retirés :
![](http://img1.uplood.fr/free/ezt7_20090817_091314_4863_img.jpg)