Gamoover

[move]Pour vous aussi la chipo ne sera jamais qu'un bootleg de merguez (c)sushy18 ? Alors soyez les bienvenus sur Gamoover ! [/move]

[WIP 90%] Borne vectorielle : Sega Space Ship

Démarré par f4brice, Jeudi 31 Décembre 2009, 16:57:03 PM

el_nino

Citation de: zebassprophet le Samedi 23 Janvier 2010, 22:07:07 PM
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 :)

Ils doivent avoir des chromosomes en commun avec  ceux ci
Mes blogs :
Vide grenier, Import, Arcade - http://doudougomgom.blogspot.fr/
Système Lindbergh : http://sega-lindbergh.blogspot.fr/
Système NAOMI : http://arcade-sega-naomi.blogspot.fr/

nicolas-le-jardinier

Pour la doc exact c'est une photocopie, il est mentionné au debut du doc que le manuel n'est plus dispo, les premieres pages sont d'ailleurs tres artisanales, shéma de la machine preque a main levé...
En tout cas content que ca puisse te servir.

f4brice

#82
Bonjour.

Petite mise à jour vite faite...

J'ai passé ma soirée et ma matinée à faire faire du pas à pas au PCB SEGA.
A chaque fois, je regardais l'adresse lue en ROM, la donnée lu, et comment cette donnée est traitée.

J'ai un peu avancé dans le dépannage et beaucoup plus dans la compréhension du CCPU...
La notice du jeu "Star Castle" dont le lien a été donné par gc339 m'a bien aidé aussi.

Déjà, j'avais vu qu'au lieu de lire l'instruction "49 E7", mon PCB lisait "09 E7".
J'ai découvert qu'il s'agit d'un problème avec la PROM PR-10.
Normalement, c'est PR-8 qui est sélectionnée pour toutes les adresses de 0x000 à 0x7FE (1ère motiée des ROM) et PR-10 pour celles de 0x800 à 0x8FE (2e moitiée)
Mais PR-10 a un problème. C'est soit un problème de sélection, soit un problème sur au moins 1 de ses 4 bits de sortie.
Alors qu'elle n'est pas sélectionnée, elle impose une valeur par-dessus celle de PR-08.
J'ai viré temporairement PR-10 (mon CCPU est loin d'être en état d'atteindre le code situé en 0x800).
Maintenant, il lit bien l'instruction "49 E7" comme prévu.


Broche 12 de PR-10 isolée, celle de PR-08 peut à nouveau s'exprimer

Je verrai plus tard ce qu'il en est exactement de PR-10 :

  • /CS0 ne répond plus => problème de sélection => peut-être que je peux utiliser /CS1 ?
  • un ou plusieurs bits de données est en permanence à l'état bas => problème de sortie => composant mort
Ceci pourra être investigué en-dehors du PCB sur ma plaquette de tests à trous.

Le débuggage du CCPU a donc pu continuer.
Maintenant qu'il lit la bonne donnée contenue dans les PROM, il peut l'exécuter :
"49 E7" = "LDJ #7E9" (charger la constante 0x7E9 dans le registre J).
Grâce à la doc Star Castel, je sais dans quels composant est stocké ce registre.
Il s'agit de P13 (registre à décalage bidirectionnel de 4 bits, mais utilisé ici comme un simple latch de 4 bits) et de R13 (gros latch velu de 8 bits).
Si tout va bien, je dois voir la valeur en question être écrite dans ces composants.

Sauf que hier soir, j'ai un peu abusé des datasheets, des schémas et de l'oscillo. Mes neuronnes ont fait un "motor trouble" et j'en étais resté à être persuadé que cette valeur "7E9" devait aller dans l'accumulateur "A", soit M4, P4 et S4 (c'était vrai tant que PR-10 mettait le bin'z et induisait d'erreur le CCPU, mais je l'ai virée).

Ce matin, à tête reposée, j'ai compris que je ne regardais pas au bon endroit...

Le débuggage va pouvoir continuer.

J'ai installé le 1er oeil de rat :


C'est une LED de 3 mm (obligatoirement rouge, sinon ce n'est plus un oeil de rat) qui reflète l'état de la clock du PCB.
J'ai préféré la commander par un petit transistor pour ne pas surcharger le boîtier 74265.

A suivre...

philougames

je n'ai qu'un mot ,impressionnant  ^-^ ^-^ bon courage a toi  <:)

f4brice

#84
Bonsoir.

Voici encore une mise à jour de ce WIP de dépannage de CCPU.

