[WIP 90%] Borne vectorielle : Sega Space Ship

[gc339]

Bonjour.

Au passage, est-ce que quelqu'un connait un genre de "catalogue" des composants TTL 74xxx ?
Je recherche un document PDF présentant le résumé du datasheet de tous les 74xxx, à raison par exemple d'un composant par page.
Je n'ai besoin que du brochage et de la description résumée du composant (table de vérité, etc...)

Ce qu'il te faut c'est une bible imprimée par le meilleur éditeur en la matière :

C'est un document papier qui rassemble tous les TTL produits par cette marque, il y a toutes les informations dont tu as besoin.
Tu peux en trouver sur le site d'enchères mondialement connu.
Préfères une édition des années 80..85 à une édition plus vieille : ces dernières ont l'épaisseur d'un dictionnaire car elles sont moins condensées et il y a moins de type de boîtiers, surtout ceux numérotés à partir de 200 comme le 74244.
Celle que j'ai prise en photo est une édition de 80 et elle pèse bien son poids ...

A+

[AsPiC]

Lut' tout d'abord bravo pour ton travail

Je ne sais pas si cela peux t'aider mais je viens de voir que arcadechips propose des ROM 6331 a la vente. Voici le liens au cas ou cela pourrai te dépanner :
http://www.arcadechips.com/product_info.php?products_id=64&osCsid=5272ddcda4fc1e08d25d9555afbbcf02

 

[gc339]

Bonjour.

De mon point de vue, je dirais que cette PROM est malade. Je ne pense pas qu'il soit normal que des bits du bus de données bagottent sur certaines transitions du bus d'adresse, alors que ces transitions n'affectent pas les valeurs à lire d'après le contenu de la PROM.
N'ayant pas un 2e PCB qui fonctionne, je ne peux pas tester les PROM accusées d'être malades sur un PCB témoin.
N'ayant pas la spécification technique détaillée de la PROM à fusible, je ne peux pas dire si son fonctionnement est en-dehors des spécifications :

• soit le constructeur indique qu'après une transition sur le bus d'adresse, tous les bits de données peuvent bagotter pour finalement se stabiliser à la valeur devant être lue ; dans ce cas le composant est conforme
• soit seuls les bits de données affectés par la transition sur le bus d'adresse doivent changer ; dans ce cas le composant est non-conforme

Il ne faut pas oublier que tous les bus sont rebouclés à travers des latches sensibles non pas à un niveau logique mais à une transition sur leur entrée d'horloge, ce qui oblitère pas mal de phénomènes transitoires.

Prenons par exemple ce cas bien particulier :

• Soit un compteur asynchrone en cmos standard relativement lente, genre CD4040, dont les sorties pilotent les adresses d'une PROM fusible. Il est bien évident qu'à chaque front négatif d'horloge sur l'entrée du compteur CD4040, ses sorties ne changeront pas d'état toutes en même temps, des "glitches" seront donc présents un court instant en sortie de la PROM fusible après chaque incrémentation du compteur.
• Si l'on connecte les entrées d'un module octuple latches comme par exemple un LS374 ou un HCT374 sur les sorties de la PROM fusible ainsi que son entrée d'horloge sur la même horloge que celle du compteur CD4040 : le compteur avancera sur les fronts descendants de l'horloge alors que les données de la PROM seront transférées simultanément dans les latches sur le front montant de ce même signal.

Les données en sorties des latches seront certes accessibles 1/2 période d'horloge plus tard, par contre elles seront "glitches-free" car les données en sortie de PROM fusible auront eu le temps de se stabiliser bien avant le front montant du signal d'horloge.

Donc prudence, il faut bien connaître le séquencement interne des transferts entre tous les circuits avant de tirer une conclusion trop hâtive.

A+

[High_Cobra]

Bonjour.

Ce qu'il te faut c'est une bible imprimée par le meilleur éditeur en la matière :

C'est un document papier qui rassemble tous les TTL produits par cette marque, il y a toutes les informations dont tu as besoin.
Tu peux en trouver sur le site d'enchères mondialement connu.
Préfères une édition des années 80..85 à une édition plus vieille : ces dernières ont l'épaisseur d'un dictionnaire car elles sont moins condensées et il y a moins de type de boîtiers, surtout ceux numérotés à partir de 200 comme le 74244.
Celle que j'ai prise en photo est une édition de 80 et elle pèse bien son poids ...

A+

J'ai une dizaine de docs comme ça aussi, de plusieurs fabricants, pour plusieurs types de composants, je peux jeter un oeil dedans si tu veux...

Et encore bravo pour ce topic de fou

[f4brice]

Bonsoir.

Mise à jour de ce WIP d'endoscopie du CPU Cinematronic.

Samedi et dimanche matin, j'ai fait un gros boulot sur la documentation.
Vu qu'elle est assez peu lisible par endroit, j'ai repris le schéma Cinematronics et j'ai ajouté pour la plupart des composants :

