[WIP] Midway Gun Fight (1975)

[f4brice]

En tout cas, le résultat que tu montres en photo est super propre. Y a bien une raison pour que le budget soit plus élevé 

Après avoir dessoudé un composant, je nettoie toujours le reste d'étain avec de la tresse puis je finis en nettoyant le PCB avec de l'alcool à brûler pour enlever certains restes de décapant.
Ainsi le champ opératoire est très propre.

Mais il arrive aussi à ce modèle de se boucher

Il arrive aussi que mon Hakko se bouche, mais ça reste rare.
Je ne suis pas aussi téméraire que toi pour oser tenter de le déboucher avec un foret.
J'utilise une queue de résistance, la plus petite possible en diamètre.
J'appuie sur le bouton d'aspiration et j'insère la queue (de la résistance, hein) dans le trou (du pistolet à dessouder, je précise).
Ça se débouche en 2 à 3 secondes.
L'aiguille fournie avec le pistolet est à mon avis trop grosse. Je n'ai jamais réussi à déboucher le pistolet avec elle.

[Little_Rabbit]

Re,

../.. et j'insère la queue (de la résistance, hein) dans le trou (du pistolet à dessouder, je précise).

../.. est à mon avis trop grosse. Je n'ai jamais réussi à déboucher le pistolet avec elle.

Ah c'est vrai, il y a ceux/celles qui les aiment plutôt grosses, et d'autres plus fines !... Il en faut pour tout les goûts !



Je 

A+

[f4brice]

Ta correction :
[couic]

En fait, c'est la correction de Marc Deslauriers, pas la mienne !
C'est lui qui est à l'origine de la version 1.3.

mais il faut croire que certaines spécimens de 8080 ont leur registre DE déjà à 0 car je t'assure que chez moi c'était le cas !

Mais mon brave monsieur, c'était le cas aussi chez moi, lors de ma précédente réparation d'un PCB Midway à base de 8080 (un Space Invaders) ! 

[f4brice]

Bonjour.

Voici la suite de ce dépannage de PCB Gun Fight.
La dernière fois, j'avais réparé la partie RAM du PCB en utilisant une ROM de test en version 1.3 et en changeant l'unique chip de RAM vu kaput.
Le test de RAM étant OK, je peux enchainer avec la répartion du shifter hardware.
La Spectro-ROM de test indiquait des résultats bien moisis.

Voyons en détail ces résultats :

Quand on a l'habitude de manipuler les nombres hexadécimaux, on voit très vite que la valeur 0x40 est omni-présente dans ce résultat.
Une ligne particulièrement intéressante est l'avant-dernière ligne.
Pour cette ligne, la ROM de test demande au shifter hardware de décaler la valeur 0x00, donc normalement le résultat doit systématiquement être 0x00.
Or le test indique que le résultat est toujours 0x40.
C'est vraiment le signe que le bit #6 du résultat lu par le CPU est scotché à 1 au lieu de 0.

Normalement, ce n'est pas une panne très dure à résoudre.
Voici la partie du schéma concerné :

Le bit #6 du résultat calculé par le shifter hardware (rouge) est issu soit du chip A3 ou A5 selon nombre de bits à décaler.
Les chips utilisés sont des AMD AM25S10. Iils ne savent faire que des décalages compris entre 0 et 3 bits.
Pour un décalage de 0 à 3 bits, on utilise le résultat de 2 chips sur les 4 présents.
Quand le décalage est entre 4 et 7 bits, on utilise les 2 autres chips dont les entrées sont câblées différemment.

Ce bit #6 calculé par le shifter arrive sur le chip D3. C'est un multiplexeur 4 entrées / 1 sortie.
Selon le port lu, le CPU obtient sur son bit #6 l'une des 4 entrées :

• le signal /LG3 (panel)
• le signal /RG3 (panel aussi)
• le signal /COIN (monnayeur)
• le bit #6 du résultat du décalage calculé par le shifter

C'est lui qui nous intéresse.
Quand le port 0x03 est lu, les entrées de sélection du multiplexeur (signal A jaune et B cyan) sont tous les deux à 1, et c'est le bit #6 du shifter qui est envoyé au CPU.
Ce signal passe à travers une porte non-inverseuse du chip C3.
Ce chip C3 a des sorties en collecteur ouvert qui tolèrent jusqu'à 15V.
Sur la partie CPU du PCB, il y a bien des résistances de pull-up.