J'ai poursuivi l'étude du fonctionnement pas à pas du CCPU.
Mon but est de suivre au plus près le déroulement de l'exécution des instructions contenues dans les ROM du jeu.
Bien sûr il y a de quoi y passer un vie entière, mais je me limite aux premières instructions pour le moment.
Si un composant est malade, je dois pouvoir le détecter grâce à cette méthode.

Si une instruction ne fait pas intervenir un composant malade, alors son exécution se déroulera sans accroc telle un plan du célèbre colonel Hannibal Smith.
J'ai donc dans l'idée, plus tard, de flasher mes propres EPROMs avec les instructions que je veux voir exécutées par le CCPU.
Le fait d'être en mode pas à pas me permettra d'utiliser des EPROMs de n'importe quelle vitesse.
Il y a une quarantaine d'instructions possibles, ce serait bien la poisse si toutes ont un problème.

Le CCPU charge dans un registre l'instruction courante à exécuter.
Vu qu'il est important de savoir quand ce registre est écrit, j'ai ajouté un 2e oeil de rat :


Oeil de rat sur le signal "/LIR"

La LED matérialise le signal "/LIR" qui permet d'écrire dans le registre d'instruction.
Je suppose que ça veut dire "Load Instruction Register".
Quand ce signal est actif (état bas), le latch T13 mémorise, lors du prochain front montant de sa clock, la prochaine instruction à exécuter.
Si l'instruction comporte un 2e octet, alors ce 2e octet est traité dans le(s) cycle(s) suivant(s).

Voici tout ce que j'ai tracé pas à pas :


HexaAssembleurDescriptionStatutCommentaires
49 E7LDJ #7E9Charger le registre J avec 0x7E9OK J'ai vu "1001" être chargé dans P13 et "0111.1110" dans R13.
8ALDP #ASélection page RAM n°AOKJ'ai vu "1010" être écrit dans H12
1BINP BLecture entrée n°B (touche "0" du panel)OKLa touche n'étant pas appuyée, la résistance de pull-up a fait son boulot ; "1" est apparu dans le bit de poid faible de l'accumulateur
ECLSLDécalage logique accumulateur 1 bit vers la gaucheOKLes 2 bits de poid faible de l'accumulateur sont devenus "10"
ECLSLDécalage logique accumulateur 1 bit vers la gaucheOKLes 3 bits de poid faible de l'accumulateur sont devenus "100"
ECLSLDécalage logique accumulateur 1 bit vers la gaucheOKLes 4 bits de poid faible de l'accumulateur sont devenus "1000"
58JMPSaut à l'adresse pointée par le registre JKOL'adresse était mauvaise ; le CCPU est parti en 0x7ED (au lieu de 0x7E9, soit 1 bit de différence comme par hasard)

Mais diantre comment l'adresse du JMP (jump) peut-elle être mauvaise alors que j'ai vu (enfin, c'est plutot mon oscillo qui l'a vue) la bonne valeur être chargée dans P13/R13 ???
Quand j'ai examiné la valeur "1001" être écrite dans P13, j'avais remarqué que son 3e bit avait une tête patibulaire mais presque :


bit 3 de P13 après chargement de l'adresse

1,2 V pour un état bas TTL, c'est vraiment louche.
Je ne pensais pas que ce pût être catastrophique, car je croyais que les entrées TTL voulaient au moins 3 V pour considérer un état "haut".
Finalement, rien de mieux que de se référer à une spécification technique. Au moins, on sait de quoi il est question :


Extrait de la spécification Fairchild du 74LS00

Il faut minimum 2,0 V pour qu'un signal soit considéré à l'état haut. Pas de souci avec ma valeur de 1,2 V.
Il faut maximum 0,8 V pour qu'un signal soit considéré à l'état bas. Bon, bin là c'est le drame...
Mon signal de 1,2 V n'est ni haut ni bas... Il n'a aucune valeur TTL...

En laissant le CCPU s'exécuter à peine plus loin, je me rends compte que ce bit foireux passe à l'état haut sur le front descendant du signal appliqué sur la broche 11 du composant :


Bit tout vilain qui fait déconner le CCPU

Là, c'est carrément répréhensible. La doc du composant indique que rien n'aurait dû se produire sur un front descendant.
Non seulement S0 et S1 étaient tous les deux à 0 (donc aucun changement sur les sorties) , mais le composant ne change d'état que sur les fronts montants :


Extrait de la spec technique du 74LS194


Bon, bin voilà. J'ai un 74LS194 malade à changer...  8)


jujusl