• la référence du composant sur mon PCB SEGA
• les n° des broches chaque fois que c'était illisible
• des annotations personnelles (d'ouske vient un signal, ouskiva, keskecé, etc...)

Y'a pas à dire, le "CCPU" (Cinematronic CPU) est une sacrée usine à gaz.
Il a été conçu par le sieur Larry Rosenthal, diplômé du MIT... Quelques infos sur cette page pour les curieux.

Déjà, j'ai compris un premier truc en regardant le code de l'émulateur du CCPU dans Mame.
Pour ceux qui ont les sources de Mame, regardez dans le fichier src/emu/cpu/ccpu/ccpu.c.
Il existe une instruction assembleur appelée "CST" (opcode $7F $F7) qui reset le watchdog. Sans cette instruction exécutée périodiquement, le CCPU est automatiquement reseté.
Il suffit au développeur du jeu de placer cette instruction à la fin de la boucle principale du jeu et le tour est joué.
Si le jeu ne démarre pas ou plante, alors le watchdog fera son boulot.

J'ai décidé, dimanche après-midi, d'arrêter de me peler les glaouis dans mon sous-sol et d'avoir les extrémitées engourdies.
J'ai temporairement déplacé mon banc de test de PCB dans mon bureau, chauffé :



Je peux bosser assis confortablement, j'ai toute la doc que je veux sous la main ou à portée de clic, et j'ai chaud !

Mes investigations ont continué en marche arrière sur le watchdog du PCB, pour être sûr qu'il n'est pas lui-même en panne et reset anormalement le PCB.
J'ai contrôlé à l'oscillo toutes les portes logiques impliquées dans le watchdog et je n'ai rien trouvé d'anormal.
Je n'ai pas cherché plus loin la raison d'aboiement du watchdog, car je sais maintenant que c'est une instruction assembleur non périodiquement exécutée qui en est la raison.

J'ai ensuite décidé de jetter un coup d'oeil d'oscillo sur les 3 puces de RAM.
Je me suis rendu compte qu'elles étaient assez peu sollicitées : leur bus d'adresse ne bouge presque pas.
J'ai alors essayé de comparer les données en entrée et les données en sortie, vue que les broches sont séparées.
C'est un peu blairométrique, mais je me suis dis que si je voyais un signal en entrée toujours à 0 ou à 1 ou bagotter et que la sortie correspondante n'avait jamais la même tête, alors peut-être que je devrais gratter un peu plus là.

Finalement, j'ai découvert que 3 des bits de donnée en entrée de la RAM avaient un niveau TTL fixe.
Je trouve que c'est assez peu plausible pour être honnête.

Extrait de la page 25

En rouge, ce sont les 3 entrées des puces de RAM qui ne bagottent pas K1, K3 et K10.
C'est peut-être un hasard, mais je n'y crois pas.
Entouré en vert, on voit 2 petites inscriptions "(2)". J'ai heureusement compris depuis un moment ce qu'elles signifient.
Elles indiquent que le composant qui génère ces signaux est situé page 2 des schémas.
Croyez moi, cette modeste information est particulièrement précieuse pour s'y retrouver.

Voici IC016 ("N2" chez Cinematronics), un des 3 composants qui génère le bus "K" dont 3 bits sont louches.
Celui-là est chargé de générer K0 à K3 :

Autre extrait de la page 25

Le composant en question est un 74LS257. Grosso modo, c'est un switch qui permet soit d'avoir K=A ou K=B selon la broche SELECT (entourée en bleu).
J'ai vérifié que cette broche SELECT est en permanance à l'état haut.
A priori, il semble que ce soit normal vu le fonctionnement dégradé du PCB actuellement.
La broche 15, entourée en vert, est la broche "/OUTPUT_CONTROL".
Il faut qu'elle soit à l'état bas pour que la sortie du composant soit valide. C'est bien le cas.

D'après le datasheet du composant, dans ces conditions (SELECT=1, /OUTPUT_CONTROL=0), je devrais avoir K1 (broche 9) = PA1 (broche 10).

Or voici ce que mon oscillo renifle :

Broche 10 : PA1	Broche 9 : K1

 

Il y a plusieurs conclusions possibles, qui ne sont pas mutuellement exclusives :

• le composant en question est en panne
• un autre composant, qui utilise le signal K1, est en panne ; ce composant impose un niveau haut sur le signal K1 (et tant pis pour IC016 qui a mal aux transistors)

À suivre :

• dessoudage du composant IC16 pour test individuel.
• pendant que IC16 est absent, mise en place d'une résistance de "pull-down" entre la masse et la broche 9 de l'emplacement de IC16 ; si un composant grillé impose un niveau sur ce signal, je trouverai un état haut malgré ma résistance

[gc339]

Bonjour.

Déjà, j'ai compris un premier truc en regardant le code de l'émulateur du CCPU dans Mame.
Pour ceux qui ont les sources de Mame, regardez dans le fichier src/emu/cpu/ccpu/ccpu.c.
Il existe une instruction assembleur appelée "CST" (opcode $7F) qui reset le watchdog. Sans cette instruction exécutée périodiquement, le CCPU est automatiquement reseté.
Il suffit au développeur du jeu de placer cette instruction à la fin de la boucle principale du jeu et le tour est joué.
Si le jeu ne démarre pas ou plante, alors le watchdog fera son boulot.

Cette information à piqué ma curiosité et j'ai donc sollicité Google avec les mots clefs suivants "ccpu mame cinematronics". Quelle ne fut pas ma surprise de voir que ce CCPU était parfaitement connu et bien doccumenté, il y a tout ce qu'il faut et dont on aurait pu rêver :

• Un assembleur pour ceux qui voudraient créer un jeu ou modifier un existant !
• Un désassembleur pour traduire en instructions intelligibles les lignes de code des ROM's
• Un simulateur ...

Le lien miraculeux : http://zonn.com/Cinematronics/

Les liens annexes :

• The Cinematronics CPU - Programmer's Reference Guide : http://zonn.com/Cinematronics/files/CineRef.pdf
• The Cinematronics Applications Programming Manual : http://zonn.com/Cinematronics/files/CineApplPgmMan.pdf

Pour exemple : le synoptique du CCPU

Tous ces documents devraient aider à la compréhension du fonctionnement du CCPU et permettre de faire une recherche de la ou des panne(s) qui soit un peu moins à l'aveuglette.
Un homme averti en vaut deux !

A+

[f4brice]

Bonsoir.

Voici une mise à jour de ce WIP.

Suite à ce message de gc339, j'ai récupéré les documents cités et je les ai parcourus.
Pour un CPU implémenté en portes TTL, les possibilités sont certes modestes, mais quand même assez puissantes.
La compréhension des possibilités du CPU a facilité celle du schéma électronique.
Ainsi je vois dans les grandes lignes à quoi servent certains signaux, la raison de l'agencement de certains composants, etc...

Depuis la dernière mise à jour, je me suis inscrit sur une liste de diffusion dédiée aux jeux d'arcade vectoriels : vectorlist.
Respectant les règles élémentaires de courtoisie, je me suis présenté et j'ai expliqué que j'étais en train de dépanner un PCB SEGA qui implémente un CPU Cinematronics.
Des gens très sympas m'ont acceuilli.
Leur compétence technique sur les CCPU est inimaginable.
L'une des personnes vend (je pense à titre privé) :

• une copie de l'Exorciser Cinematronics ; c'est un outil dédié au dépannage des CCPU qui fonctionne avec un appareil de mesure un peu particulier qui est un analyseur de signature ; le principe est d'injecter des signaux précis à des endroits précis sur le PCB et de regarder le résultat à certains autres endroits avec l'analyseur de signature
• des puces de remplacement pour les PROMs du CCPU

Une autre personne a répondu aussi à mes questions de manière extrêment précise et m'a conseillé pour la suite de mon dépannage.
Il s'agit de Mark SHOSTAK.
Cette personne travaille chez CineLabs, une société spécialisée dans... le dépannage des cartes à base de CCPU (entre autres) !

On m'a proposé de dépanner ma carte, mais j'ai décliné cette offre pour le moment, préférant le faire moi-même.
La personne de CineLabs a été très surprise de voir un CCPU sur un PCB SEGA.
J'ai donné le lien vers ce WIP, même si je pense que la langue restera un obstacle.
Il a été constaté sur les photos que mon PCB SEGA ne dispose pas des emplacements prévus par Cinematronics pour la mise en oeuvre d'un dépannage avec l'Exorciser.
On se demande donc comment les techniciens SEGA pouvaient bien faire pour dépanner ces cartes...
Les photos ont permis aussi de voir à quoi ressemble la borne SEGA.



Je reprends l'endoscopie du CCPU...

La dernière fois, j'avais identifié un problème majeur au niveau du bus "K", où 3 de ses bits étaient mauvais.

J'ai fait l'hypothèse que c'était la puce de RAM qui imposait l'état du signal via l'une de ses broches d'entrées.
J'ai donc dessoudé ce composant :



Notez que j'ai collé sur le PCB plein de petites étiquettes afin de retrouver instantanément un composant à partir de sa référence sur le schéma Cinematronics.

Ensuite, j'ai mis un support à la place, pour pouvoir remettre et retirer le composant à ma guise.
Problème : ce composant a un écartement entre ses 2 rangées de broches de 0,4 pouces, ce qui est assez peu courant (0,3 pouces est largement plus courant) :



N'ayant que des supports de 0,3 ou 0,6 pouces de large, j'ai utilisé le système D...

Déjà, il faut 2 × 22 = 44 broches, ce que je n'ai pas.
Donc, je prends un support de 14 broches et un autre de 8 :



Puis je sépare les rangées avec une pince coupante :



Pour pouvoir tout souder tranquillement, je joue aux Légos avec d'autres supports.
Les autres supports apportent un maintient mécanique et le bon écartement :



Et voilà :



Ensuite, je refais la mesure, avec le composant absent.
Si c'était lui qui imposait le niveau haut, son absence doit permettre de retrouver un signal normal.

Finalement, le problème que j'avais observé est toujours présent.
Je décide donc de tester le composant chargé de générer les bits malades.
Il s'agit de N2, soit IC16.

Je le dessoude :



Puis je soude un support et replace le composant sur le support.
Je plie légèrement la broche de sortie que je pense être malade, de sorte à l'isoler du reste du circuit.



Après test, il apparaît bien que le composant est malade.
Il a 2 sorties qui restent en permanance à l'état haut alors qu'elles devraient bagoter.
J'ai 2 de ces composants sur les 3 installés qui ont un problème.
A chaque fois, j'ai vérifié en isolant la broche (méthode du pliage) et en vérifiant son niveau.
J'ai vérifié que le signal sur le PCB était à un niveau "non positionné", soit environ 2,5 V. Pour moi, aucune entrée d'un autre circuit ne "tire" ce signal anormalement vers la masse ou vers VCC.

Ce matin, le crémier m'a vendu 2 composants neufs que j'ai mis sur les supports soudés la veille :



Après mise en route et test, je constate qu'il n'y toujours pas de commande sur les bus X et Y qui communiquent avec l'écran.
Je jette un coup d'oeil sur le reset, et effectivement, le chien de garde continue d'aboyer.
Le CCPU est toujours réseté périodiquement.

Il y a donc une autre panne et je m'en doutais un peu.

Je reprends donc les investigations autour des puces de RAM L14, M14 et N14.
Cette fois, je me rends compte qu'une des sorties de L14 est complètement à l'ouest.
Elle bagotte correctement puis me fait un beau signal analogique particulièrement esthétique, mais pas du tout TTL...
Il s'agit de la broche n°16 qui correspond à la sortie du 4e bit de données (signal "W3" sur le schéma Cinematronics).

Malheureusement, j'ai fait une fausse manip avec la sonde de l'oscillo.
Tel le soldat Pithivier dans la 7e Compagnie, « j'ai glissé chef ! »...
La sonde a glissé et a fait contact entre la broche 16 (O3) et sa voisine la broche 17 qui est reliée à VCC.
Bilan : fini le beau signal analogique totalement anormal ; j'ai maintenant un signal TTL qui bagote comme les autres.
Le PCB ne fonctionne ni mieux ni moins bien suite à ça, mais je pense avoir quand même grillé un peu plus le composant.

Voici la scène reconstituée :




Je pense que je vais passer commande chez Arcade Chips.
Les puces de RAM en question sont disponibles pour 1,5 dollar pièce.
Je vais en profiter pour commander aussi quelques composants spécifiques pour l'écran X-Y.


À suivre...

[maldoror68]

je suis toujours subjugé comme tu te lance la dedans...
on dirai Gandalf qui fait du Base Jumping dans une Moria de composants, dans un abime électronique...

je suis vraiment fan de ce topic, même si je comprends que pouic  


il faut quand même que je pose une question:

le modèle de cinématronic est bien antérieur à celui de sega? on peu donc penser (raisonablement) que celui de sega est basé sur le modèle cinématronics. l'architecture et la présentation des composants est quasi la même, alors pourquoi CNM (j'abrège cinématronics) à laissé une porte de service sur sa carte et pas Sega ?