Je modifie la ROM de test pour qu'elle réalise un décalage de 0 bits de la valeur 0x00.
Je devrais avoir 0x00 mais je sais que le CPU lit 0x40. Je veux voir à quel endroit le bit #6 "0" se change anormalement en "1".
En boucle infinie, mon programme modifié lit la valeur du shifter.
Çà va me permettre de mieux utiliser l'oscillo pour investiguer sur ce bit.

Déjà, je vérifie que tous les latches A6, B6, C6 et D6 ont bien tous leurs sorties à 0 puisque c'est cette valeur qui doit être shiftée.
C'est bien le cas, donc à priori aucun de ces 4 chips n'est en cause.
Ensuite je m'intéresse au multiplexeur D3. C'est lui qui aiguille le bit #6 calculé par le shifter vers le CPU.
Voilà la mesure à l'oscillo :

Les couleurs de l'oscillo sont celles du schéma plus haut.
Le bit #6 du résultat du shifter (rouge) est bien à 0 comme attendu. Jusque là tout va bien.
La sortie du multiplexeur (magenta) est elle aussi à 0.
Par contre, la sortie de la porte à collecteur ouvert (vert) du chip en C3 est foireuse.
Au lieu d'avoir une valeur proche de 0.0V, je mesure une valeur à environ 1,5V qui est interprétée comme un "1".
Son transistor de sortie est sûrement fatigué, et n'arrive plus à vaincre la pull-up de 470 Ω présente sur la CPU board.
C'est là la panne que je cherche.