Très intéressant et didactique :-*
Ca me rappelle mes cours d'informatique à la fac (20 ans déjà...  :'()
:D

speedsterharry

Quelle débauche de talent pour trouver le composant à 3 francs 6 sous défectueux !

En termes de VS fighting, on pourrait dire que tu es vraiment cracké, f4brice

Ca me rappelle une histoire (légende urbaine ?) au début des années 80 ou même 70, un ordi est en panne, il faut le réparer. Plus tard, la société qui recoit la facture voit 1.000.000$ de dollars. Furax, le patron appelle les techniciens qui ont réparé la bécane et demandent une explication. En effet, quel composant a bien pu couter si cher ?
Le gars répond: 1$ de composant et 999.999$ pour trouver la panne.

Aganyte


f4brice

Bonsoir.

Voici une mise à jour de plus concernant le dépannage de ma borne SEGA Space Ship.

Ce matin, sur le chemin du boulot, je me suis arrêté chez le crémier pour acheter un composant 74LS194.

J'ai dessoudé celui en place :


Le voici (en bas) à coté de son remplacant (en haut).
Le hasard a fait qu'ils soient du même constructeur (je pense que c'est Motorola) :


Je ne suis pas sûr, mais si "8211" signie que le composant neuf a été fabriqué durant la 11e semaine de 1982, alors ce composant neuf n'est pas tout jeune : il aurait 28 ans !

Voici le nouveau composant installé sur le PCB :


Là, j'ai à nouveau recommencé l'exécution pas à pas.
J'ai pu constater que le composant conserve maintenant correctement la valeur écrite.
Quand le "JMP" de la dernière fois est atteint, c'est bien la bonne adresse qui est utilisée, le CCPU cotinue l'exécution en 0x7E9 comme prévu.

Le changement de ce composant a donc corrigé une panne majeure du PCB.
Bien sûr, j'ignore s'il en reste d'autres....

J'ai continué l'exécution pas à pas du code présent dans les PROMs du jeu.
Tout semble fonctionner correctement. Le jeu initialise plusieurs variables en RAM.
C'est très logique de trouver ça, je pense que c'est la partie initialisation du jeu qui est comme ça.
Il reste de nombreuses instructions dont je n'ai pas pu vérifier le bon fonctionnement :

  • tout ce qui touche au 2e accumulateur
  • les comparaisons
  • les soustractions, les multiplications
  • ...

Je me suis penché sur la PROM "PR-10" que j'avais temporairement retirée car elle imposait un niveau logique sur le bus de données (au moins pour 1 bit) alors qu'elle n'était pas sélectionnée.
C'est en soit la preuve d'une panne sur ce composant.
Vu que c'est un composant programmé par SEGA et difficile à remplacer, je me suis dit que ça valait le coup de regarder de près son problème...

Ce composant est une PROM à fusibles de 1024 × 4 bits, référence HM-7643-5 du constructeur Harris.
Le temps d'accès est de 50 ns maxi, ce qui est très rapide.
Il dispose de 2 entrées de sélection, nommées "/CE1" (broche 8 ) et "/CE2" (broche 10).
Il faut que toutes les deux soient simultanément à l'état bas pour que le bus de donnée soit "actif". Sinon, il est dans un état "haute impédance", l'équivalent de "déconnecté".
SEGA, qui n'avait besoin que d'une unique broche de sélection a donc relié "/CE1" en permanence à la masse et n'utilise que "/CE2".

L'hypothèse que je veux vérifier est la suivante :

  • la broche "/CE2" utilisée par SEGA est morte et ne contrôle plus rien
  • la broche "/CE1" qui n'a jamais servi est peut-être encore opérationnelle et pourrait travailler à la place de "/CE2"

Je réalise donc un petit montage de test de la PROM sur ma plaque d'essais "à trous"...


Mise en place du composant, câblage alim et bus d'adresse


Câblage du bus de données, commande des transistors


Ajout des LEDs, mise en place d'interrupteurs sur les 4 bits de poids faible du bus d'adresse

Bon, maintenant ça ce complique...  ;)

Cas n°1.
Je sélectionne le composant. Les petits cavaliers en 1 et 2 sont présents. Ils forcent /CE1 et /CE2 à l'état bas.
Le composant est sélectionné, son bus de données est actif.
J'ai réussi à trouver une adresse où les 4 bits de données sont à l'état haut, ce qui me fait allumer les 4 LEDs.


Cas n°1 : /CE1 et /CE2 tous les deux à l'état bas ; le composant est sélectionné