n'empèche que si ça continue, le plus simple serai de "ressortir" toutes les roms de mame, de remmettre TOUTES les puces à neuf avec l'aide d'un prog d'eprom, de tout ressouder et de tester. ça eviterai de t'arracher les cheveux dans cette architecture en boucle qui rend toute analyse quasi impossible...

ce serai possible et pas trop onéreux  ??  du coup après la panne ne pourrai venir plus que d'une piste ou d'un condo / résistance...

[f4brice]

le modèle de cinématronic est bien antérieur à celui de sega? on peu donc penser (raisonablement) que celui de sega est basé sur le modèle cinématronics. l'architecture et la présentation des composants est quasi la même, alors pourquoi CNM (j'abrège cinématronics) à laissé une porte de service sur sa carte et pas Sega ?

Cette carte réalise un CPU. Le terme adéquat est l'anglicisme "implémenter". Le jeu qui est dedans s'appelle Space Wars.
Ce CPU est une architecture électronique dédiée aux jeux vectoriels.
Le schéma du CPU et le jeu Space Wars ont été conçus par une personne nommée Larry Rosenthal.

Rosenthal a vendu une licence d'exploitation à Cinematronics, mais a conservé la propriété intellectuelle.
Cette carte a pris le nom de "CCPU" (Cinematronics CPU) bienque Cinematronics n'en soit pas le concepteur ni le propriétaire intellectuel.
Il y a 2 possibilités :