Je dessoude le chip en C3 (un 7417) (désolé, j'ai oublié de faire la photo) et je le teste :

Il est effectivement kaput.
Notez que le testeur dit que la pin #10 devrait être "L" mais qu'il la mesure à "H".
C'est bien ça que j'ai observé à l'oscillo.

Je teste son remplaçant :

Vu qu'il est OK, il est rapidement soudé, toujours sans support :

Plutôt que de relancer ma ROM de test modifiée, je remets la Spectro-ROM de test non modifiée et je la laisse réaliser son test de shifter :

C'est tip-top, le bit #6 n'est maintenant plus scotché à 1 comme avant.
Un premier problème a bien été résolu.

Reste que le résultat du test n'est toujours pas OK ; il devrait y avoir des "00" partout.
Il reste donc un ou plusieurs problèmes avec le shifter hardware.
D'ailleurs, si on regarde bien, on observe un pattern assez flagrant !

À suivre : suite du dépannage du shifter hardware

[Maitre_Poulpi]

Punaise je suis surpris, je crois que j'ai presque tout compris.
Faut dire aussi que c'est super bien expliqué 

[Little_Rabbit]

Salut,

Le résultat qu tu obtiens durant le test du shifter est surprenant je trouve : c'est exactement la série de valeurs que le test s'attend à trouver !

Pour que nos lecteurs comprennent mieux, je me permets de citer ce que Spectro disait à propos de sa routine de test :

Pour l'analyse de la matrice, n'oublie pas que j'ai fais des modifications sur la dernière version de la rom de test.

La matrice des résultats attendus est celle ci :
01 02 04 08 10 20 40 80
02 04 08 10 20 40 80 01
04 08 10 20 40 80 01 02
08 10 20 40 80 01 02 04
10 20 40 80 01 02 04 08
20 40 80 01 02 04 08 10
40 80 01 02 04 08 10 20
80 01 02 04 08 10 20 40
00 00 00 00 00 00 00 00
FF FE FC F8 F0 E0 C0 80

et le programme affiche le XOR entre cette dernière et celle renvoyée par les registres à décalage.

Et je me permets également de rappeler à nos fidèles lecteurs ce que fait une fonction XOR (ou exclusif) :

Rappelons la table de vérité d'un OU Exclusif (XOR) :



Le truc à retenir, c'est que 1 XOR 1 = 0 => donc si ce qu'on lit après le décalage est identique à ce qui est attendu, le résultat sera 0 !

Exemple :

    00000100   
XOR 00000100
    ________
=  00000000

Or, comme les valeurs affichée par le test sont exactement celles attendues, j'en conclurais qu'en sortie de shifter, tous les bits sont à 0 !

Je verrais 3 causes possibles :
- soit les 25S10 sont morts
- soit ce qu'on leur donne à décaler/multiplexer vaut toujours 0, auquel cas ce sont les latches 74175 qui sont morts
- soit les valeurs fournies par les 25S10 ne parviennent pas jusqu'au bus de donnée, auquel cas ce serait les multiplexeurs 74LS153 qui seraient défaillants...

Je dis ça en ayant regardé le schéma un peu en diagonale, je l'avais détaillé en 2017 mais c'est un peu loin (et celui que j'avais sur ma Si était la version alternative à base de 74151, un multiplexeur 8 sources vers 1, à la place des 25S10 qui sont des registres à décalage de 4 bits) .

A+

[f4brice]

Bonjour.

Voici la suite de ce dépannage de PCB Gun Fight.
La dernière fois, j'avais réparé le bit #6 en sortie du shifter qui était scotché à 1.
Le nouveau résultat des tests montrait bien que la valeur 0x40 avait disparue.
Néanmoins, le shifter est toujours détecté KO par la Spectro-ROM de test.

Si on regarde le résultat des tests :

Il y a un pattern bien particulier.
Comme l'a judicieusement remarqué Petit_Lapinou, ce sont là exactement toutes les valeurs théoriques que le shifter aurait dû calculer !?
Mais comme est-ce possible que la Spectro-ROM de test affiche les valeurs théoriques et non pas les valeurs réelles ?
En fait, ce sont bel et bien les valeurs réellement lues en sortie du shifter.
La ROM de test, pour aider au diagnostic, indique les bits en erreur mesurés en sortie du shifter.
Elle utilise pour ça un banal XOR (ou exclusif) entre la valeur attendue et la valeur mesurée.

• tout bit identique entre la valeur attendue et la valeur mesurée sera ainsi affiché à 0
• tout bit différent entre la valeur attendue et la valeur mesurée sera ainsi affiché à 1

Petit_Lapinou a tout a fait expliqué plus haut le fonctionnement du XOR.

Sachant que "TRUC XOR 0x00" est toujours égal à "TRUC", la conclusion, c'est que systématiquement, quelque soit la valeur à décaler et le nombre de bits de décalage à réaliser, le résultat du shifter est toujours 0x00 !
Ourgl. Ça craint du boudin.
Ça veut dire qu'il ne calcule rien du tout, quelque soit la valeur à shifter et le nombre de bits ! C'est la grève totale et illimitée.
Les causes sont multiples, et pas que salariales. On va aller jeter un coup d'œil avec l'oscilloscope.

Pour ne pas me battre contre des moulins à vent, je modifie une fois de plus la ROM de test pour lui faire latcher en boucle infinie une demande de décalage de 7 bits :

L'idée, c'est de synchroniser l'oscillo sur la pin #9 du latch et de regarder ce qui rentre (pins #4, #12 et #13) versus ce qui a été latché (pins #2, #10, #15 et accessoirement aussi la #14).
J'ai fait 3 mesures, en observant à chaque fois ce qui rentre (cyan) versus ce qui sort (magenta)...

Bon, c'est sans appel, le latch ne latche absolument pas.
Normalement, sur le front montant du signal jaune, le signal magenta devrait prendre la valeur du signal cyan.
Là, ce n'est jamais le cas.
Ce qui est quand même bizarre, c'est que les 3 bits serait tous les 3 en même temps kaput !?
Il faut regarder le datasheet du 74175 :

La première ligne est intéressante.
Le chip dispose d'une pin "/CLEAR" (la #1) qui, quand elle est active (niveau "L"), force la sortie à 0 et ce quelque soit la clock et les entrées.
On dirait bien que c'est notre symptôme.
Pourtant, sur le schéma Midway, la pin #1 est reliée à une résistance de pull-up, donc à l'état "H" en permanence :

Je fais la mesure :

En effet, il y a bien un problème : le signal /CLEAR (en vert sur ma mesure ci-dessus) est à 0.
Donc le latch est en permanence effacé et les entrées jamais recopiées sur les sorties.

C'est extrêmement rare, mais peut-être que j'ai la résistance de pull-up qui serait cassée ?
Je ne sais pas exactement où est située cette résistance sur le PCB, mais voyant ça...

... je ne serais pas surpris d'avoir ce genre de problème... 

Je décide donc de regarder de près où va la petite piste en cuivre qui part de la pin #1 du latch en E6.
Je veux trouver ladite résistance de pull-up et lui parler de retraite anticipée.
Finalement, j'ai une grosse surprise :

Le latch E6 est le chip entouré en jaune.
La piste qui démarre de la pin #1 (rouge) part vers la gauche et arrive sur le chip en H6, pin #8 (entouré en orange).
C'est la sortie d'une porte inverseuse du chip en H6 (un 7404).
Quand on regarde l'entrée de cette porte (pin #9 en magenta), ça passe via le gros connecteur noir et ensuite ça va :

• à la pin #10 du "power connector", le connecteur d'alim
• et aussi à la pin #12 du CPU (RESET).

Je retrouve bien ça sur le schéma de la partie CPU :

Donc en réalité, le signal RESET issu de l'alim va aussi effacer tous les latches impliqués dans le shifter hardware + compteur de crédit + audio :

Je pense que Midway a dû constater des problèmes avec ces latches qui pouvaient déconner lors de la mise sous tension, et un p'tit coup de reset au démarrage les motive à mieux bosser.
Mon PCB est sûrement d'une révision plus récente que le schéma.

Hum, hum, le "problème" de ce signal RESET se situe entre le sol et l'oscilloscope : c'est... moi qui le fabrique ! 
Je n'ai pas d'alim Midway, donc j'utilise une pull-down de 10kΩ, avec un bouton poussoir connecté au +5V :

Au repos, le signal RESET est à 0 grâce à ma pull-down.
Quand j'appuie sur le bouton poussoir, il est à 1.
Je mesure la valeur de mon signal RESET au repos, et il n'est pas à 0V. Il est approximativement à 2V (en vert ci-dessous) :

Ça ne semble pas gêner le CPU pour fonctionner, par contre la porte inverseuse du 7404 en H6, elle n'aime pas.
Ma résistance de 10kΩ est trop grande, et elle ne tire pas assez le signal vers 0.
Cette valeur est typique quand on utilise des 74LSxxx, mais là on est en technologie "pas LS".
Les chips tirent plus de courant sur leurs entrées.
D'ailleurs, Midway utilise des résistances de 470Ω !
Je remplace ma 10kΩ par une 1kΩ :

Je relance une mesure sur le latch en E6 :

C'est bon, il fonctionne correctement, maintenant que son /CLEAR n'est plus actif (signal vert ci-dessus) !

Je relance la Spectro-ROM de test non modifiée :

TADAAAAAAAAA !!!!
C'est nettement mieux !
Je n'ai plus que 2 cas précis où le shifter déconne.


À suivre : suite encore et encore du dépannage du shifter !

[Little_Rabbit]

Salut,

Bien vu le coup du signal RESET qui ne descend pas assez bas au repos ! 

Du coup, cela m'a fait me poser une question : pourquoi n'ai-je pas rencontré le même problème, alors que mon bouton RESET est de même nature ?

Je viens de vérifier mon harnais bricolé : ma résistance de pull-down est de 4,7 KΩ !

Peut-être que cette valeur deux fois plus petite suffit-elle à me sortir d'affaire !?...

Quant à la panne résiduelle, elle montre que cela ne se produit que lorsque le bit de poids faible D₀ est à 1...

Je commencerais par regarder du côté du latch en D6 : sa broche 10 passe-t-elle à 1 quand on lui présente un 1 en entrée sur la broche 12 ?

A+

[Little_Rabbit]

Salut,

La nuit portant conseil , j'ai réfléchi un peu plus à la panne résiduelle, et je me suis rendu compte que ce que je disais hier soir n'a pas de sens .

En effet, si le problème se situait au niveau du latch, la valeur erronée de D₀ se constaterait pour toutes les valeurs de décalage !

Or elle n'apparaît que lorsque D₀ vaut 1, et qu'on la décale d'un bit.

Non, le problème ne peut donc se situer qu'en aval des latches, et selon toute vraisemblance sur le 25S10 qui gère D₀...

J'ai examiné le schéma, mais je vous avoue que cette partie du shifter me fait faire un peu des nœuds dans la tête !...

Je vous mets la table de vérité du fameux 25S10, sachant qu'il y en a 4 interconnectés, cela réclame une gymnastique intellectuelle qui je crois n'est plus de mon âge ...



Je vais attendre l'analyse de F4brice, sans me risquer à un nouveau pronostique !

A+

[f4brice]

La nuit portant conseil , j'ai réfléchi un peu plus à la panne résiduelle, et je me suis rendu compte que ce que je disais hier soir n'a pas de sens .

En effet, si le problème se situait au niveau du latch, la valeur erronée de D₀ se constaterait pour toutes les valeurs de décalage !

Je confirme ! 

Non, le problème ne peut donc se situer qu'en aval des latches, et selon toute vraisemblance sur le 25S10 qui gère D₀...

Je confirme aussi ! 

J'ai examiné le schéma, mais je vous avoue que cette partie du shifter me fait faire un peu des nœuds dans la tête !...

Je détaillerai ça dans mon prochain message ! 

[f4brice]

Bonjour.

On continue le dépannage du shifter hardware de ce PCB Gun Fight.
La dernière fois, je n'avais plus que ces 2 cas en erreur :

Là, je vais m'attaquer à celui de la dernière ligne.
Il correspond au test suivant :

• valeur à décaler : 0xFF
• nombre de bits à décaler : 1
• valeur théorique attendue : 0xFE
• valeur lue par la ROM de test : 0xFE XOR 0x02 = 0xFC
  il d'agit du bit D1 calculé par le shifter qui est vu à 0 alors qu'il aurait dû être à 1
  ce bit D1 du shifter provient du bit D0 de la donnée à décaler, puisque le décalage est de 1 bit

Toujours pour bien synchroniser mon oscilloscope et éviter les problèmes lors de la mesure, je modifie la ROM de test :

Je fais décaler au shifter la valeur 0xFF d'1 seul bit, et je lis en boucle infinie le résultat.

Je commencerais par regarder du côté du latch en D6 : sa broche 10 passe-t-elle à 1 quand on lui présente un 1 en entrée sur la broche 12 ?

Je pense que oui, car la première valeur de la dernière ligne du test du shifter est bonne (décaler 0xFF de 0 bit).
Ca veut dire que le latch D6 propose bien sur ses 3 sorties des données à 1.
Mon regard se porte plutôt sur le shifter en B3...

Voyons comment fonctionne ce shifter et comment Midway les utilise.
Voilà un extrait de son datasheet :

Il dispose de 2 entrées S1·S0 qui lui indiquent le nombre de bits à décaler, soit de 0 à 3 bits.
Il dispose de 7 entrées I3·I2·I1·I0·I-1·I-2·I-3, et de 4 sorties Y3·Y2·Y1·Y0.
Quand on décale de 0 bit, on a Y3·Y2·Y1·Y0 = I3·I2·I1·I0.
Quand on décale de 1 bit, on a Y3·Y2·Y1·Y0 = I2·I1·I0·I-1.
Quand on décale de 2 bits, on a Y3·Y2·Y1·Y0 = I1·I0·I-1·I-2.
Quand on décale de 3 bits, on a Y3·Y2·Y1·Y0 = I0·I-1·I-2·I-3.

Vu qu'il ne calcule que 4 bits en sortie, ce shifter est utilisé par paire, chacun calculant 4 des 8 bits du résultat.
Ensuite, vu qu'il ne sait faire que 0/1/2/3 bits de décalage, Midway utilise 2 paires de 2 paires, soit 4 chips.
La première paire (B3 + A5) est utilisée pour des décalages de 0 à 3 bits, l'autre paire (B5 + A3) est utilisée pour les décalages de 4 à 7 bits.

Le shifter hardware de Midway est à cheval entre du 16 bits et du 8 bits.
On latche 2 valeurs de 8 bits, et on lit un résultat de 8 bits.
La valeur à décaler s'appelle "DS" (Data to Shift).
Elle s'écrit en binaire : DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Selon le décalage à appliquer on va lire :

Donnée en entrée :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Décalage de 0 bit :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Décalage de 1 bit :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
Décalage de 2 bits :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0
...	...
Décalage de 7 bits :	DSF·DSE·DSD·DSC·DSB·DSA·DS9·DS8·DS7·DS6·DS5·DS4·DS3·DS2·DS1·DS0

Le décalage "S" est écrit dans le latch en E6 lorsque le CPU écrit sur le port 0x02.
En sortie de E6, on a un mot de 3 bit qui est le décalage "S" en nombre de bits.
Ce décalage "S", en binaire s'écrit en 3 bits S = S2·S1·S0.
Quand on a de 0 à 3 bits à décaler, on a S = 0·S1·S0, soit un décalage de 0, 1, 2 ou 3 bits
Quand on a de 4 à 7 bits à décaler, on a S = 1·S1·S0, soit un décalage de 4 + 0, 4 + 1, 4 + 2 ou 4 + 3 bits.
Midway (Taito) utilise le bit S2 et son complément /S2 pour sélectionner soit la 1ère paire de shifter 2 × 4 bits, soit la 2e paire.

La 1ère paire est active quand S2 = 0. Les inputs de ces shifters sont directement les bits à décaler.
Ainsi le shifter en B3 qui calcule les 4 bits de poids faible reçoit sur ses entrées Y3·Y2·Y1·Y0 = DSB·DSA·DS9·DS8.
Son collègue en A5 qui calcule les 4 bits de poids fort reçoit sur ses entrées Y3·Y2·Y1·Y0 = DSF·DSE·DSD·DSC.
Chacun reçoit sur des entrées Y-1·Y-2·Y-3 les rangs immédiatement précédents.

La 2ème paire est active quand S2 = 1, soit /S2 = 0. Les inputs de ces shifters ne recoivent pas directement les bits à décaler, mais les bits déjà décalés de 4 rangs.
Ainsi le shifter en B5 qui calcule les 4 bits de poids faible reçoit sur ses entrées Y3·Y2·Y1·Y0 = DS7·DS6·DS5·DS4.
Comme ça, s'il doit décaler ses entrées de 0 bits, on a bien le résultat attendu : un décalage apparent de 4 bits.
Son collègue en A3 qui calcule les 4 bits de poids fort reçoit sur ses entrées Y3·Y2·Y1·Y0 = DSB·DSA·DS9·DS8.
Là ausssi, chacun reçoit sur des entrées Y-1·Y-2·Y-3 les rangs immédiatement précédents.

Voilà en résumé :

Nombre de bits à décaler :	de 0 à 3 bits	de 4 à 7 bits
Shifters impliqués :	B3 et A5	B5 et A3
Rôle de B3 :	calculer les 4 bits de poids faible du résultat	non impliqué ; sa pin /OE est à 1
Rôle de A5 :	calculer les 4 bits de fort faible du résultat	non impliqué ; sa pin /OE est à 1
Rôle de B5 :	non impliqué ; sa pin /OE est à 1	calculer les 4 bits de poids faible du résultat
Rôle de A3 :	non impliqué ; sa pin /OE est à 1	calculer les 4 bits de poids fort du résultat

Dans mon cas, j'ai un problème sur un décalage de 1 bit. Donc c'est B3 et A5 qui sont utilisés. B5 et A3 sont au repos.
Mon problème est sur le bit D1 du résultat, donc c'est B3 qui est suspect.

Pour mon test, je veux décaler 0xFF de 1 bit :

• S0 (jaune) = 1
• S1 (cyan) = 0
• DS8 = bit de poids faible de la dernière valeur latchée = 1 (magenta)
• décalage de 1 bit, donc il doit sortir sur Y1 (vert) que je dois mesurer à 1

Voici la mesure :

Désolé, j'ai oublié de faire une copie d'écran "propre" de l'oscillo. Il va falloir regarder sur la photo ci-dessus !

• en jaune, c'est le signal S0 envoyé au shifter ; il est bien à 1 car il faut décaler de 1 bit
• en cyan, c'est le signal S1 envoyé au shifter ; il est bien à 0 car il faut décaler de 1 bit
• non visible, mais vérifié : S2 = 0 car il daut décaler de 1 bit
• en magenta, c'est le bit DS8 envoyé au shifter en I0 ; il est bien à 1 car la valeur à shifter est 0xFF
• en vert, c'est la sortie Y1 du shifter, qui devrait être égale à I0 puisqu'on shift de 1 bit

Je constate que la sortie Y1 du shifter n'a pas la bonne valeur.
C'est bien le shifter en B3 qui est malade.

Pour le vérifier, je vais permuter B3 avec B5, et vérifier que le problème se déplace sur les décalages de 4 à 7 bits.

C'est parti, on dessoude tout le monde :

Pour une fois, je soude des supports tulipes et je remets en place les chips, en ayant pris soin de permuter B3 et B5 :

Je relance la Spectro-ROM de test :

Ouergllll....
Pas cool du tout, je suis revenu en arrière dans ma réparation. J'ai davantage de problèmes qu'avant...
Quand on regarde le problème, on se rend compte que le problème est lié au nibble de poids fort pour des décalages de 0 et 1 bit.
C'est lié à A5. Je vérifie... Hop, une soudure oubliée !!! Je répare...
Je relance le test :

Bon, c'est confirmé, le problème est bien lié à mon AM25S10 qui était en B3.
Il est un peu malade, pas complètement mort. Il doit partir en retraite.
Notez que je n'ai pas la 2e erreur que j'avais au début (dernière ligne).
C'est simplement que le résultat attendu a son bit D1 à 0, donc l'erreur est masquée.

Le problème, c'est que je n'ai pas de chip AM25S10 de remplacement...
Pas facile à trouver à prix raisonnable...
Sur arcadechips.com, il apparaît à $2.50 fdpout...
Sur ibé, c'est la classique recto-dilatation digne du congrès annuel de la SNFCP :

Finalement, je suis joueur, j'ai acheté ça :

C'est un lot de 5 chips "DS2510DC" pour environ 10 € fdpin.
Je ne suis même pas sûr que ce soit les bonnes puces, impossible de trouver le datasheet de ces trucs...
Bon on verra bien, c'est p'tet 10 balles de perdues...
Si quelqu'un sait me trouver le datasheet d'un DS2510DC...
À priori, le fabriquant serait RFT MIKROELEKTRONIK, un fabriquant de composants électroniques en ex-Allemagne de l'Est !
C'est bon, j'ai trouvé ça : lien. Ca doit être bon !

J'ai aussi un plan B : faire une carte de substitution à base de 8 chips 74LS151.
Les révisions les plus récentes de Space Invaders ont laissé tomber ces puces exotiques AM25S10, et le même résultat est calculé à partir de 74LS151. C'est bourrin, efficace et parfaitement juste.
Une personne du nom de Grant le détaille un peu sur sa page Space Invaders

À suivre : bah soit réception de mes "DS2510DC" made-in-DDR et peut-être cramage de ma LOGIC board, ou sinon conception d'une petite board de substitution...

[Little_Rabbit]

Salut,

Cool, ça progresse ! 

Une personne du nom de Grant le détaille un peu sur sa page Space Invaders

Lien intéressant !  Et sinon, une personne du nom de Little_Rabbit le détaille un peu sur son WIP Space Invaders.



A+

[f4brice]

Bonsoir.

Un peu de teasing, en attendant de recevoir les composants made in Deutsche Demokratische Republik...

Je me suis penché sur mon plan B, au cas où le plan A ne se déroulerait pas sans accroc.
Et puis de toute façon, ce ne sera probablement pas perdu, ça rendra sûrement service à quelqu'un.

Voilà :

Punaise, je me suis fait iéch grave de grave pour le routage.
Les 8 chips 74HCT151 sont en boîtier TSSOP16 pour qu'ils tiennent tous les 8 sur une petite carte qui fait la surface du rectangle délimité par les 4 shifters d'origine.
Chaque puce (sans les broches) fait 5,1 × 4,5 mm. Les broches sont au pas de 0,65 mm, soit environ 4 fois plus petit que les composants d'origine.
Ces trucs sont ultra-petits (j'espère que j'arriverai à les souder), et en plus ça rentre au chausse-pied...
J'ai quand même réussi à rester en 2 couches.

Je vais lancer un batch de 10 cartes, on verra bien...

[Little_Rabbit]

Salut,

Génial ! 

Oui, je mesure tout à fait la difficulté du routage de ces minuscules composants !... J'ai moi-même dernièrement fait une petite carte avec un TSH73CPT en boîtier TSSOP14 : ces bestioles font 5 x 4,4 mm, avec comme toi des broches distantes de 0,65 mm (soit un vide de 0,46 mm entre 2 broches ).

Leur soudure est réservée aux personnes non atteinte de Parkinson !

A+

[Michel Maeva]

Salut,

Quelle est l'utilité de cette carte ?

[f4brice]

Désolé, c'était évident pour moi alors je ne l'ai pas expliqué.
Les composants "AM25S10" sont exotiques et obsolètes, ce qui les rend pas très facile à acheter aujourd'hui à prix raisonnable.
L'idée, c'est de dessouder les 4 composants lorsque l'un ou plusieurs des quatre sont morts.
Ils sont remplacés par cette carte :

La carte reprend l'emplacement et l'espacement des 4 composants pour s'y fixer à leur place. Elle les substitue par des composants plus faciles à trouver.
Elle a besoin de 8 composants 74HCT151 qui ne sont ni obsolètes ni exotiques.