Salut,
@philougames : merci, ça fait toujours plaisir de savoir cela intéresse certaines personnes !
À présent que ma borne fonctionne depuis plusieurs mois, je voulais faire un petit bilan de ce dépannage
.
En ce qui concerne le PCB, ce WIP démarra en novembre 2015, pour s'étaler jusqu'en novembre 2018 ! Trois ans !...
Un WIP, c'est facile à démarrer, mais c'est autre chose de s'y tenir et aller jusqu'au bout
. Et c'est encore pire pour ce qui est de s'astreindre à rédiger son WIP et continuer à le partager avec la communauté !...
Bon, ce WIP a certes été très long (et n'est pas fini sur le plan cosmétique !), mais il faut dire que c'était le premier PCB auquel je m'attaquais véritablement avec persévérance, et puis les pannes étaient multiples !
Voyons l'étendu de ce qui était HS :
- le microprocesseur 8080
- 2 condensateurs tantale goutte en court-circuit (j'ai aussi remplacé pas mal d'autres condensateurs, dont tous ceux de la carte alimentation
)
- 8 RAM sur les 16 présentes
- 4 circuits TTL : le 7404 lié au RESET, le 9316 des tops de synchro vidéo, le 7400 lié au signal Sample, et le fameux 74S174 qui sert de Status Register et qui m'a donné tant de fil à retordre !
- 3 LM3900 sur la partie son
- Et 4 ROM sur les 5 présentes !
Parlons de ces ROM justement. Une fois que le PCB était dépanné et fonctionnait avec les EPROM 2716 programmées, j'étais curieux de voir si les ROM d'origine étaient bonne ou pas. D'autant que j'avais remarqué qu'il y en avait 5 et non 4 comme c'est normalement le cas sur un PCB Space Invaders ! S'agissait-il d'une version Deluxe ?
Comme j'avais déjà dessoudé/ressoudé plusieurs fois les « jumpers » qui permettent de changer la configuration entre ROM ou EPROM, cette zone du PCB commençait à être fragilisé. Ne voulant pas l'abîmer d'avantage, j'ai décidé d'ajouter un commutateur permettant facilement de passer instantanément de ROM à EPROM :
J'ai ensuite pu mettre en place les 5 ROM d'origine
.
Mise sous tension, et... rien !
Le PCB ne boote pas. Je voulais en savoir un peu plus, et était curieux de dumper ces ROM pour voir ce qu'elles pouvaient contenir. Mais mon programmateur ne les connaît pas, et leur brochage étant différent d'une EPROM, ce n'était pas possible directement. Du coup je me suis fabriqué un petit adaptateur. Les brochages sont très proches :
9316
A7 1 +-v-+ 24 Vcc
A6 2 | | 23 A8
A5 3 | | 22 A9
A4 4 | | 21 CS/
A3 5 | | 20 CS/
A2 6 | | 19 A10
A1 7 | | 18 CS
A0 8 | | 17 D7
D0 9 | | 16 D6
D1 10 | | 15 D5
D2 11 | | 14 D4
GND 12 +---+ 13 D3
2716
A7 1 +-v-+ 24 Vcc
A6 2 | | 23 A8
A5 3 | | 22 A9
A4 4 | | 21 Vpp
A3 5 | | 20 OE/
A2 6 | | 19 A10
A1 7 | | 18 CE/
A0 8 | | 17 D7
D0 9 | | 16 D6
D1 10 | | 15 D5
D2 11 | | 14 D4
GND 12 +---+ 13 D3
-------------------------------------------------------------------
Broche | 9316 | 2716 | Câblage sur PCB Midway
--------+--------+--------+----------------------------------------
18 | CS/ | CE/ | Chip Select du boîtier
--------+--------+--------+----------------------------------------
20 | CS/ | OE/ | Toujours à la masse
--------+--------+--------+----------------------------------------
21 | CS/ | Vpp | +5V pour EPROM, à la masse pour 9316
-------------------------------------------------------------------
|
Pour lire une 9316 sur un programmateur réglé sur le type 2716, il suffit donc de détourner la broche 21 vers la 20
Ainsi j'ai pu tenter de dumper mes 5 ROM « mystère ».
Résultat :
- ROM D => HS !
- ROM E => HS !
- ROM F => dumpée
- ROM G => HS !
- ROM H => HS !
Sur les 5 ROM, 4 s'avéraient mortes
...
Mon fichier binaire de la ROM F allait-il tout de même m'en apprendre un peu plus et révéler le mystère ? Bah même pas ! La ROM F s'avéra tout à fait identique à la ROM F d'un Space Invaders de base ! Mais pourquoi y avait-il 5 ROM au lieu de 4 ? Je ne le saurai peut-être jamais
. Si vous avez un PCB Space Invaders à 5 ROM, je suis curieux de savoir ce qu'elles contiennent !
Et pour l'anecdote, dernier point que je voulais approfondir : le programme de test corrigé par f4brice et surtout grandement amélioré par spectroman. Vous savez combien ce programme fût précieux, et je les remercie encore une fois pour leur superbe travail !
Souvenez-vous, j'ai terriblement galéré autour du dépannage des RAM :
- j'en avais 8 de défectueuses sur les 16
- sur les 24 RAM soit disant NOS achetées sur Ebay, 17 s'avérèrent HS !
- et ce satané Status Register en panne qui venait parasiter le bus de donnée pour certaines combinaisons de A8, A9 et A10 me fit longtemps douter de la viabilité des RAM installées
Ces difficultés m'ont fait exécuter un paquet de fois le programme de test. Et comme je faisais cela avec mon banc test et non dans la borne, j'avais la possibilité d'appuyer sur mon bouton RESET pour exécuter encore et encore ce programme, sans éteindre et rallumer l'ensemble. Mais curieusement, j'avais remarqué qu'après un RESET, une bonne moitié des RAM étaient presque toujours détectée comme mauvaises
. Tant que le PCB était en panne, on pouvait trouver cela normal, mais une fois apparemment fonctionnel, un RESET du programme de test provoquait toujours la détection de RAM défectueuses !
Du coup je me suis penché sur la routine de test dont je vous livre le début :
;---------------------------------------
; First RAM test
;---------------------------------------
ramtest:: mvi d,0x00 ; clear the error register
mvi c,0x03 ; We'll do the ram tests three times - keep track in c
;---------------------------------------
;Store #0x55 in all memory 0x2000 - 0x4000
;---------------------------------------
ramtest1: mvi b,0x55
lxi h,0x2000
rmtst1: mov m,b
inx h
mov a,h
cpi 0x40
jnz rmtst1
;---------------------------------------
;Check each stored value 0x2000 - 0x4000
;---------------------------------------
lxi h,0x2000
rmtst2: mov a,m
xri 0x55
jz rmtst2_cont ; no error, test next byte
mov b,a ; save A in B
mov a,l ; YES- load L into A
rrc
jc rmtst2_bad_odd
mov a, e
ora b
mov e, a
jmp rmtst2_cont
rmtst2_bad_odd:
mov a, d
ora b
mov d, a
rmtst2_cont:
inx h
mov a,h
cpi 0x40
jnz rmtst2
...
Comme je n'avais pas écrit cette routine, il me fallait comprendre pas à pas ce qu'elle faisait. Je comprends que les registres D et E de huit bits chacun, qui forment le registre 16 bits DE sont utilisés pour stocker les n° de RAM détectées comme mauvaises. OK.
Mais à la 1ère lecture un truc m'interpella : la ligne de code suivante remettait bien à 0 le registre D avant de commencer le test :
;---------------------------------------
; First RAM test
;---------------------------------------
ramtest:: mvi d,0x00 ; clear the error register
mais je ne trouvais pas trace d'initialisation du registre E ! Serait-ce aussi simple ? J'ai remplacé cette première instruction par la suivante :
;---------------------------------------
; First RAM test
;---------------------------------------
ramtest:: lxi de,0x0000 ; clear the error register
cette fois, c'est la paire de registres DE qui est mise à zero. J'assemble le code, le « link » et programme une nouvelle EPROM. Je test sur mon PCB, et... ça marche !
Même après un RESET, toutes les RAM sont bien détectées comme bonnes !
On peut en conclure qu'un microprocesseur 8080 remet à 0 tous ces registres à 0 à la mise sous tension, mais que ce n'est pas le cas après un RESET ! Voilà pourquoi cela fonctionnait la première fois, mais pas les suivantes en cas de RESET
.
J'ai donc corrigé ce petit bug dans la routine de spectroman, et il existe à présent une version 1.3 de la ROM de test qui fonctionne dans toutes les circonstances
.
Ça c'était en novembre 2018, et je viens de constater que le gars qui héberge la ROM de test et les sources a déjà une autre version 1.3 faite par un Canadien en mars 2019 ! Merde, moi qui pensais passer à la postérité en matière de restauration d'arcade avec mon débuggage, me suis fait griller par un Québécois
.
Les leçons que je retirerai de ce dépannage :
- être persévérant, même si les impasses dans lesquelles on se trouve parfois sont décourageantes
- ne pas toujours se focaliser sur la recherche d'un composant coupable, parfois ce peut être une piste coupée ou abîmée
- ouvrir les yeux ET les oreilles : le son fourni par un PCB peut aussi être source d'indices qui mèneront à la résolution de la panne
Comme le disait si bien La Fontaine, "Patience et longueur de temps font plus que force ni que rage"
!
A+