• Rosenthal a vendu une license aussi à SEGA
• SEGA a acheté un droit à Cinematronics

Dans les 2 cas, SEGA a certainement récupéré l'industrialisation (production de série), donc aucune raison d'avoir une implantation différente.
Je pense que SEGA a fait une modif mineure au niveau des PROMs de jeu certainement pour adresser soit un problème de coût de composants, soit un problème d'approvisionnement.
SEGA n'a pas jugé utile de prévoir les emplacements pour la connection de l'Exorciser.
Peut-être n'ont ils pas acheté la licence d'utilisation de l'outil, peut-être qu'ils disposent de leur propres outils (planche à clous par exemple).

n'empèche que si ça continue, le plus simple serai de "ressortir" toutes les roms de mame, de remmettre TOUTES les puces à neuf avec l'aide d'un prog d'eprom, de tout ressouder et de tester. ça eviterai de t'arracher les cheveux dans cette architecture en boucle qui rend toute analyse quasi impossible...

ce serai possible et pas trop onéreux  ??  du coup après la panne ne pourrai venir plus que d'une piste ou d'un condo / résistance...

Une personne ayant une très grande expérience dans le dépannage des cartes CCPU m'a indiqué que si le contenu d'une PROM était bon, alors il y avait 99,9% de chances que la PROM fonctionne.
En 15 ans de dépannage de CCPU, il n'a jamais vu une PROM déconner alors que son contenu était bon.