Cas n°2.
J'ai retiré le cavalier n°2, donc /CE2 est à l'état haut grâce à une résistance de pull-up. Le cavalier en 1 est toujours en place.
Cette situation devrait suffire à désélectionner le composant et son bus de données devrait passer en haute impédance.
Vu que les LEDs restent allumées, j'ai bien la preuve que l'entrée /CE2 est morte et ne permet plus de désélectionner le composant.


Cas n°2 : /CE1 est à l'état bas, /CE2 est à l'état haut ; le composant reste anormalement sélectionné

Cas n°3.
J'ai remis le cavalier en 2 (même si en fait il ne sert plus à rien du tout vu que l'entrée est morte), et j'ai retiré le cavalier en 1.
Cette fois, j'ai /CE1 qui est à l'état haut.
Je constate que les LEDs sont maintenant éteintes.

  • soit le composant est réellement déselectionné
  • soit le composant est anormalement resté sélectionné et impose un état bas sur le bus de données


Cas n°3 : /CE1 est à l'état haut, /CE2 est à l'état bas ; le composant semble enfin désélectionné

Pour lever l'ambiguïté, il me suffit de faire un 4e test.
Avec une résistance de pull-up, je viens "tirer vers le haut" chacun des bits du bus de données.
Si la LED s'allume, c'est que le composant est bien désélectionné et n'impose plus aucun état sur le bus.

Bingo, le composant a bien libéré le bus de données (vérifié pour les 4 bits) :


Vérification que le bus de données est bien en haute impédance

C'est une très bonne nouvelle.
Ca veut dire que mon composant SEGA est toujours utilisable, mais je dois échanger les broches 8 et 10.

Pour échanger ces 2 broches, j'ai besoin de souder 2 petits bouts de fils.
Vu que je veux conserver la possibilité de retirer le composant sans fer à souder, je place le composant sur un support, en ayant pris soin de plier les 2 broches que je veux permuter.


Broche 8 isolée


Broche 10 isolée

Ensuite, il me suffit de souder 2 petits bouts de fil à wrapper pour réaliser la permutation.
Je soude les fils sous le support, au plus haut sur la patte métallique pour ne pas gêner lors de l'insertion de l'ensemble sur le support soudé sur le PCB.


Repiquage


Repiquage

Et voilà :



J'ai testé en mode pas à pas la 1ère donnée lue en ROM.
PR-10 est bien désélectionnée et la donnée lue est bien celle de PR-8 !  :-)=


À suivre :

  • ça vaut le coup maintenant de rester le PCB avec l'oscillateur d'origine ;
    la seule inconnue est la PROM PR-18 pour laquelle le doute m'habite quand à son contenu, différent de la référence Cinematronics
  • je ne sais toujours pas si les composants de RAM sont bons, j'ai tracé 2 instructions d'écriture qui se sont correctement déroulées, mais ce n'étaient que 2 adresses parmi les 256 possibles...

zebassprophet

tu pourrais presque monter ton wip de 1 ou 2 pourcent:p

f4brice


maldoror68


AsPiC

Citation de: f4brice le Mardi 26 Janvier 2010, 01:11:17 AM
Le hasard a fait qu'ils soient du même constructeur (je pense que c'est Motorola) :

C'est bien motorola.

Citation de: f4brice le Mardi 26 Janvier 2010, 01:11:17 AM
Je ne suis pas sûr, mais si "8211" signie que le composant neuf a été fabriqué durant la 11e semaine de 1982, alors ce composant neuf n'est pas tout jeune : il aurait 28 ans !

Je confirme également cette hypothèse :)
Pour la petite histoire, vu l'âge de ce composant ce n'est probablement pas de la distribution officielle (cad vendu par le fabricant) mais probablement un composant acheté chez ce que l'on appel un Broker (En gros un brocanteur de l'électronique) ;)

Iro

Merci de nous donner des explications aussi détaillées (même si je/on comprend pas grand chose :D)
Faire un récit aussi propre et illustré doit prendre autant temps que le debug !!!
"Jet set 2, c'est avec Robert Garcia ?" Kaneda, Lapsus de sac Vol.1
Peter Shou Owner' Club

WIPs : Naomi - SEGA Rally - AB Cop - Lethal Enforcers - COMPUMI - Terminator 2 - Space Invaders - Artworks pour Boitiers K7 Naomi CF - Ma collec' de panels

LES TUTOS DE GAMO   

gc339

#94
Bonjour.

