Gamoover

Les puces de la zone 3 ont une fonction assez particulière : Il s'agit de composants 74LS181. Chacun est une "ALU" (Arthimetic Logical Unit) de 4 bits.
En gros, c'est un composant capable de faire l'opération que l'on veut (il en existe 16) sur 2 mots de 4 bits.
Je suppose que SEGA a eu besoin d'une fonction logique spéciale que ce composant sait faire.
C'est une bonne idée car ça évite l'utilisation d'un composant type PAL/GAL et on reste dans du composant générique.

Sega a plutôt constitué, sur cette carte, un calculateur dédié à base de ce qui était disponible à l'époque, les premiers µP comme le 8080 ou le 6800 ne devaient pas encore être disponibles ou devaient coûter horriblement cher à l'époque.
En principe le noyau du calculateur devrait posséder ses propres PROM's fusibles dédiées à son micro-programme interne réalisant le séquencement nécessaire à chaque instruction lue dans un autre groupe de PROM's fusibles qui constitueraient la mémoire programme proprement dite.
Le micro-programme séquence au 1er niveau les échanges entre les ALU's, les registres de travail internes au noyau, la mémoire extérieure au noyau, les entrées/sorties ...
La mémoire programme contient les instructions qui sont lues et exécutées par le noyau du calculateur.

Et enfin, les 3 composants de la zone 4 sont réliés à l'écran.
Il s'agit de 74LS377. Ce sont des latches 8 bits.
En gros, ils assurent que les 2 mots de 12 bits envoyés à l'écran pour déplacer le spot sont stables pendant que le PCB calcule le mot suivant.

Les 3 ALU's de 4 bits, ainsi que ces 3 registres semblent montrer que le calculateur de la carte a une largeur de bus de 12 bits.

Avant d'aller plus loin, je constate qu'il y a des résidus oranges de soudure à de nombreux endroits.

Ne serait-ce pas plutôt la signature du remplacement de certains boîtiers lors d'une précédente tentative de réparation de la carte ?

Il est moche, parasité à mort. C'est une 1ère panne.
En suivant des yeux la piste, je me rends compte que ce signal est généré par... une ROM !!!

Ces ROM's sont des mémoires à sorties 3 états, le signal est peut-être multiplexé avec d'autres sorties à 3 états provenant d'autres boîtiers ? Est-ce que la mémoire en question est validée en permanence : broche CE/ (15) au niveau logique 0 permanent ?

Il est moche, parasité à mort. C'est une 1ère panne.

A quel endroit as tu raccordé la masse de ton oscilloscope ? Il est préférable de la raccorder au plus près du connecteur de la carte.
As tu remplacé les condensateurs chimiques de la carte et ceux de l'alimentation, est-ce que le +5 volts est propre quand il est zieuté à l'oscilloscope.

Peut-être qu'avec l'âge, l'accès est plus lent et que certains bits n'ont pas le temps de "sortir" avant que l'adresse de lecture ne change déjà...
J'ai essayé de givrer la ROM malade, mais sans aucun succès.

Ce sont des PROM's à fusibles, elles sont bien plus rapides en temps d'accès que des EPROM's même plus récentes.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Saturday 02 January 2010, 02:23:01 AM

Bonsoir.

Sega a plutôt constitué, sur cette carte, un calculateur dédié à base de ce qui était disponible à l'époque
[couic]

C'est intéressant comme idée ! :)
Je détaille plus bas comment les PROMs sont organisées.

Ne serait-ce pas plutôt la signature du remplacement de certains boîtiers lors d'une précédente tentative de réparation de la carte ?

C'est bien possible. Toutes les PROMs avaient des traces de soudures, ainsi que quelques boîtiers 74LSxxx.
J'ai noté que les 3 boîtiers 74LS377 avaient eux aussi des traces de soudures.

Ces ROM's sont des mémoires à sorties 3 états, le signal est peut-être multiplexé avec d'autres sorties à 3 états provenant d'autres boîtiers ? Est-ce que la mémoire en question est validée en permanence : broche CE/ (15) au niveau logique 0 permanent ?

Pour la PROMs concernée, son /CS est toujours à l'état bas : le boîtier est sélectionné en permanence.
Le bit que j'accuse d'être malade est relié à :

2 portes NOR sur IC75
l'entrée /E (enable input) des 3 boîtiers 74LS377

A quel endroit as tu raccordé la masse de ton oscilloscope ? Il est préférable de la raccorder au plus près du connecteur de la carte.
As tu remplacé les condensateurs chimiques de la carte et ceux de l'alimentation, est-ce que le +5 volts est propre quand il est zieuté à l'oscilloscope.

Bien évidemment, j'ai fait l'erreur de connecter la masse de mon oscillo "loin" de la carte...
Elle était pile à la sortie de l'alim, au niveau du départ des fils qui vont au connecteur du PCB.

Dans l'alim, il y a 3 monstrueux condensateurs que j'appelle "bombones".

1 × 10.000 µF / 16 V en amont du régulateur 7805 qui fournit le +5 V TTL
2 × 22.000 µF / 35 V sur le +25 V & -25 V non régulés pour l'écran et l'audio du PCB

Sur la carte, il n'y a que très peu de condensateurs chimiques. Il y en a exactement 4 :

2 × 470 µF / 10 V sur le +5 V TTL
1 × 47 µF / 35 V sur le +15 V audio (obtenu à partir du +25 V via un 7815)
1 × 47 µF / 35 V sur le -15 V audio (obtenu à partir du -25 V via un 7915)

Aucun n'a été changé pour le moment, mais je le ferai.

: f4brice Saturday 02 January 2010, 02:23:01 AM

Ce sont des PROM's à fusibles, elles sont bien plus rapides en temps d'accès que des EPROM's même plus récentes.

La maigre doc que j'ai pu trouver pour les PROM MMI 6331-1J indique :

t_AAC = 50 ns max
t_CAC = 30 ns max

L'un des deux est le temps d'accès (adress valid to output valid), et effectivement 30 ou 50 ns, c'est très rapide.
Une EPROM classique est plutot dans les 80 ns, je crois.

Voici la suite des investigations sur le PCB.

J'ai compté exactement 14 boîtiers de PROMs :

(http://img1.uplood.fr/free/rjhf_20091229_184220_6795_img.jpg) (http://www.uplood.fr)

Les 6 PROMs des zones 1, 2 et 3 ont toutes leur broche /CS reliée en permanance à la masse. Ces boîtiers sont donc sélectionnés en permanence.
Mon hypothèse est qu'ils ne contiennent pas de code/gfx au sens habituel du terme, mais n fonctions de transfert logiques à m arguments (n étant le nombre de bits du bus de données de la PROM, et m le nombre de bits du bus d'adresse)

Les 8 PROMs de la zone 4 travaillent différement. Elles ont toutes 2 broches "chip select" nommées /CS0 et /CS1.
Pour toutes, /CS1 est à la masse en permanence.
En revance /CS0 est dynamique.