Pour infos, les PROMs présentes sur le PCB ne sont pas des EPROM.
Les PROMs ne sont programmables qu'une et une seule fois et ne peuvent pas être effacées.
Lorsqu'elle est vierge, elle comporte tout une structure de micros-fusibles que l'on vient détruire lors de la programmation. C'est donc irrémédiable.


Je ne m'arrache pas trop les cheveux. J'ai trouvé une méthodologie et une technique de mesure qui semblent bien fonctionner :

• j'ai trouvé rapidement les 2 pannes des composants IC16 et IC20
• j'ai trouvé rapidement la panne sur IC145

Mon problème aujourd'hui est un problème de disponibilité de composant pour remplacer IC145.
C'est un composant de RAM de la fin des années 70 / début des années 80.
Je dois le commander dans une boutique aux États-Unis.
J'attends lundi prochain pour passer commande. J'aurai peut-être des composants supplémentaires à commander pour le PCB Space Invaders de ZBP.



Je profite de ce message pour une petite mise à jour du WIP.

J'ai re-testé à l'oscillo la sortie malade de la puce de RAM IC145.
À ma grande surprise, le beau signal analogique, preuve de la panne, est réapparu.
Cette fois, j'ai pu faire 2 captures d'écrans, à des fréquences de balayage différentes :

IC145 (L14), broche 16 (Out4)

Normalement sur cette broche, je dois avoir un signal TTL, c'est a dire dont la tension est soit d'environ 0 V (conventionnellement appelé "0"), soit environ 4 à 5 V (conventionnellement appelé "1").
Or je vois un signal qui fait un peut n'imp...


J'ai fait le test de plier la broche suspecte avant de replacer le composant sur son support.
Là, j'ai un signal propre sur la broche isolée.
Du coup je me dis que c'est un autre composant qui est malade et qui vient polluer le signal.
Mais pourtant, si je mesure le signal dans ces circonstances, je le trouve à une valeur intermédiaire, signe qu'aucun circuit ne tente de lui imposer une valeur.

Je pense que lorsque le CCPU fonctionne avec la broche de RAM isolée, il doit planter encore plus tôt et je n'ai pas la même signature.

[f4brice]

Bonjour.

Voici une petite mise à jour de ce WIP, en attendant zebassprophet qui est sur la route pour arriver chez moi.

Des personnes de la liste de diffusion vectorlist m'ont demandé des photos du panel de la borne.
Voici :

Panel de la borne

Il existe un panel US dessous...

Vue de dessous, joueur de gauche

Vue de dessous, joueur de droite

On constate qu'il y a de nombreux emplacements vides dans le panel US pour tous les boutons normalement prévus pour ce jeu.
SEGA, en recouvrant le panel US par un panel FR a décidé de masquer certains emplacements pour des boutons.
Il y a donc de nombreuses options de jeu qui sont innaccessibles. 

[f4brice]

Bonjour encore.

Voici une mise à jour supplémentaire de ce WIP.

Merci à nicolas-le-jardinier qui m'a scanné et envoyé par mail les pages de la doc Cinematronic que je lui avais demandées.
Le scan est de qualité, ainsi j'ai accès à la doc avec la qualité d'origine.
Par endroit le schéma est lisible, à d'autres non. Mais au moins le problème n'est plus dû au document numérisé.
Ce scan me servira pour lire certaines parties du schéma écrites en tout petit, souvent illisibles sur le 1er document que j'ai récupéré.
Il faut savoir que le document original est souvent une photocopie de photocopie, réduite qui plus est.
Elle ne peut donc pas avoir la précision du schéma original.

J'ai décidé de tester le contenu des PROMs du PCB :