Afin de progresser plus rapidement et plus confortablement dans le dépannage de cette carte CCPU il serait bon que tu t'équipes d'afficheurs hexadécimaux pour visualiser le contenu des bus de la carte ou les données en sorties d'une mémoire. Ce serait quand même beaucoup plus pratique est plus lisible que d'installer une foultitude de LED's ou de balader la sonde de l'oscilloscope sur chaque fil d'un bus à chaque nouvelle instruction.

LE TIL311 de Texas Instruments :













  • Le datasheet : http://www.alldatasheet.com/datasheet-pdf/pdf/28761/TI/TIL311.html
  • Afficheur "all-in-one", le boîtier DIL comporte la logique TTL et les LED's. L'affichage n'est pas un affichage à 7 segments car il est réalisé à l'aide de 20 points lumineux rouges , ce qui permet d'avoir des chiffres hexadécimaux moins stylisés et d'afficher le "B" et le "D" en majuscules.
  • Il comporte aussi deux points décimaux, le droite et le gauche qui peuvent être utilisés comme "oeil de rat" pour afficher indépendemment l'état d'un signal TTL quelconque.
  • Le gros problème est que ses entrées sont du type TTL et non pas du type TTL LS, il impose donc une charge trop importante sur un bus à base de TTL LS. Il est nécessaire de faire précéder chaque entrée A, B, C, D ou DP par un élément d'un boîtier type 74LS244 ou 74LS541. Le mieux serait d'utiliser les éléments d'un boîtier 74HCT244 ou 74HCT541 pour perturber encore moins le bus ou le signal dont on veut afficher l'état.
  • Le TIL311 a toujours été relativement cher : 23 euros chez Électronique Diffusion, actuellement il y en a deux de disponibles (Electro Breizh) sur un site d'enchères mondialement connu pour 12 euros pièce.


Le DM9368 de Fairchild :





















  • Le datasheet : http://www.alldatasheet.fr/datasheet-pdf/pdf/51129/FAIRCHILD/DM9368.html
  • Le DM9368PC est un driver hexadécimal pour afficheurs 7 segments à LED's, il a le même brochage que les afficheurs décimaux du type 7447 ou 74247 avec les caractéristiques suivantes :

    • Affichage 7 segments, le "b" et le "d" sont affichés en minuscules alors que les autres lettres le sont en majuscules.
    • Nécessite un afficheur 7 segments à LED's à cathode commune.
    • Pas besoin de résistance de limitation de courant en série avec chaque LED de l'afficheur car les sorties sont à courant constant (environ 20 mA ).
    • Les entrées A0 à A3 sont à très faible courant, donc elles peuvent être connectées directement sur le bus à visualiser sans le perturber.
    • Évidemment ses sorties à courant constant le font chauffer un peu surtout quand il doit afficher le "8". C'est pour cela qu'il vaut mieux utiliser des afficheurs d'une autre couleur que le rouge car plus la tension de seuil d'allumage des lED's sera élevée, moins le module aura à dissiper de calories.
  • Le DM9368 est obsolète mais on peut encore en trouver. Sur le même site d'enchère mondialement connu, le vendeur LittleDiode en propose en ce moment au prix prohibitif de 21,60 € pièce alors que l'on peut en trouver à beaucoup moins cher ailleurs. Par exemple Intertex Electronics (http://www.intertexelectronics.com/product11382.html?osCsid=7c50bfbdd82464d837705b55c5aed6dc) les vends $5,95 pièce et il accepte PayPal !
    EDIT : Sur le même site d'enchères, le vendeur dialelec en propose en ce moment deux exemplaires au prix plus raisonnable de 8,90 GBP (10,20 €) pièce sous l'appellation F9368DC.
  • Il faut bien sûr prévoir un afficheur 7 segments par module, une autre couleur que le rouge est préférable (orange, vert) pour la raison invoquée plus haut.

Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard





Persecutor

ben si j'avais su que l'on pouvait faire tout ça en electronique   :-\
j'aurais jamais seché les cours pour aller jouer a SF2 au bar du coin  :?

F4brice une fois de plus  ^-^
Les jeux de moto c'est nul ! Y'a pas de volant ...

Les bornes japonaises c'est comme les vaisseaux de la prélogie star wars,
c'est beau, lisse et parfaitement fonctionnel;
Alors que les bornes old school c'est un peu comme le Faucon Millenium qui passe jamais en vitesse lumière,
c'est chiant mais c'est tellement plus attachant ...

WIP s | Jeutel 25" RGB Jamma | Générique 17" 31khz | Mini BarTop TFT | Race Pod PC |

http://persecutor.tamdb.net