(http://img1.uplood.fr/free/5ixf_20091229_184230_6796_img.jpg) (http://www.uplood.fr)

le bus d'adresse (10 bits) est commun pour les 8 PROMs
les PROMs sont associées 2 par 2 pour le bus de données (4 bits)
les PROMs sont associées 4 par 4 pour le chip select

Chaque PROM faisant 1024 mots de 4 bits, j'ai l'impression que ces 8 PROMs forment l'équivallent de 2 PROMS de 1024 mots de 16 bits.

J'utilise maintenant mon banc de test pour dépanner le PCB.
Je ne connecte que la masse et le + 5 V TTL.
Il manque le +25 V / -25 V mais ces 2 tensions ne servent que pour la partie analogique audio du PCB.
Pour le moment, je n'investigue pas de ce coté.

Sur les conseils de GC339, j'ai examiné la tension d'alimentation à différents endroits sur le PCB, d'une part quand il était alimenté par la borne SEGA, et d'autre part quand il est alimenté par l'alim à découpage de mon banc de test.
Dans les 2 cas, les mesures sont très semblables.
Tous les oscillogrammes suivants ont été relevés avec le PCB connecté au banc de test.

Voici la composante alternative de VCC mesurée à 2 endroits différents :

(http://img1.uplood.fr/free/9xc3_ic138_vcc.png) (http://www.uplood.fr)	(http://img1.uplood.fr/free/sv5u_ic029_vcc.png) (http://www.uplood.fr)
broche 16 de IC138 (la PROM que j'accuse d'être malade)	broche 16 de IC29 (un 74LS151 éloigné de IC138)

Dans un cas, j'ai plus de 800 mV d'amplitude de parasites.
Dans l'autre cas, j'ai environ 300 mV d'amplitude de parasites

Voici maintenant des bits du bus de données de la PROM accusée d'être malade :

(http://img1.uplood.fr/free/wq5z_ic138_d0.png) (http://www.uplood.fr)	(http://img1.uplood.fr/free/6hli_ic138_d2.png) (http://www.uplood.fr)
bit D0	bit D2

(http://img1.uplood.fr/free/4eqy_ic138_d3.png) (http://www.uplood.fr)	(http://img1.uplood.fr/free/vh0r_ic138_d6.png) (http://www.uplood.fr)
bit D3	bit D6

Pour moi, les bits D0 et D6 sont bons, mais les bits D2 et D3 seraient malades.
Mais vue la sale tronche du +5 V reçu par la PROM, peut-être qu'avec un condo céramique et un chimique entre masse et VCC au plus près de la PROM, les choses pourraient s'améliorer ?

J'ai aussi réussi a "dumper" le contenu de IC138 : c'est une PROM de 32 mots de 8 bits. 8)
Pour ça, je me suis réalisé un petit montage où les 8 bits de données de la PROM commandent chacun un transistor NPN, lequel transistor commande une LED.
Pour dérouler les adresses sur le bus, j'utilise un strap sur le bit de poids fort, 3 interrupteurs sur les bits intermédiaires et un bouton poussoir pour le bit de poids faible :

(http://img1.uplood.fr/free/yeni_20100101_210534_6840_img.jpg) (http://www.uplood.fr)

(http://img1.uplood.fr/free/znas_20100101_210546_6841_img.jpg) (http://www.uplood.fr)

Pour chacune des 2⁵ = 32 adresses possibles, je note dans un tableau l'état des 8 sorties.

Je pense avoir confirmé le fait que la PROM réalise en fait 8 fonctions logiques à 5 arguments.
En effet :

D0, D1, D6 et D7 ne passent à l'état haut qu'1 fois sur 32
D2, D3 et D5 ne passent à l'état bas qu'1 fois sur 32
D4 ne passe à l'état bas que 2 fois sur 32

À suivre : filtrage de VCC !

: [WIP 10%] Borne vectorielle : Sega Space Ship
: HerosSuperMan Saturday 02 January 2010, 09:13:12 AM

superbe
^-^
je panne pas tout mais c'est superbe :D

: [WIP 10%] Borne vectorielle : Sega Space Ship
: Darth Nuno Saturday 02 January 2010, 10:52:59 AM

Yeps, concernant la 'pastille', tu as bien fait de la laisser à sa place :

(http://img1.uplood.fr/free/s0mo_20091229_194554_6802_img.jpg)

Sans connaître le jeu, il est certain qu'il s'agisse d'un simple 'masque' servant à coloriser un élément du jeu. Procédé courament utilisé sur les premières bornes B&W (Break Out, Space Invaders, SuperBug ... ), un peu comme les caches de la Vectrex dans le genre.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: aganyte Saturday 02 January 2010, 15:50:45 PM

Chapeau bas <:) , de la vrai bonne bidouille d'électroniciens ^-^

Ps: ça me fait penser à l'époque ou on ce tapé le décodage d'adresse à la main.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Saturday 02 January 2010, 18:36:32 PM

Bonjour et meilleurs voeux pour 2010 à tous ceux qui liront ce post.

Dans l'alim, il y a 3 monstrueux condensateurs que j'appelle "bombones". [couic] Sur la carte, il n'y a que très peu de condensateurs chimiques. [re-couic] Aucun n'a été changé pour le moment moment, mais je le ferai.

Il est important de ne pas les remplacer par n'importe quel condensateur que ne manquerait pas de refourguer le crémier le plus proche.
Les "pots de confitures" doivent être remplacés par des condensateurs de filtrage équivalents prévus pour supporter le courant périodique qui les traverse. Il faut le vérifier sur le datasheet du fabriquant, c'est parfois indiqué sur leur boîtier, exemples :

I eff à 100 Hz 6,9 A à 85°
I eff. (20 KHz) 9,5 A (70°C)
3,5A. 85°C

Les condensateurs de découplage sur la carte doivent être remplacés par des modèles à "low ESR" pour plus d'efficacité. Ils sont plus difficiles à approvisionner, Conrad en vend sur son site n°2, sinon voir Farnell.

: f4brice Saturday 02 January 2010, 02:23:01 AM

(http://img1.uplood.fr/free/9xc3_ic138_vcc.png) (http://img1.uplood.fr/free/6hli_ic138_d2.png)
broche 16 de IC138
(la PROM que j'accuse d'être malade)

bit D2 de la même PROM

Ces deux oscillogrammes me font penser à ceux que l'on pourrait observer sur les broches d'une mémoire rapide dont les adresses seraient connectées à un compteur asynchrone genre CD4040 ou 7493.
L'horloge qui pilote le compteur n'étant pas distribuée sur tous les bascules du compteur, mais uniquement sur la 1er, elles ne changent pas d'état simultanément mais les unes après les autres. Ce qui induit des états transitoires sur le bus d'adresse, donc des commutations intempestives sur les sorties des données et par conséquent des pointes de courant sur l'alimentation.
Ce comportement peut être aussi le fait d'une broche d'adresse "en l'air" ou à un niveau logique intermédiaire. As tu vérifié à l'oscilloscope le signal sur chacune des broches d'adresse de ces mémoires ?

: f4brice Saturday 02 January 2010, 02:23:01 AM

Mais vue la sale tronche du +5 V reçu par la PROM, peut-être qu'avec un condo céramique et un chimique entre masse et VCC au plus près de la PROM, les choses pourraient s'améliorer ?

Non, il faut voir les choses autrement, ce sont les appels de courant intempestifs de la PROM qui parasitent le + 5 volts, c'est pour cela que la perturbation de l'alimentation, constatée sur l'oscilloscope, est plus importante au voisinage de ce boîtier.
Pour être sûr du bon fonctionnement de la PROM ( mais malheureusement pas de l'intégrité de sa programmation initiale ), il faudrait réaliser un petit montage :

L'adresser par un compteur synchrone piloté par une horloge à quartz d'une dizaine de MHz (deux compteurs 74LS163 ou mieux 74S163 / 74F163 en cascade).
Alimenter le montage à part pour qu'il ne soit pas parasité par d'autres circuits.
Découpler correctement l'alimentation +5 volts du compteur et de la PROM.
Vérifier les signaux à l'oscilloscope sur chacune des ses sorties.

A+

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Sunday 03 January 2010, 15:54:46 PM

Petite mise à jour intermédiaire...

Je suis en plein reverse-engineering sur le chassis vidéo de l'écran X-Y. 8)
Alors que j'étais dans l'exploration autour du 1^er convertisseur numérique/analogique, je suivais une piste de cuivre qui devait normalement être "-VCC", soit du -15 V régulé.

J'arrive sur ce composant, que j'ai examiné un peu vite :

(http://img1.uplood.fr/free/e53q_20100103_154152_6849_img.jpg) (http://www.uplood.fr)

Ayant lu la sérigraphie entourée en rouge, je m'étais dit que c'était un régulateur positif 14 V.
Déjà, 2 choses très louches :

les régulateurs 14 V, ça n'existe pas dans la nature (c'est 12 ou 15 V)
d'après la doc technique du CNA, je devais trouver une tension d'alim négative

En fait, la référence du composant est entourée en vert. C'est bien un régulateur négatif -15 V.
La sérigraphie "7814" correspond à la date de fabrication : 14^e semaine de 1978...

Arf, le gros piège à noob, et je suis tombé dedans ! ;D

Bon, j'y retourne... :-)=

: [WIP 10%] Borne vectorielle : Sega Space Ship
: zebassprophet Sunday 03 January 2010, 17:24:38 PM

je viens de regarder mes flips (et faire un peu de la merde d'ailleurs) et quand je vois la facilité avec laquel tu trouve et resoud certains probleme dans l'ordre
j'en reste pantois :-)=

: [WIP 10%] Borne vectorielle : Sega Space Ship
: funkycochise Sunday 03 January 2010, 17:24:58 PM

: f4brice Sunday 03 January 2010, 15:54:46 PM

La sérigraphie "7814" correspond à la date de fabrication : 14^e semaine de 1978...

Putain, avril 1978...
ca nous rajeunit pas !

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Sunday 03 January 2010, 20:52:37 PM

Pfiouuuuuu....

Ayé, je viens de terminer une grosse partie du reverse-engineering sur le chassis vidéo du moniteur X-Y de la borne ! :-)=

Voici la pré-version du schéma électronique du pilotage de la bobine de déviation X du tube, à partir des données envoyées par le PCB (connecteur J1 à gauche sur mon schéma).
C'est un brouillon amélioré. J'ai réussi à ne pas faire se croiser trop de lignes.

Le pilotage de la bobine Y est totalement similaire. Seules changent des valeurs de résistances autour de IC4.

(http://img1.uplood.fr/free/thumbnails/fazv_deviation-x.png) (http://www.uplood.fr/visu.php?url=http://img1.uplood.fr/free/fazv_deviation-x.png)

J'ai mesuré les résistances ohmiques des bobines de déviation :

bobine X : environ 1,0 Ω
bobine Y : environ 0,3 Ω

La mesure tient compte de la résistance des fils du multimètre ; elle a été faite au plus près des bobines, au niveau du support blanc où les fils de cuivre sont soudés.

Mes commentaires :

1.

La sortie du convertisseur numérique/analogique rentre sur 2 switches analogiques
la sortie d'un des switches attaque C8 en direct, tandis que l'autre passe à travers 2 résistances
J'ai l'impression que C8 sert de mémoire analogique lorsque les 2 switches sont ouverts ; il maintient la dernière tension convertie par le CNA à l'entrée du filtre réalisé autour de IC4 ?
Quand J1-22 est actif, C8 reçoit directement la sortie du CNA ; le spot fait un saut depuis sa position courante vers l'endroit demandé ?
Ce serait l'équivallent du "PLOT" du basic...
Quand J1-21 est actif, C8 reçoit la sortie du CNA à travert R45 + VR4 ; le spot se déplace depuis sa position courante vers l'endroit demandé ?
Ce serait l'équivallent du "DRAWTO" du basic...

L'ampli-op IC4 (un LF351N) réalise un filtrage, mais je suis incapable de dire lequel...

Il n'y a pas moins de 11 transistors pour l'étage de commande de la bobine de déviation !
TR18 semble avoir un rôle de protection, mais je ne saurais dire exactement lequel ; il est commandé par le courant qui traverse la bobine de déviation
si le courant est trop fort, il se sature et tend à bloquer TR17 en augmentant la tension de son émetteur ?
Je n'ai pas trop compris à quoi servent TR12 et TR13 ; ce sont 2 "petits" transistors (boîtier TO92) ; protection en cas de destruction de TRX1 ou TRX2 ? amorçage du circuit ?

il y a un truc louche avec TR12 et TR13 ; ce sont respectivement des "C815" et "A539"
à supposer que ce sont des 2SC815 et 2SA539, leur brochage diffère de la doc que j'ai trouvée sur le net ; la doc dit que la base est la broche du mileu alors que la sérigraphie SEGA la place sur un coté
mon schéma est conforme à la sérigraphie SEGA.

(http://img1.uplood.fr/free/512h_20100103_204938_6850_img.jpg) (http://www.uplood.fr)

À suivre : reverse-engineering sur la partie THT... 8)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: nicolas-le-jardinier Sunday 03 January 2010, 22:14:08 PM

Toujours admiratif de tes travaux, j'ai un space wars en rade (bien en rade), j'ai faillis bener le moniteur mais en voyant des gars (enfin 1 gars :D) qui s'atarde sur des trucs comme ca :-* bah je le garde ca pourra servir qui sait :)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Sunday 03 January 2010, 22:51:13 PM

L'ampli-op IC4 (un LF351N) réalise un filtrage, mais je suis incapable de dire lequel...

IC4 est cablé en amplificateur pseudo logarithmique, le gain V_sortie/V_entrée n'est pas constant, il diminue quand l'amplitude de la tension de sortie augmente.

(http://pagesperso-orange.fr/michel.hubin/physique/elec/sv5185195.gif)
Principe de l'amplificateur logarithmique

Dans le cas présent, la courbe de transfert peut être assimilée à une suite de 3 segments de droite ayant des inclinaisons différentes.

Le premier coude ayant lieu dés que la tension en sortie avoisine le seuil des diodes D25 ou D26, c'est à dire ± 0,7 volt, il circule alors un courant dans la résistance R43 et le gain de l'amplificateur en est minoré d'autant.
Le deuxième ayant lieu quand la tension en sortie avoisine les seuils cumulés de D24 + D25 ou de D23 + D26, c'est à dire ± 1,4 volt, il circule alors un courant dans la résistance R42 qui vient minorer une nouvelle fois le gain de l'amplificateur.

Il n'y a pas moins de 11 transistors pour l'étage de commande de la bobine de déviation

Il faut se représenter chaque amplificateur comme un amplificateur opérationnel de puissance réalisé avec des composants discrets.

TR18 semble avoir un rôle de protection, mais je ne saurais dire exactement lequel ; il est commandé par le courant qui traverse la bobine de déviation si le courant est trop fort, il se sature et tend à bloquer TR17 en augmentant la tension de son émetteur ?

TR17 et TR18 constituent un étage d'entrée différentiel, les transistors sont couplés par leur émetteurs et ils se partagent la source de courant constant constituée par TR16.
La base de TR17 est l'entrée "+" de cet amplificateur opérationnel de puissance et la base de TR18 est l'entrée "-"

Je n'ai pas trop compris à quoi servent TR12 et TR13 ; ce sont 2 "petits" transistors (boîtier TO92) ; protection en cas de destruction de TRX1 ou TRX2 ? amorçage du circuit

TR12 et TR13 servent à limiter le courant dans les transistors de puissance TRX1 et TRX2. Ces deux transistors de puissance sont associés respectivement à TR11 et TR10 pour constituer un assemblage nommé 'transistor darlington".

(http://www.awatronic.com/images/uploads/GammeE1020.jpg)

L'ensemble se comportant comme un super transistor dont le gain en courant est égal au produit des gains de chacun des transistors qui le constitue.

La tension aux bornes de la résistance R19 est aussi la tension appliquée à la jonction base / émetteur de TR12, de même pour TR13 avec la résistance R21, dés que cette tension atteint les 0,6 / 0,7 volt, le transistor impacté se met alors à conduire et à court-circuiter la jonction base / émetteur du transistor darlington qu'il protège. Le courant collecteur du transistor de puissance s'auto-limite alors à 0,7 ÷ 0,18 soit 3,9 ampères.

: f4brice Sunday 03 January 2010, 23:12:24 PM

il y a un truc louche avec TR12 et TR13 ; ce sont respectivement des "C815" et "A539" [couic] à supposer que ce sont des 2SC815 et 2SA539, leur brochage diffère de la doc que j'ai trouvée sur le net ; la doc dit que la base est la broche du milieu alors que la sérigraphie SEGA la place sur un coté mon schéma est conforme à la sérigraphie SEGA.

Cela arrive parfois selon avec certains constructeurs. Un test à l'ohmmètre devrait permettre de vérifier une fois pour toute s'ils sont correctement montés.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Sunday 03 January 2010, 23:12:24 PM

Merci pour ces explications ! <:)
J'ai maintenant compris la fonction des transistors TR12 et TR13. :)

Que penses-tu de mon commentaire n°1 ? J'ai vu juste ou j'ai fumé ?

Sinon, j'ai bientôt fini de tracer le schéma de la partie "THT".
Il faut que je le redessine pour qu'il soit plus compréhensible.
J'ai l'impression que l'oscillateur nécessaire pour faire fonctionner la THT réside dans le PCB de jeu...

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Monday 04 January 2010, 00:15:11 AM

Que penses-tu de mon commentaire n°1 ? J'ai vu juste ou j'ai fumé ?

Il me semblait correct, c'est pour cela que je n'ai rien ajouté. Mais à bien y réfléchir :

Dans un cas le condensateur est chargé/déchargé par l'impédance de sortie du convertisseur : le spot se déplace rapidement.
Dans l'autre, la constante de temps est augmentée et le spot se déplace plus lentement :
- θ_mini = RC = 11 × 10³ × 22 × 10^-9 = 0,242 ms
- θ_maxi = RC = (11 + 5) × 10³ × 22 × 10^-9 = 0,352 ms
La constante de temps me parait bien faible vis à vis de la persistance rétinienne.

Ne s'agirait-il pas plutôt d'un dispositif connexe à l'extinction de trace :

Tracé non affiché : il vaut mieux déplacer le spot rapidement pendant l'extinction, inutile de folatrer...
Tracé visible : il vaut mieux déplacer le spot plus lentement pour améliorer la luminosité du tracé.

: f4brice Sunday 03 January 2010, 23:12:24 PM

J'ai l'impression que l'oscillateur nécessaire pour faire fonctionner la THT réside dans le PCB de jeu...

Pourquoi pas ! Puisque la production de THT n'a pas besoin d'être asservie au balayage ligne, celui-ci n'étant pas cyclique.

A+

: [WIP 10%] Borne vectorielle : Sega Space Ship
: Vany Monday 04 January 2010, 01:54:52 AM

((:s

Hey les gars, vous faites quoi dans la vie comme boulot ? ;)

J'ai la sensation d'être devant un tableau de Milo largement incompréhensible et donc forcément fascinant.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Monday 04 January 2010, 02:05:35 AM

Voici le schéma de la partie "THT".

(http://img1.uplood.fr/free/thumbnails/rix1_tht.png) (http://www.uplood.fr/visu.php?url=http://img1.uplood.fr/free/rix1_tht.png)

Commentaires :

IC10 possède 6 portes inverseuses à sortie à collecteur ouvert ; seules 2 portes ont utilisées
je n'ai pas pu déterminer exactement les enroulements de la THT
à priori :
- E semble être un secondaire, sortie G2
- J semble être le focus et VR6 son réglage
- G semble être la cathode et VR5 son réglage
J1-35 et J1-36 semblent contrôler la luminosité du spot ; il y a probablement 4 niveaux différents, en comptant le niveau "éteint"
je n'ai pas compris comment TR22 est commandé
le +18 V non régulé qui polarise TR21 vient directement de l'alim ;
ce sont 2 enroulements du transfo avec un point commun et 2 diodes de redressement ;
il y a un petit condo tantale de filtrage que je n'ai pas indiqué

Voici le transfo THT :

(http://img1.uplood.fr/free/b0o4_20100103_125420_6846_img.jpg) (http://www.uplood.fr)

La sérigraphie de ce gros truc gris indique "voltage tripler".
J'imagine que c'est un transfo noyé dans de la résine.
Il est entre la sortie latérale de la THT et la tétine.

(http://img1.uplood.fr/free/wh5b_20100103_125548_6847_img.jpg) (http://www.uplood.fr)

Bonne nuit. :D

: [WIP 10%] Borne vectorielle : Sega Space Ship
: maldoror68 Monday 04 January 2010, 09:17:51 AM

je commence à scotcher à ce WIP, même si je comprends que-dalle :-* <:)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: zebassprophet Monday 04 January 2010, 09:47:20 AM

elle a l'air en bon état la platine
c'est deja un bon debut

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Monday 04 January 2010, 10:15:13 AM

Bonjour.

Help ! je n'arrive pas à enregistrer une image au format png sur le site d'upload.fr alors que les formats gif et jpeg sont OK, impossible même en direct.
J'obtiens systématiquement le message "Type de fichier invalide". Quelqu'un a la solution ?

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Monday 04 January 2010, 10:46:03 AM

: gc339 Monday 04 January 2010, 10:15:13 AM

Bonjour.

Help ! je n'arrive pas à enregistrer une image au format png sur le site d'upload.fr alors que les formats gif et jpeg sont OK, impossible même en direct.
J'obtiens systématiquement le message "Type de fichier invalide". Quelqu'un a la solution ?

Bizarre, car je confie souvent des images png à upload.fr (mes schémas par exemple).
Peut-être tes png ont une particularité qui ne plait pas à upload.fr ?
Mes images sont travaillées avec l'outil Gimp (http://www.gimp.org/) :

scan (scanner Canon) 300 dpi -> image RVB 32 bits
filtrage seuil pour obtenir du noir & blanc pur
transformation en palette indexée, 2 couleurs, pas de tramage
réduction à 1.600 pixels de large
sauvegarde en PNG, compression maxi

As-tu vérifié la taille (octets) du fichier ?
Peut-être sont-ce les dimensions de l'image (pixels) qui ne plaisent pas à upload ?

: [WIP 10%] Borne vectorielle : Sega Space Ship
: supercarotte Monday 04 January 2010, 10:47:33 AM

Va l'héberger sur www.imageshack.us, il me semble que ça prend le .png ;)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Monday 04 January 2010, 10:52:11 AM

: f4brice Monday 04 January 2010, 02:05:35 AM

je n'ai pas compris comment TR22 est commandé

TR22 et deux des enroulements du transformateur THT réalisent un auto-oscillateur à surcouplage connu sour le nom "d'oscillateur blocking".
Désolé, je n'ai trouvé que cette explication en anglais : http://en.wikipedia.org/wiki/Blocking_oscillator
La phase des enroulements doit être respectée pour que le système puisse osciller, je l'ai représentée par des points noir sur le schéma modifié :

(http://img1.uplood.fr/mamu/kdlm_rix1_tht.small.jpg) (http://img1.uplood.fr/mamu/etns_rix1_tht.jpg)

Les composants RC ainsi que les deux diodes sont ajoutés pour améliorer les temps de commutation du transistor TR22 et/ou le protéger des surtensions.

: f4brice Monday 04 January 2010, 02:05:35 AM

La sérigraphie de ce gros truc gris indique "voltage tripler".
J'imagine que c'est un transfo noyé dans de la résine.

Non, ce n'est pas un transformateur mais un dispositif redresseur constitué de cellules diodes/condensateurs :

(http://retro-forum.com/download/file.php?id=43682)

Voir cette explication sur le tripleur pour THT : http://dede92dubois.free.fr/alacouleur/21/21alacouleur.htm paragraphe : "B) Le redressement par multiplication de tension"

Ce dispositif tripleur était majoritairement utilisé dans les années 70/80 pour produire la THT des téléviseurs et moniteurs couleurs à transistors. Il a progressivement disparu dés que l'on a su produire des transformateurs à enroulements fractionnés voir le paragraphe "C) Le redressement fractionné" du même document.

A+

: [WIP 10%] Borne vectorielle : Sega Space Ship
: High_Cobra Monday 04 January 2010, 10:54:00 AM

: supercarotte Monday 04 January 2010, 10:47:33 AM

Va l'héberger sur www.imageshack.us, il me semble que ça prend le .png ;)

Pas besoin d'aller voir ailleurs, uplood gère très bien le png et a une persistance de contenu bien meilleure que imageshack.us... Et en plus, son créateur est membre gamoover :D

Après, même supposition que f4brice, sans doute un png "bizarre"...

: [WIP 10%] Borne vectorielle : Sega Space Ship
: emilealpi Monday 04 January 2010, 10:59:52 AM

J'apporte ma modeste pierre à l'édifice, même si elle n'a rien de technique (toute façon vu le niveau je crois pas qu'il y ait besoin d'en rajouter :D)

Ton jeu est un "Space Wars" et le "Soleil" central a bien sa raison d'être ! Il ne faut surtout pas le retirer, il matérialise le "trou noir" gravitationnel central qui perturbe la combat que se livrent les deux vaisseaux.

Not a valid youtube URL name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="

type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>[/youtube]

plus d'info ici : http://en.wikipedia.org/wiki/Space_Wars (http://en.wikipedia.org/wiki/Space_Wars)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: liodel Monday 04 January 2010, 11:33:38 AM

C'est pas la doc ça ?
http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/Space%20Wars.pdf

plein d'autres infos ici :
réparation écran, rom eproms, art...
http://andysarcade.de/spacewars.html

: [WIP 10%] Borne vectorielle : Sega Space Ship
: keube Monday 04 January 2010, 11:42:14 AM

ça avance on dirait ^-
Bon courage tu vas réussir à nous à la ressuisciter cette borne qui a maintenant un nom!

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Monday 04 January 2010, 12:18:15 PM

: emilealpi Monday 04 January 2010, 10:59:52 AM

Ton jeu est un "Space Wars"

: liodel Monday 04 January 2010, 11:33:38 AM

C'est pas la doc ça ?
http://arcarc.xmission.com/PDF_Arcade_Manuals_and_Schematics/Space%20Wars.pdf

plein d'autres infos ici :
réparation écran, rom eproms, art...
http://andysarcade.de/spacewars.html

Ouergl ! :-)=

Mon jeu est la version SEGA de Space Wars.
Le schéma de l'écran correspond à mon écran SEGA (mais SEGA utilise des composants japonnais).
Pour celui du PCB, ça a l'air d'être le même schéma. Il faut que je regarde en détails.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: Wapata Monday 04 January 2010, 13:21:09 PM

Ben les gars...
Vous êtes épatants.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Monday 04 January 2010, 13:29:40 PM

: f4brice Monday 04 January 2010, 12:18:15 PM

Pour celui du PCB, ça a l'air d'être le même schéma. Il faut que je regarde en détails.

C'est aussi ma première impression, il faudra compter avec des adaptations mineures causées par l'emploi d'EPROM ou de ROM de capacité supérieure.

Il y a aussi le dump de ces ROM dans le lien donné par liodel, donc possibilité de vérification si les contenus sont identiques.

A+

: [WIP 10%] Borne vectorielle : Sega Space Ship
: Darth Nuno Monday 04 January 2010, 13:41:49 PM

: f4brice Monday 04 January 2010, 12:18:15 PM

Ouergl ! :-)=

Mon jeu est la version SEGA de Space Wars.
Le schéma de l'écran correspond à mon écran SEGA (mais SEGA utilise des composants japonnais).
Pour celui du PCB, ça a l'air d'être le même schéma. Il faut que je regarde en détails.

Yeps, indice déjà indiqué lors de la vente, juste ici (http://www.gamoover.net/Forums/index.php?topic=20430.msg293539#msg293539) ;)

Sinon, j'ai trouvé une photo de cette borne dans mon livre reprenant toutes les bornes SEGA... allez, hop, à l'arrache avec l'i-phone :fleche:

(http://www.arcadelifestyle.net/forforum2/segaspace.jpg)

Je ferai un scan high res. si tu veux...et histoire que quelqu'un puisse te traduire le texte ;)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: supercarotte Monday 04 January 2010, 13:45:15 PM

Je peux lui prêter le Sega Arcade History que j'ai aussi si besoin, mais je pense pas qu'il contienne des infos extraordinaires :)

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Monday 04 January 2010, 13:55:23 PM

Un scan me suffit. <:)
J'ai 2 collègues de boulot qui devraient, à eux deux, peut-être me décrypter ça ! :D

EDIT: bon, y'en a un des deux qui se dégonfle devant le document !

: [WIP 10%] Borne vectorielle : Sega Space Ship
: maldoror68 Monday 04 January 2010, 14:36:25 PM

wahaaa !

une space wars à gamoover!

champagne!!!! ((:s :10:

manquerai plus que la pcb de sega soit très proche voir identique à la doc , et la rénov' est dans la poche!

: [WIP 10%] Borne vectorielle : Sega Space Ship
: nicolas-le-jardinier Monday 04 January 2010, 16:50:05 PM

J'ai une notice du moniteur trouvée dans ma space wars, je l'avait transmise an andréa de http://andysarcade.de/ (http://andysarcade.de/)
Si ca t'interesse fais moi signe, je crois que c'est un vectorbeam

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Monday 04 January 2010, 21:41:22 PM

Bonsoir, juste une petite aparté ...

: gc339 Monday 04 January 2010, 10:15:13 AM

Help ! je n'arrive pas à enregistrer une image au format png sur le site d'upload.fr alors que les formats gif et jpeg sont OK, impossible même en direct.
J'obtiens systématiquement le message "Type de fichier invalide". Quelqu'un a la solution ?

Depuis j'ai essayé plusieurs browsers dont IE7, IE8 et Firefox, avec deux d'entre eux il m'est effectivement impossible d'enregistrer un png sur le site d'upload.fr, quelque soit le pc ou son système d'exploitation (XP ou Vista). Avec le 3èm browser, pas de soucis, le png est bien accepté.
Je vous laisse deviner lesquels de ces browsers sont incompatibles ...

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Monday 04 January 2010, 22:14:22 PM

: gc339 Monday 04 January 2010, 21:41:22 PM

Bonsoir, juste une petite aparté ...
[couic]

J'utilise Opera (http://www.opera.com/). ^-
C'est sûrement pour ça que je n'ai jamais eu ce problème !

Je viens de regarder la notice du jeu Space Wars de chez Cinematronic.
Ouergl, gc339 avait vu juste : c'est bien un CPU spécifique qui est réalisé en logique TTL. :o

Voici un extrait (traduit par mes soins) de la page 9 de cette notice, à propos de ce CPU dédié :

: Notice

Les désavantages principaux d'un point de vue "SAV" sont que le système est lourdement contrôlé par le logiciel avec son propre language machine et op-codes, et qu'il y a un nombre de "boucles" au sein des circuits de signaux qu'il est virtuellement impossible de localiser une panne en utilisant des moyens et des techniques ordinaires.

Eh bé...
Les ~~journées~~ ~~soirées~~ nuits vont être longues ! :D

La 1ère chose que je vais faire, c'est reporter sur les schémas Cinematronic les n° de circuits (IC1, IC2, ... jusqu'à IC151) choisis par SEGA.
Je devrais ainsi ~~m'y retrouver~~ moins m'y perdre.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Tuesday 05 January 2010, 01:04:17 AM

Bonsoir.

Voici une mise à jour de ce WIP.

Je me suis précipité pour télécharger les 2 archives zip contenant le dump des ROMs :

dump du micro-cadenceur du CPU Cinematronic
dump des ROMs du jeu lui-même

Le lien pour récupérer ces 2 archives est dispo sur cette page (http://andysarcade.de/spacewars.html), indiquée par liodel.

Déjà, chose bizarre, l'archive qui contient les PROMs du micro-cadenceur du CPU possède 6 fichiers dump + 1 fichier texte :

(http://img1.uplood.fr/free/jll1_a.png) (http://www.uplood.fr)

Je pensais que les PROMs de la région 4 étaient le micro-cadenceur :

(http://img1.uplood.fr/free/rjhf_20091229_184220_6795_img.jpg) (http://www.uplood.fr/)

En fait, pas du tout...
Ce sont les PROMs des régions 1, 2 et 3 qui sont le micro-cadenceur du CPU.
Dans les PROMs de la région 4 sont stockées les données spécifiques au jeu (instructions assembleur, données de graphisme, ...)

Cinematronic utilise une référence "ligne/colonne" pour désigner un circuit intégré sur le PCB de jeu.
On devine la sérigraphie "A B C..." de droite à gauche en bas du PCB sur cette photo :

(http://img1.uplood.fr/free/5jtl_spacewars.pcb.jpg) (http://www.uplood.fr)
[source : Crazy Kong (http://www.crazykong.com/pcbs/P%20-%20S/index02.html)]

De son coté, SEGA désigne les circuits intégrés avec une référence que j'appelle dans mon jargon une référence "itérative" : "IC1", "IC2", ... "IC151".
Mais dans la pratique, SEGA a placé ses composants au même endroit que Cinematronic, à quelques exceptions près.

J'ai donc pu recouper ainsi que la PROM SEGA "PR-17", référencée "IC138" sur le PCB SEGA correspond à la E14 chez Cinematronic.

C'est comme ça que j'ai pu comparer le dump que j'avais fait moi-même avec le dump de l'archive proposée par Andreas (http://andysarcade.de/) :

Mon relevé : chaque ligne est une adresse de lecture de la PROM.
J'avais préparé une feuille vide avec un tableur :

(http://img1.uplood.fr/free/wne4_dump_fab.png) (http://www.uplood.fr)

Contenu du dump trouvé sur le net :

(http://img1.uplood.fr/free/hkom_editeur_hexa.png) (http://www.uplood.fr)

Les 2 contenus sont totalement identiques. Il n'y a aucun bit de différence.
Le contenu de ma PROM est donc correct.

Grâce à l'aide de la doc, je vais pouvoir aborder le problème différemment.
Par exemple, page 12, il est indiqué - si j'ai bien compris - qu'une condition de reset sera atteinte si un foirage sur n'importe lequel des 90% des signaux du PCB est détecté.

Je vais donc examiner en 1er ce signal reset.

Par contre, il est indiqué qu'une conséquence est l'absence de commandes envoyées à l'écran et donc la rupture d'un fusible de l'alim, pour protéger l'écran.
Or d'après mes 1er tests, rien n'est envoyé à l'écran et pourtant je n'ai pas de fusible grillé.

J'avais déjà investigué, sur les conseils de gc339, les 5 bits d'adresse que la PROM que j'accusais d'être moisie.
Voici les relevés :

(http://img1.uplood.fr/free/wlm0_a0.png) (http://www.uplood.fr)	(http://img1.uplood.fr/free/ce6g_a1.png) (http://www.uplood.fr)	(http://img1.uplood.fr/free/9zj4_a2.png) (http://www.uplood.fr)
a0	a1	a2
(http://img1.uplood.fr/free/7z7h_a3.png) (http://www.uplood.fr)	(http://img1.uplood.fr/free/3m3a_a4.png) (http://www.uplood.fr)
a3	a4

Mes relevés ne permettent pas de détecter l'asynchronisme de commutation des signaux du bus d'adresse. Il faut que je sorte la 2e sonde pour ça.
Déjà, il n'y a aucun bit "en l'air".
Les signaux ne m'ont pas l'air d'être exagérément parasités.
Sur a3, dans la 6e division de temps, il y a un glitch qui n'est pas constant (le trait épais).
Mon relevé a été fait alors que le glitch était bien visible.

À suivre : endoscopie du CPU Cinematronic ! :D

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Tuesday 05 January 2010, 01:35:26 AM

: nicolas-le-jardinier Monday 04 January 2010, 16:50:05 PM

J'ai une notice du moniteur trouvée dans ma space wars, je l'avait transmise an andréa de http://andysarcade.de/ (http://andysarcade.de/)
Si ca t'interesse fais moi signe, je crois que c'est un vectorbeam

J'ai trouvé cette notice (http://arcarc.xmission.com/PDF_Monitors/Keltron%20Monitor%20new.pdf) en pdf, donc je n'ai pas besoin de ton document.
Par contre, si tu as la notice du jeu avec les schémas électroniques, ça m'intéresse.
Le scan que j'ai trouvé sur le net, sans être mauvais, n'a pas la précision nécessaire à certains endroits.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: philougames Tuesday 05 January 2010, 08:35:59 AM

salut f4brice ,c'est un vrai plaisir de te relire =:))
tu es calé dans le domaine ,
en tous cas bravo ,grâce a des gens comme toi il y aura des bornes de collection qui seront sauvé ^-^ ^-^
de plus tu nous aide beaucoup dans nos réparation
je vais suivre ton wip de très près
bonne chance

: [WIP 10%] Borne vectorielle : Sega Space Ship
: BadGuigui Tuesday 05 January 2010, 10:13:23 AM

Oui tes travaux sont vraiment agréables à lire car tu nous explique vraiment pas à pas ce que tu fais et c'est vraiment top.

Vraiment top ^- bon courage!!!

: [WIP 10%] Borne vectorielle : Sega Space Ship
: nicolas-le-jardinier Tuesday 05 January 2010, 13:38:07 PM

: f4brice Tuesday 05 January 2010, 01:35:26 AM

J'ai trouvé cette notice (http://arcarc.xmission.com/PDF_Monitors/Keltron%20Monitor%20new.pdf) en pdf, donc je n'ai pas besoin de ton document.
Par contre, si tu as la notice du jeu avec les schémas électroniques, ça m'intéresse.
Le scan que j'ai trouvé sur le net, sans être mauvais, n'a pas la précision nécessaire à certains endroits.

Oui je vais regarder je pense l'avoir.

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Tuesday 05 January 2010, 14:22:44 PM

Bonjour.

Je ne sais pas comment tu comptes t'y prendre pour dépanner cette carte, mais en analysant les schémas pages 25 et 26 de la notice "space wars" on se rend vite compte que tous les bus internes se "mordent la queue" à travers ALU et latches. Je ne parle pas du micro-séquenceur qui ajoute encore en complexité. C'est infernal à dépanner même avec les meilleurs outils.

La meilleure des solutions dans ce cas la est la méthode "bourrin" qui consiste à dessouder les circuits intégrés un par un ou par grappe pour :
- Vérifier le contenu de toutes les ROM.
- Vérifier les RAM.
- Vérifier les circuits TTL en les regroupant par fonction : ceux du compteur programme, ceux des accumulateurs, ceux de chaque multiplexeur 12 fois X vers 1 ... et en vérifiant le fonctionnement de la carte à chaque fois que les boîtiers d'une fonction ont été vérifiés et remis en place (sur supports tulipe ). Cette méthode a plus de chance d'aboutir rapidement qu'un test désordonné des circuits TTL.

Si l'on trouve par exemple un boîtier avec une de ses broches d'entrée/sortie en court-circuit ou qui impose une tension bâtarde, il est nécessaire d'aller vérifier tous les autres boîtiers ayant une ou des broches entrée/sortie connectées avec celle-ci.

Il y a bien la solution de remplacer les circuits TTL à chaque fois que l'on en dessoude un par un neuf, mais rien ne garantie que le neuf est 100% OK. C'est pour cela qu'un testeur de CI (IC tester) te serait des plus utile surtout si tu comptes dépanner tout le lot de cartes récupérées.
Ce genre d'équipement permet en plus de programmer et/ou de vérifier tout un tas de mémoires, voir par exemple les modèles VP280 et TOP2049 en vente sur un site d'enchères très connu.

A+

: [WIP 10%] Borne vectorielle : Sega Space Ship
: aganyte Tuesday 05 January 2010, 14:24:43 PM

Ça sent bon le WIP de malade ici...Moi j'aime bien :-)=

: [WIP 10%] Borne vectorielle : Sega Space Ship
: f4brice Wednesday 06 January 2010, 01:39:03 AM

Bonsoir.

: gc339 Tuesday 05 January 2010, 14:22:44 PM

Je ne sais pas comment tu comptes t'y prendre pour dépanner cette carte, mais en analysant les schémas pages 25 et 26 de la notice "space wars" on se rend vite compte que tous les bus internes se "mordent la queue" à travers ALU et latches. Je ne parle pas du micro-séquenceur qui ajoute encore en complexité. C'est infernal à dépanner même avec les meilleurs outils.
[couic]

N'ayons pas peur des mots : cette carte est une parfaite usine à gaz d'une complexité inimaginable !

(http://img1.uplood.fr/free/ey90_raffinerie.jpg) (http://www.uplood.fr)

Je me demande combien de temps et de prototypes il a fallu aux gens de chez Cinematronic pour pondre cette carte...

Pour le dépannage, j'avais dans l'idée de procéder à reculons.
J'ai déterminé (voir plus bas) que le CPU est reseté sans arrêt.
Mon idée, c'est de remonter progressivement tous les signaux qui provoquent cette condition de reset affin d'en déterminer la raison.
Pour le moment, j'ignore si cette méthode est réaliste.

Le problème avec l'idée d'un systématisme dans le dessoudage + test + soudage support + remise en place du composant, c'est que je vais certainement me retrouver avec un grand nombre de supports sur le PCB, ce que j'aimerais éviter pour une raison purement esthétique. Oui je sais, c'est une raison débile, mais idéalement j'aimerais garder ce PCB au plus proche de son état d'origine, avec ses composants d'origine (pour ceux qui veulent bien encore fonctionner en 2010).

J'ai bien conscience que cette contrainte purement subjective complique le dépannage.

Cependant, en cas d'échec de ma méthode, je me rabattrai certainement sur la tienne, dans l'ordre que tu as décris car cet ordre me semble assez logique.

: gc339 Tuesday 05 January 2010, 14:22:44 PM

[couic]
C'est pour cela qu'un testeur de CI (IC tester) te serait des plus utile surtout si tu comptes dépanner tout le lot de cartes récupérées.
Ce genre d'équipement permet en plus de programmer et/ou de vérifier tout un tas de mémoires, voir par exemple les modèles VP280 et TOP2049 en vente sur un site d'enchères très connu.

Ca tombe bien, car je pensais justement acheter un progammateur d'EPROM.
J'avais vu le modèle G540 (USB, bleu) sur le même site d'enchères.
Le TOP2049 me semble pas mal.
Le test de composants TTL & RAM me sera utile.
Quel est le meilleur modèle, sachant que je ne suis pas à 40 € près pour cet achat ?
Autre point, aucun ne semble pouvoir lire & programmer les PAL (mais ils savent faire les GAL). Une idée du pourquoi ?
On trouve souvent des PALs sur les PCB de jeux, et ce serait bête de ne pas pouvoir les lire/copier.

Sinon, petite mise à jour de ce WIP d'endoscopie de CPU Cinematronic...

J'ai examiné la clock principale du PCB (environ 20 MHz), et je trouve le signal pas très rectangulaire :

(http://img1.uplood.fr/free/yphk_a.png) (http://www.uplood.fr) (http://img1.uplood.fr/free/80rr_ic011-broche10.png) (http://www.uplood.fr)

Le signal observé est entouré en rouge sur le schéma (extrait de la page 24).
Le 0 V de mon oscillo est à 2 divisions en partant du bas (repère entouré en rouge).
Heureusement que mon oscillo a suffisamment de bande passante (100 MHz) pour ces mesures.

J'ai également examiné le signal /RESET (extrait de la page 27) :

(http://img1.uplood.fr/free/3sgb_b.png) (http://www.uplood.fr) (http://img1.uplood.fr/free/load_ic070-broche05.png) (http://www.uplood.fr)

Donc il est sûr que le CPU est constament reseté.
Je n'ai pas pu mesurer la périodicité du reset.
Quand je ralentis la base de temps, l'oscillo perd de vue le pic à 0 V du signal avant que je ne puisse voir 2 signaux en même temps.
J'ai encore une carte à jouer avec la synchro (je peux synchroniser l'oscillo sur un front non visible à l'écran), mais je n'ai pas encore testé.

La partie "reset à froid" (power up) n'est pas en cause. Le signal est fixe à +5 V.

Une idée qui vaut ce qu'elle vaut :

mesurer le temps entre la fin du reset et le démarrage du CPU (fliquer les accès à une PROM du micro-ordonnanceur)
mesurer le temps entre le démarrage du CPU et le reset suivant
en déduire combien d'instructions assembleur le CPU a exécuté (fliquer les lectures dans la ROM de code du jeu)

Là, soit le CPU est reseté avant de lire le 1er op-code du jeu, soit il est reseté après N op-codes.
Peut-être que je pourrai déterminer quel op-code le fait planter et examiner les composants impliqués.
Le reverse-engineering des op-codes du CPU Cinematronic est totalement réalisé sous Mame.

EDIT: orthographe

: [WIP 10%] Borne vectorielle : Sega Space Ship
: maldoror68 Wednesday 06 January 2010, 11:01:31 AM

Autre point, aucun ne semble pouvoir lire & programmer les PAL (mais ils savent faire les GAL). Une idée du pourquoi ?

et bien tout simplement un pal n'est pas réinscriptible. selon wiki un Gal est Un PAL réinscriptible. cqfd

je cite:
"An innovation of the PAL was the generic array logic device, or GAL, invented by Lattice Semiconductor in 1985. This device has the same logical properties as the PAL but can be erased and reprogrammed."

:D

: [WIP 10%] Borne vectorielle : Sega Space Ship
: gc339 Wednesday 06 January 2010, 12:00:13 PM

N'ayons pas peur des mots : cette carte est une parfaite usine à gaz d'une complexité inimaginable ! [couic ]Je me demande combien de temps et de prototypes il a fallu aux gens de chez Cinematronic pour pondre cette carte...

Je pense surtout que c'est le micro-programme qui a du demander le plus de compétences pour la mise au point. L'architecture de la micro-machine est somme toute relativement standard.
Un seul prototype a du suffire s'il a été réalisé en mini-wrapping, il est très facile de modifier le câblage, d'ajouter/supprimer/remplacer une porte ou une fonction. Par contre il a peut-être fallu retoucher le circuit imprimé à plusieurs reprises pour éliminer des dysfonctionnements (temps de propagation du aux longueurs de pistes, équipotentialité des masses, parasites sur le + 5 volts ...) qui n'existaient pas avec le prototype en mini-wrapping.

Pour le dépannage, j'avais dans l'idée de procéder à reculons.
J'ai déterminé (voir plus bas) que le CPU est reseté sans arrêt.
Mon idée, c'est de remonter progressivement tous les signaux qui provoquent cette condition de reset affin d'en déterminer la raison.
Pour le moment, j'ignore si cette méthode est réaliste.

Pourquoi pas, tu peux dans 1^er temps voir quelle est la cause qui fait aboyer le chien de garde, eh oui ce dispositif de réinitialisation n'est pas autre chose qu'un chien de garde.
Entre parenthèses : il n'est pas exclus qu'il soit malade et réinitialise intempestivement la carte !
Puis avec de la chance et de la réflexion voir quel est le circuit défaillant. Même en cas d'insuccès tu auras toujours progressé dans la compréhension du fonctionnement de cette carte.

Le problème avec l'idée d'un systématisme dans le dessoudage + test + soudage support + remise en place du composant, c'est que je vais certainement me retrouver avec un grand nombre de supports sur le PCB, ce que j'aimerais éviter pour une raison purement esthétique. Oui je sais, c'est une raison débile, mais idéalement j'aimerais garder ce PCB au plus proche de son état d'origine, avec ses composants d'origine (pour ceux qui veulent bien encore fonctionner en 2010).
J'ai bien conscience que cette contrainte purement subjective complique le dépannage.

Alors dans ce cas, je ne vois que deux solutions :

Sois tu te mets en recherche d'un deuxième exemplaire de cette carte de jeu, pour pouvoir dépanner tranquillement la première. Et si le deuxième exemplaire est fonctionnel, ce ne sera que tant mieux.
Sois tu clones la carte, ce qui n'est pas une tâche insurmontable avec les logiciels de tracé de schéma et de PCB existants. Le plus difficile sera peut-être d'approvisionner certains composants comme les mémoires RAM. Après tout il y a peut-être des gens qui seraient intéressés par un clone encore inédit de cette carte ...

Puis tu achètes une vitrine en verre pour exposer la carte et commencer ta collection de cartes originales ...

J'avais vu le modèle G540 (USB, bleu) sur le même site d'enchères.

J'ai zieuté ses caractéristiques, apparemment il ne réalise que la fonction programmation.

Le TOP2049 me semble pas mal.
Le test de composants TTL & RAM me sera utile.
Quel est le meilleur modèle, sachant que je ne suis pas à 40 € près pour cet achat ?
Autre point, aucun ne semble pouvoir lire & programmer les PAL (mais ils savent faire les GAL). Une idée du pourquoi ?
On trouve souvent des PALs sur les PCB de jeux, et ce serait bête de ne pas pouvoir les lire/copier.

Je ne sais pas quel est le meilleur modèle sur les deux que j'ai cité.
Ils programment bien certains PAL, il suffit de rechercher avec le mot clef "PAL" dans la liste dont le lien est donné dans chaque annonce.
Par contre il n'y a pas de liste concernant les références des boîtiers TTL qu'ils peuvent tester.

J'ai examiné la clock principale du PCB (environ 20 MHz), et je trouve le signal pas très rectangulaire :

C'est tout à fait normal, les inverseurs fonctionnent en régime pseudo linéaire grâce aux résistances de 330 ohms disposées entre entrée et sortie, sinon le montage ne pourrait pas entrer en oscillation. Le flip-flop qui suit est là pour symétriser le signal en le divisant par deux et obtenir des flancs plus raides dignes d'un signal TTL.

Une idée qui vaut ce qu'elle vaut :
mesurer le temps entre la fin du reset et le démarrage du CPU (fliquer les accès à une PROM du micro-ordonnanceur)
mesurer le temps entre le démarrage du CPU et le reset suivant
en déduire combien d'instructions assembleur le CPU a exécuté (fliquer les lectures dans la ROM de code du jeu)
Là, soit le CPU est reseté avant de lire le 1er op-code du jeu, soit il est reseté après N op-codes.
Peut-être que je pourrai déterminer quel op-code le fait planter et examiner les composants impliqués.

Pourquoi pas, je ne crains qu'une seule chose : que tu progresses plus vite dans la compréhension du fonctionnement de la carte que dans son dépannage effectif !

J'ai déjà vu se faire le dépannage de ce genre de carte :

Sur site : la carte était sortie de son panier par un prolongateur, il y avait un connecteur en bout de carte pour enficher :
- Un outil comportant une cinquantaine de LED pour afficher ainsi tous les signaux névralgiques, il avait été baptisé du joli nom poétique de "yeux de rat".
- Un mini-pupitre pour faire avancer l'horloge en pas à pas ou par cycle, avec une sonde pour stopper l'horloge sur apparition d'un signal quelconque prélevé sur la carte.
En usine : la carte alimentée était disposé sur une "planche à clous". Les clous de la planche étaient en fait les pointes des sondes reliées au calculateur de la machine de test.
La machine de test devait soit imposer sa propre horloge soit prélever l'horloge de la carte pour synchroniser le test.
Par contre il semble me souvenir que les EPROM's de la carte étaient retirées pour ne pas entrer en conflit avec celles spécifiques au test. Ces dernières, situées dans la machine de test, étaient connectées à la carte à travers la "planche à clous".