• les 6 PROMs qui implémentent le micro-ordonnanceur du CCPU
• les 8 PROMs qui contiennent le code assembleur du jeu "Space Wars"

Pour ça, j'ai dû dessouder ces 14 circuits intégrés...
De plus, je voulais aussi faire quelques manip avec les puces de RAM. j'ai donc dessoudé les 2 dernières puces (sur les 3 présentes en tout).

Cette modeste photo est en fait le résultat de plusieurs heures de travail sur le PCB :

Composants dessoudés

• à gauche : les 2 dernières puces de RAM maintenant dessoudées
• au centre : les 8 PROMs qui contiennent au total les 4096 octets du code assembleur du jeu
• à droite : 5 des 6 PROMs qui implémentent les signaux internes du micro-ordonnanceur du CCPU (la 6e était déjà dessoudée)

En regardant la référence des PROM SEGA ("PR-03", etc...), je me demandais si SEGA utilisait des numéros uniques pour toute PROM/EPROM de jeu.
Par exemple, "EPR-7457" est une référence à priori unique, présente sur les PCB Quartet.
Si c'est bien ça, j'ai sur ce PCB la 3e référence de ROM SEGA. 
Pas forcément la 3e ROM de l'histoire de SEGA, mais peut-être la 3e ROM depuis que SEGA a adopté ce système de numérotation.

Voici l'emplacement des PROMs du jeu :

Il manque 2 pastilles de cuivre sur IC84. C'est sans conséquence pour l'électronique.
Je ne pense pas être le seul responsable de cet incident.
Les PROMs avaient des traces évidentes de soudure à la main.
Probablement qu'elles ont été dessoudées déjà une première fois, et que la personne ayant fait ce travail n'a pas consacré la même minutie que moi dans cette opération.
Malgré tout le soin observé durant cette intervention, 2 pastilles se sont arrachées.


Voici le PCB avec des supports, et les composants dessoudés installés respectivement à leur emplacement d'origine :

Composants sur supports

Au début, je ne voulais pas trop mettre de supports pour garder le PCB au plus près de son état d'origine.
Je l'ai fait à contre-coeur, car je dois absolument vérifier le contenu des PROMs et pouvoir en changer une facilement le cas échéant.
Mon modeste stock de supports divers a pris une claque. Il reprendra son niveau standard dès ma prochaine visite chez le crémier ou ma prochaine commande chez Électronique Diffusion.

Un essai rapide avec vérifications à l'oscillo à certains point clés m'a confirmé que cette opération de dessoudage / supports / remise en place n'a pas provoqué de panne supplémentaire.


À suivre :

• dump du contenu des PROMs, comparaison avec le dump récupéré chez Andy's Arcade
• commande chez Arcade Chips ; j'attends de mettre les pattes dans le PCB de SI de zebassprophet pour compléter ma commande et la transmettre

[maldoror68]

je redéterre ce topic que j'apprécie tant 

alors ? comment va la Space Ship?

[f4brice]

Bonjour.

Le WIP de réparation de cette borne continue petit à petit.

J'ai dumpé toutes les PROMs de 32 × 8 bits :

Contenu des PROM 32 × 8 bits

Je n'ai scanné que le recto de mon document. Il y a un 5^e dump au verso.

Je me suis rendu compte qu'un des bits d'une EPROM n'avait pas les valeurs attendues dans 16 cas sur 32 possibles.
Ma PROM sort un "0" logique (état bas) alors que d'après le dump trouvé sur le net, je devrais avoir pour ces 16 cas un "1" logique (état haut).
Les valeurs louches dans mon document ont un coin noirci.
J'ai d'abors crû à un problème de l'EPROM.
Mais depuis hier soir cette nuit, je ne suis plus aussi sûr.
Peut-être s'agit-il plutot d'une spécificité propre à mon PB SEGA, car cette différence de contenu de PROM est indirectement liée à un écart de conception électronique par rapport au schéma "de référence" qui est le schéma Cinematronic.
Voir plus bas dans ce même message quel est cet écart.

Le dump "manuel" des PROMs s'arrête là.
Pour toutes les autres, il me faudra un système "semi-automatique" où c'est un compteur TTL qui génère le bus d'adresse.
J'incrémenterai le compteur avec un simple montage flip-flop.
Je suis toujours en attente de mon programmateur d'EPROM acheté en Chine via un site d'enchères mondialement connu.
C'est le moment de placer une de mes contrepétries favorites : "il arrive à pied par la Chine".  


La suite du WIP, c'est un débuggage pas à pas de l'électronique du CCPU.
L'idée est la suivante :

• tout le PCB est cadencé par un unique oscillateur à environ 20 MHz
• je désactive cet oscillateur le plus proprement possible
• je mets en place un bouton poussoir qui va permettre de manuellement générer le signal de CLOCK à la place de l'oscillateur
• pour des raisons de rebond, le signal électronique du bouton poussoir serait moche et génererait plusieurs CLOCK pour un unique appui
• j'installe un système anti-rebond (flip-flop) entre le bouton poussoir et l'entrée CLOCK du PCB

C'est un peu comme un film qui serait en mode pause.
Mon bouton, c'est la télécommande qui me permet d'avancer image par image au rythme où je veux.
J'ai ainsi le temps de faire toutes les investigations que je veux avant de passer à l'étape d'après.

La réalisation de l'anti-rebond est identique à ce schéma (voir "Bascule à CD4011") sauf que je dois utiliser un 74LS00 (techno TTL) qui est l'équivallent du CD4011 (techno CMOS).


Voici le 1er étage de l'oscillateur du PCB :

1er étage de l'oscillateur

Il est constitué d'un quartz, d'un condensateur, de 2 résistances et d'un boîtier 74LS04 (6 portes inverseuses).

Je pensais, tel un bourrin de base, dessouder le 74LS04, mais ce n'est pas nécessaire. Il suffit de dessouder le quartz et une résistance :

Quartz et résistance retirés

Ensuite je prépare mon 74LS00 pour une installation par-dessus un circuit déjà soudé.
C'est ce qu'on appelle dans le jargon électronique une "verrue".

J'ai mis à l'horizontale toutes les broches sauf la 7 (GND) et la 14 (VCC).
En le placant au-dessus d'un boîtier TTL à 14 broches pas trop exotique, les broches 7 et 14 vont tomber pile en face de ce que je veux.
Ensuite, il me reste à cabler le bouton poussoir et le flip-flop.

J'ai maintenant un PCB qui ne peut fonctionner qu'en pas à pas.
Dès la mise sous tension, il... ne fait rien.
Il est simplement figé, faute de signal d'horloge.
C'est mon doigt qui va remplacer les vibrations d'un cristal de quartz.


Maintenant que mon PCB ne sait faire que du pas à pas, l'idée est la suivante :

• alimenter le PCB
• regarder la 1ère instruction qui est lue dans la ROM du jeu
• regarder dans le guide de référence du CCPU que fait cette instruction
• fliquer son exécution par le PCB
  
  • si c'est par exemple le chargement de la constante 0xF4B dans l'accumulateur A, je dois voir cette valeur s'écrire dans les 3 boîtiers latch qui correspondent à l'accumulateur (M4/IC37, P4/IC39 et S4/IC41 en l'occurence)

C'est donc là que j'ai regardé en détail l'agencement des 8 PROMs qui contiennent le code du jeu.
C'est là l'une des principales différences avec le schéma de référence :

• Cinematronics utilise 4 boîtiers EPROM 2616, chaque boîtier fait 1024 × 8 bits
• SEGA utilise 8 boîtiers PROM MB7054 ou 7643, chaque boîtier fait 1024 × 4 bits

Correspondance EPROMs Cinematronics / PROMs SEGA

SEGA a associé les boitiers 4 bits deux par deux pour faire l'équivallent d'un boîtier 8 bits.
Le bit A11 (à gauche sur le schéma) passe bien par une porte spéciale (boîtier TI SN74265) qui assure 2 sorties complémentaires et parfaitement synchrones. Ces 2 sorties sélectionnent les boîtiers PROMs quatre par quatre comme sur mon schéma.
Attention : cette entrée de sélection est active à l'état bas :

• A11=0 va sélectionner PR-07, PR-08, PR-03 et PR-04
• A11=1 va sélectionner PR-09, PR-10, PR-05 et PR-06

Par contrel la bascule JK (en bas à droite) est absente du PCB SEGA, les 2^e entrées /CS des 8 boîtiers PROMs sont en permanance à l'état bas.

Ce qui est bizarre, c'est que d'après le schéma original Cinematronic, si la bascule JK ne sélectionne pas la bonne paire de boîtiers EPROM (U7+R7 ou bien T7+P7), alors selon la valeur du bit A11, on risque de lire "dans le vide" (aucun boîtier sélectionné) :

• hypothèse : la sélection de page (bascule JK) sélectionne les boîtiers U7+R7
• une adresse 0xxxxxxxxxxx (A11=0) est lue : A11 va sélectionner T7+P7
• in fine, aucun boîtier n'est sélectionné et la lecture se fait dans le vide...

Bizarre...
La conception du CCPU permet d'avoir plusieurs "pages" de code en ROM. Peut-être que mon schéma est incomplet ?


Pour en revenir à mon PCB SEGA, là je n'ai pas de doute : la sélection de page de ROM n'existe pas, et c'est seul le bit A11 qui choisit la quadrette de boîtiers PROM.

Grâce à nicolas-le-jardinier qui m'a scanné son document Cinematronic, j'ai le contenu du code du jeu (sous forme hexadécimale) facilement accessible :

Le jeu commence par le code machine "49 E7".
Un petit tour par le "Programmer's Reference Guide" du CCPU (voir ce message de gc339), et je sais que :

• 49 E7 = "LDJ #7E9", soit charger la constance 0x7E9 dans le registre "J"
  (je n'ai pas réussi à trouvé où était stocké ce registre J sur le PCB...)

Par contre, dès la 1ère instruction, ça chie déja...
Au lieu de lire "49 E7", mon CCPU lit "09 E7".
En effet, j'ai découvert que le bit D2 de la PROM PR-08 semble malade.
Quand il veut passer à l'état haut, il se positionne à peine à 0,5 V...
Je dois investiguer si la PROM est en cause, ou si le signal est bouffé par un autre composant.

Du coup, le CCPU exécute :

• 09 E7 = "LDA #900" suivi de "ADD [ i]"

Je flique les boîtiers U11 et T11...
C'est bon, leur entrée SELECT est à l'état bas, ils laissent passer les boîtiers "pairs". Tout va bien.

Je flique le boîtier S13...
C'est bon, "on" l'active bien (/LDR passe à 0).
Je regarde sur le front montant de la CLOCK (j'appuie sur mon bouton)...
Et paf ! Sur le front montant de la clock, les sorties du latch changent, mais pas avec les données qu'on lui a présentées :

• les 4 bit de poid faible de S13 auraient dus être chargés avec "1001", soir "9" en hexa
• j'ai pas "1001" en sortie du latch...

Ben ça commence fort, ce mode pas à pas...
Ce n'est pas la bonne instruction qui est lue.  
L'instruction exécutée à la place ne l'est même pas correctement...  


A suivre :

• diagnostic pour PR-08 : malade ou signal bouffé par un autre composant ?
• diagnostic pour S13 : vraiment malade ?

Merci à gc339 pour ses conseils : j'aurais inutilement dessoudé le composant I2, inutilement utilisé 2 boutons poussoirs alors qu'un seul suffisait.  

[gc339]

Bonjour.

Je me suis rendu compte qu'un des bits d'une EPROM n'avait pas les valeurs attendues dans 16 cas sur 32 possibles.
Ma PROM sort un "0" logique (état bas) alors que d'après le dump trouvé sur le net, je devrais avoir pour ces 16 cas un "1" logique (état haut).
Les valeurs louches dans mon document ont un coin noirci.
J'ai d'abord crû à un problème de l'EPROM.
Mais depuis hier soir cette nuit, je ne suis plus aussi sûr.
Peut-être s'agit-il plutôt d'une spécificité propre à mon PB SEGA, car cette différence de contenu de PROM est indirectement liée à un écart de conception électronique par rapport au schéma "de référence" qui est le schéma Cinematronic.
Voir plus bas dans ce même message quel est cet écart.

Comme quoi il faut toujours se méfier, le jeu cloné n'est pas toujours une copie conforme

C'est mon doigt qui va remplacer les vibrations d'un cristal de quartz.

Il ne va pas faire que remplacer la vibration du quartz, il va aussi faire osciller dangereusement cet "échafaudage" à chaque appui sur le bouton poussoir, ce n'est pas très prudent ! Il eu mieux valu fixer le bouton poussoir sur une petite équerre métallique boulonnée dans un des trous de fixation du PCB (j'en ai ai au moins distingué deux sur les photos, un dans chaque angle, sur le bord opposé au connecteur).

[gc339]

Bonsoir.

je n'ai pas réussi à trouver où était stocké ce registre J sur le PCB...

2.3.5 The ‘J’ register

The CPU’s jump opcodes do not, in themselves, contain the destination addresses of the jumps. Instead all jumps jump to the address contained in the ‘J’ register, which must be loaded previous to the execution of a jump instruction.

Il ne faut pas faire une fixation sur la notice du "Space Wars" et ne pas hésiter à aller bouffer à tous les râteliers consulter les autres notices de jeux à base de CCPU.

Par exemple la notice du "Star Castle" est beaucoup plus prolifique à ce sujet :

• Selon la page 6-2 de cette notice, affichant le synoptique général, le registre baptisé "J" dans le "Programmer's Reference Guide" du CCPU devrait être le registre "ADDRESS REGISTER" numéroté "16", le PC ou compteur ordinal devant être le registre "ADDRESS COUNTER" numéroté "15"
  

• La page 6.6 paragraphe 16 lève le doute : "This register is a latch used for temporary storage of an address which will be loaded into the program counter during a jump instruction".
  

CPU BOARD page 6.3 + Page 6.4

Page 6.5

Page 6.6

Page 6.7

• Et la page 6.7 énumère l'emplacement physique de chaque boîtier impliqué dans le bloc "16" du synoptique : P13 et R13.
  

Comme tous les circuits imprimés à base de CCPU Cinématronics sont pratiquement identiques quelque soit le jeu ou leur indice de version, il n'y a plus aucune difficulté à repérer ces boîtiers sur le schéma du "Space Wars" et à retrouver leurs emplacements sur le circuit imprimé Sega du "Space Ship".

[zebassprophet]

t'es un grand bourrin f4brice, tu es reelement impressionant niveau electronique
( de même pour gc339 , mais j'ai plus eu l'occasion de voir le travail de F4b)

bonne chance pour la suite