Gamoover

Besoin de contacter un admin pour une proposition, une suggestion ou discuter d'un probleme ?
C'est ici : High_Cobra, AsPiC ou Pich

[WIP] Midway Gun Fight (1975)

Démarré par f4brice, Jeudi 21 Janvier 2021, 22:16:49 PM

Maitre_Poulpi

Trop fort le post, c'est super intéressant.

En plus c'est attendrissant, entre le petit_lapin ou et la machine à doudou, on a envie de faire des câlins  :D
May the Gamooforce be with you !
À partir du moment où un fou sait qu'il l'est, peut-on toujours le nommer ainsi ?
Boulot, rétro, dodo... et un peu (beaucoup) de TATC© (Touche A Tout Compulsif)...
Le WIP en slip et le hack Sega en Pijama !

f4brice

Citation de: Little_Rabbit le Samedi 23 Janvier 2021, 23:31:37 PM
Je suis content que mes travaux précédents servent à quelqu'un !  ^-  :-*

C'est tout l'intérêt d'un forum et du partage de connaissances !  :-*
Merci à toi !

Citation de: Little_Rabbit le Samedi 23 Janvier 2021, 23:31:37 PM
Le 74157 en F5 a une bonne tête de coupable non ? :)

Oui, sa pin #11 serait morte.
Mais ça peut aussi être le compteur en amont, le 9316 en E5 qui aurait sa pin #12 morte.
Ton hypothèse est quand même la plus vraisemblable.

Citation de: Little_Rabbit le Samedi 23 Janvier 2021, 23:31:37 PM
PS : as-tu bien reçu le schéma de la carte mère Taito mis au propre que je t'ai adressé par email ? :)

Non, rien reçu du tout !  :'(
Je te redonne mon adresse e-mail par MP !

Michel Maeva

Bonjour,

Je possède une borne Gun Fight depuis le dernier RT effectué avec Sentinelle.

L'ensemble des faisceaux est soudé aux différents peignes du PCB, il faut que j'achète les peignes adéquats.

La borne n'a pas encore été testée, cependant elle a dû rester une paire d'années dans un local d'un exploitant.

Je vais suivre ce WIP avec beaucoup d'intérêts.
Sauvegardons notre patrimoine arcade !!!
Président du Celtic Arcade Museum (Musée de l'arcade à Quimperlé (29))
https://www.facebook.com/CelticArcadeMuseum

f4brice

#19
Bonjour.

On continue le dépannage de ce PCB Gun Fight.
La dernière fois, j'avais observé que l'image avait un défaut de zones clonées.
Un petit peu de réflexion à tête reposée mettait en cause le bit AD3 du bus d'adresse de lecture des RAMs.

C'est parti à grands coups d'oscillo !

Voici une vue d'ensemble de mon environnement de dépannage :


L'ordi portable me sert à lire les schémas électroniques.
Il est posé sur la valise renforcée dans laquelle je range l'oscillo.
Juste à droite de la valise, il y a le pistolet à dessouder "FR-300" de chez "HAKKO" (lien), conseillé par Petit_Lapinou et c'est un excellent choix.
Au pied de la perceuse à colonne, ce sont les notes de mon aide de camp, qui aime dessiner et écrire.

Revenons à notre bit AD3...
Le bit AD3 qui est envoyé aux RAMs est, comme l'a indiqué dans un message précédent Petit_Lapinou, généré par le composant en F5 :


Ce composant a la lourde tâche de commuter 4 des bits d'adresse envoyées aux RAMs à partir de 2 sources possibles :

  • les adresses croissantes générées par le "scan" qui parcourt la RAM vidéo pour lire les pixels et générer le signal vidéo ;
    elles sont connectées sur les entrées "I0n", soit les pins #2, #5, #11 et #14
  • les adresses issues du CPU quand il veut lire ou écrire en RAM, peu importe la raison
    elles sont connectées sur les entrées "I1n", soit les pins #3, #6, #10 et #13

Le choix se fait selon la pin #1 "SEL" :


  • SEL = 0, on balance aux RAMs l'adresse courante générée par le "scan" vidéo
  • SEL = 1, on balance aux RAMs l'adresse voulue par le CPU pour lire ou écrire

Ce qui nous intéresse, c'est le bit AD3 en rouge, issu soit du signal en vert (scan vidéo) ou en magenta (CPU).
Et il faut regarder ce qui se passe quand SEL = 0, c'est à dire que c'est le scan vidéo qui accède aux RAMs.
On doit avoir le signal rouge = le signal vert.

Vu qu'on est sur un bit d'adresse de rang assez faible (comprendre par là qu'il bouge tout le temps : 4 fois par ligne vidéo), je synchronise mon oscillo sur la dernière "RIPPLE CARRY" des compteurs générateurs des adresses de scan vidéo.
C'est ce signal en rouge :


Quand le tout dernier compteur générateur des adresses de scan vidéo a fini de compter, une impulsion sort sur sa pin "RIPPLE CARRY".
Imaginez compter "zéro plus un font un ; un plus un font deux ; deux plus un font trois ; etc...", mais ne pouvoir écrire qu'un chiffre.
Arrivé à neuf, on  dirait, "neuf plus un font dix ; j'écris zéro et je retiens un".
Cette pin "RIPPLE CARRY", c'est le "je retiens un" quand le compteur boucle.
Et celui-là boucle à la toute fin du scan vidéo, juste avant de reprendre au début de l'image et de la RAM vidéo.
Ainsi, j'ai là un top de synchro fiable qui va me permettre d'observer les adresses de scan sans que ça gigote dans tous les sens sur mon oscillo.

Voilà le résultat :



  • en jaune, c'est la synchro de l'oscillo, le début de scan d'image
  • en cyan, c'est la pin de sélection du chip F5, celle qui dit si on balance aux RAM l'adresse de scan vidéo (SEL = 0) ou l'adresse du CPU (SEL = 1)
  • en magenta, c'est le bit AD3 de l'adresse de scan. Déjà on voit qu'elle bouge, donc le compteur E5 en amont semble à priori bon
  • en vert, c'est le bit AD3 qui est envoyé aux RAMs. quand on a SEL = 0, on doit retrouver le signal magenta. Quand on a SEL = 1, on utilise l'adresse demandée par le CPU et pour le moment on s'en fout

Voilà l'analyse :


Les 8 premières fois où on a SEL = 0 (scan vidéo) et le signal magenta = 0 (1er quart de la 1ère ligne de l'image vidéo), on voit qu'on balance systématiquement un "1" aux RAMs (signal vert), alors que ça aurait du être un 0 (signal magenta). J'ai entouré ça en rouge.
Ensuite, les fois suivantes (entourées en orange), on a le signal magenta qui vaut 1 (2e quart de la 1ère ligne de l'image vidéo) et on balance bien un "1" aux RAM (signal vert).
CQFD : sur le 1er quart de l'image, on a AD3 qui vaut 1, donc on va lire (et afficher) en fait les pixels présents dans le 2e quart en RAM.

On a notre coupable : le chip "9322" en F5 !

Je le dessoude :


Notez ces tordus de chez Midway qui pliaient les pattes des composants comme des psychopathes avant de les souder :


Il faut vraiment de la patience (un bon outillage aide beaucoup) pour extraire ça sans tout arracher !

Bon, le problème c'est que je viens de dessouder une bouze de machin un peu exotique : un "9322"...  :'(
Je n'ai pas ça en stock et une recherche rapide sur ibé donne des douleurs anales :


Le moins cher est à 9,04 € fdpin les 2 chips, soit 4,52 € l'unité !  (:x

Si on regarde de près, c'est simplement un clone du TTL 74157 avec des caractéristiques dynamiques un peu améliorées :

Le 9322 :


Le DM74157 :


Dans certains cas, le 74157 est un poil plus lent.
Je n'aime pas me faire recto-dilater sur ibé (ni ailleurs, en fait), donc je vais tenter avec mon DM74157 en stock.

Le composant d'origine est testé comme si c'était un 74157 :


Il est effectivement kaput.
Quand on regarde de près l'erreur du testeur, il dit :
EXPECTED: V0002:101L01LGL10L101V
RESULT: V0002:101L01LGH10L101V


Il faut causer un peut le testeur de composant couramment...
"V0002" signifie que c'est l'itération de test n°2.
Ensuite, on a une série de 16 caractères pour les 16 pins du composant.
"L" indique que le testeur doit vérifier que la pin est à 0.
Il dit "H" pour la pin #9 : il la voit à 1.
C'est exactement notre panne qui est identifiée par le testeur !

Je teste le remplaçant :


Il est bon, donc je le soude à la cow-boy, sans support !


Pourquoi sans support, d'autant plus que je ne suis pas sûr de ma substitution ?
Simplement parce que je n'aime pas les supports sur un PCB. C'est moche et source de faux-contacts.
Si jamais mon DM74157 ne fonctionne pas correctement, j'ai de quoi le ressortir sans risquer d'abîmer le PCB.

Il est temps de re-tester le PCB, toujours équipé de sa Sectro-ROM de test :


TADAAAAA !
J'ai corrigé le problème de zones d'écran clonées. Mon DM74157 fait bien le job à la place du 9322 exotique !
Maintenant le résultat du test de RAM s'affiche correctement.
Notez que dans ce que j'avais appelé la "zone 2" de l'image, toutes les RAMs sont vues OK, et c'était cette partie de l'image qui était clonée en "zone 1".

À suivre : on va s'attaquer à ce problème de RAMs !


Little_Rabbit

#20
Salut,

Cool, une panne en moins !  ^-

Pas cool, il y aurait 6 RAM à remplacer ?...  :-\

À voir si les buffers en sortie de RAM pourraient être en cause, mais de mon expérience, ce sont le plus souvent les RAMs qui sont cuites... :'(

Cela dit, as-tu refait le test sans EPROM depuis que le multiplexeur 74157 a été remplacé ? Car je serais curieux de voir la gueule des barres verticales à présent : elles étaient bien régulières, ce qui laissait présager des RAMs plutôt fonctionnelles.

[edit : je m'auto réponds => les lignes verticales ne donnent qu'une indication assez partielle de l'état des RAM, car pas mal de pixels sont à zéro, notamment les 10 bits de poids fort !... =>

Citation de: Little_Rabbit le Vendredi 25 Décembre 2020, 16:54:38 PM
D'ailleurs, si on observe cette valeur $0039 qui est mise en pile, d'un point de vue « pixel », cela donne ça :



]

A+
Recherche bornes dédiées ou PCB originaux: Miss Pacman, Dig Dug, Galaga, Mappy, Asteroids, Battlezone, Missile Command, Tempest, Star Wars, Donkey Kong (+ Jr), Mario Bros, Moon Patrol, Defender, Joust, Frogger, Gyruss, Pooyan, Space Tactics, Zaxxon, etc. Flip : Gottlieb des années 80 (Spirit, Amazon Hunt, ...), Baby Pac Man. Divers :  Ice Cold Beer => Trois fois rien quoi ! :D
Ma séance sur le divan : c'est grave Docteur ? :-\
Ma gaming room, ma storage room

Franzy2121

Je suis ce dépannage épique avec délectation.
Encore merci f4brice pour ce partage de ta grande expérience!
^-^

f4brice

Bonjour.

Voici la suite de ce dépannage de PCB Gun Fight.

La dernière fois, la Spectro-ROM de test m'avait indiqué pas moins de 6 RAM kaput.
Il faut bien comprendre que le test consiste à écrire en RAM, relire, et déclarer une ou plusieurs RAM kaput si la valeur relue n'est pas celle qui avait été écrite.
En réalité, les possibilités de pannes sont très nombreuses :

  • la donnée écrite par le CPU n'arrive pas / mal jusque dans la RAM (pb de driver de bus de données CPU => RAM)
  • la donnée écrite par le CPU n'est pas écrite au bon endroit en RAM (pb de driver de bus d'adresses)
  • la donnée n'est pas écrite du tout (pb de gestion du signal R/W)
  • la donnée relue en RAM n'arrive pas / mal jusque dans le CPU (pb de driver de bus de données RAM => CPU)
  • problème avec le latch qui contient le STATUS WORD du CPU
  • problème de sélection de RAM
  • problème avec la RAM elle-même

J'avoue n'avoir pas trop réfléchi à tout ça, et je me suis lancé tête baissée dans le dessoudage des 6 composants de RAM (préparez les tomates)...
Le pistolet à dessouder HAKKO est vraiment une merveille, et fait un travail extraordinaire :


En deux temps trois mouvement, la RAM est extraite :


Bien sûr mon aide de camp est à mes côtés. Elle aussi "réparer des cartes électroniques".
Elle m'a demandé un fer à souder pour faire comme papa.
L'avantage, c'est qu'à cet âge il n'y a pas besoin de réalisme. Le plus important c'est l'imagination.
Je lui donne une carte électronique issue de mon stock de donneurs d'organes, et un tournevis qui "on dit que c'est un fer à souder".
Elle pose l'extrémité du fer à souder sur sa carte et dit "brrrrrrr" pour imiter le bruit de mon outil :


Et voilà, les 6 RAM ont été dessoudées, des supports tulipes soudés et de nouvelles RAM mises en place :


Tout fébrile, je relance la ROM de test...


Bon ben voilà. Ça c'est fait. Absolument aucun changement.
Il est très peu probable que mes 6 RAM neuves soient toutes les 6 kaput en même temps...
Donc il faut arrêter de se lancer tête baissée dans le déssoudage, et réfléchir davantage...
Là vous pouvez me lancer des tomates pour avoir foncé sans réfléchir...

Ce qui est très bizarre, c'est que l'image vidéo n'est pas du tout buggée. Aucun pixel parasite, etc... L'image est nickel.
J'en déduis que le CPU arrive correctement à écrire en RAM, mais que la lecture déconne.
Dépanner ça à l'oscillo n'est pas simple, car durant le test RAM, tous les bus gigotent dans tous les sens et à toute vitesse.
Il est très dur d'arriver à observer LA lecture de RAM qui foire.

Je modifie donc le code assembleur de la Spectro-ROM de test.
Normalement, le test de RAM va jusqu'au bout des tests, puis affiche le résultat.
Ça ne m'arrange pas du tout : j'ai besoin d'observer à l'oscillo le crime au moment où il est commis !
Je modifie chaque test (il y en a 3 différents) pour faire un jump dans du code spécial à moi immédiatement dès la première erreur :


L'idée, c'est d'observer à l'oscillo une écriture et une relecture à la première adresse identifiée KO par la ROM de test.
Pour ça, mon code modifié va réaliser en boucle infinie :

  • reset du watchdog, pour éviter que le CPU ne soit reseté par un élément extérieur
  • écriture de la valeur 0x00 en RAM à l'adresse fautive
  • relecture de l'adresse fautive
  • écriture de la valeur 0xFF en RAM à l'adresse fautive
  • relecture de l'adresse fautive
  • GOTO 1

Ainsi à l'oscillo, dès la première erreur de RAM, je vais pouvoir observer l'écriture et la lecture à l'adresse fautive, alternativement avec des 0 et des 1.
Je flashe mon code modifié dans une EPROM 2716 :


Et voici le résultat :


Hein ? Quoi ? RAM = OK ? WTF ?
Encore une diablerie du Démon des Pannes qui se paye ma tronche ?
Plus AUCUNE RAM en erreur alors que juste avant j'en avais 6 ?
Sachant aussi que dans ce cas là, mon code n'est pas exécuté puisqu'il n'est appelé qu'en cas de pb détecté ?!

Je vérifie mon code assembleur, et il est parfaitement correct...
Finalement la réponse est dans le changelog de la Spectro-ROM de test :


En mars 2019, une personne prénommée "Marc" a identifié et corrigé un bug d'initialisation du test de RAM.
Ce bug provoquait des fausses erreurs sur les RAM d'adresse paire (colonne G).
Cette personne a partagé son travail tout comme Spectroman et moi. La version 1.3 de la ROM de test a été créée pour l'occasion.
Ma Spectro-ROM de test, retrouvée dans mon bazar était sûrement une version 1.1. C'est avec elle que j'ai consaté les 6 RAM en erreur.
Mais pour faire mon hack, je suis reparti de la version 1.3. J'ai donc intégré sans m'en rendre compte le bugfix de Marc.
Et effectivement, le bug corrigé par Marc pouvait provoquer des faux-positifs sur les 8 premières RAM (celles de la colonne G).
Le Démon des Pannes a bien dû savourer son popcorn en me regardant dessouder les 6 chips de RAM !

Donc je reflash une version 1.3 "propre" (sans mon hack destiné à m'aider à utiliser l'oscillo) et je remets aussi toutes les RAM d'origine.


Là, je comprends mieux. Je pense que résultat est fiable et que la RAM #7 est vraiement en erreur, d'autant plus qu'il y a des petits cacas sur l'image.
Je change cette RAM #7 (située en G14) par une neuve, et voilà :


En réalité, je n'avais donc qu'une seule RAM de kaput.
Les 5 autres étaient des faux-postifs dû à un bug présent dans la version 1.1 (ma ROM de test initiale, qui était déjà flashée dans l'EPROM retrouvée dans mon bazard).

Maintenant que les RAM sont OK, je peux poursuivre le dépannge du PCB : le shifter hardware, l'audio et les inputs.
Je ferai l'audio et les inputs plus tard. Je veux d'abord réparer tout ce qui concerne le CPU.
À la fin du test audio, la ROM de test réalise un test de ce shifter hardware du PCB.
Ce shifter hardware est présent pour optimiser le code assembleur du jeu.
En effet cette bouse de CPU 8080 ne sait pas trop faire les décalages binaire. Il sait juste faire 1 bit à la fois.
Pour accélérer les décalages binaire, Taito a ajouté du hardware dédié.
Le CPU balance la data (8 bits) et le nombre de bits à décaler (de 0 à 7), et récupère sur un plateau le resultat calculé par le shifter hardware.
La Spectro-ROM de test vérifie l'exactitude des données calculées par le shifter, et affiche les éventuels écarts.

Voilà :


Ouergl ! Le shifter hardware est vraiment buggé jusqu'à l'os !
Normalement, on ne devrait avoir que des "00"...


À suivre : dépannage du shifter hardware, à partir des résultats affichés par la ROM de test

Little_Rabbit

#23
Salut,

Ah, je ne m'attendais pas à ça, même si j'avais trouvé que 6 RAM défectueuses, ça faisait peut-être beaucoup (quoique, mon PCB Space Invaders en avait 8 de défectueuses !...).

Mais tes résultats me surprennent beaucoup !  :-\

En effet, je m'étais penché de près sur la routine de Spectro, que j'ai utilisé des dizaines (voire centaines) de fois durant le laborieux dépannage de mon pcb Space Invaders :). Et j'avais bien remarqué qu'après un RESET, la routine de test donnait des résultats qui n'étaient jamais les mêmes qu'après une mise sous tension.

J'avais détaillé cela dans ce post. La seule différence qu'il y a entre la version 1.2 et 1.3, c'est la bonne initialisation à 0 du registre DE qui sert à stocker les n° de RAM incriminées durant le test. Autrement dit, que tu aies eu des résultats farfelus après un RESET ne m'auraient pas surpris, mais lors du 1er test, à la mise sous tension, la version 1.2 donne un résultat fiable, car à la mise sous tension TOUS les registres du 8080 sont à 0, alors qu'un RESET ne remet que le registre PC à 0 ! :)

À moins que ton PCB soit équipé d'un 8080 un peu holé holé qui ne remette pas ses registres à 0 à la mise sous tension ! :D

Pour ton shifter, tu nous diras comment est ta carte fille, mais sur les 3 que j'ai eu l'occasion de dépanner, les composants utilisés pour mémoriser les valeurs décalées, des 74LS153, ils étaient toujours sur support gris, qui n'agrippent pas très bien les composants qui y sont insérés :



Les bugs détectés par la routine de Spectro ne venaient que de mauvais contacts :). Un peu d'exercice pour étirer leurs gambettes engourdies par des années de repos avait suffit à les remettre d'aplomb. :) J'ai même remplacé ces supports (mais toujours galère, d'autant que les pistes de la carte fille sont encore plus fragiles que celles de la carte mère !).

Un petit détail: pour le shifter, tu parles d'une valeur 8 bits qu'on récupère décalée du nombre de bits voulus => en réalité, c'est une valeur 16 bits à laquelle on applique un décalage pouvant aller jusqu'à 8 bits ;). J'avais détaillé son fonctionnement sur ce post :).

Hâte de voir la suite !  :-)=

A+
Recherche bornes dédiées ou PCB originaux: Miss Pacman, Dig Dug, Galaga, Mappy, Asteroids, Battlezone, Missile Command, Tempest, Star Wars, Donkey Kong (+ Jr), Mario Bros, Moon Patrol, Defender, Joust, Frogger, Gyruss, Pooyan, Space Tactics, Zaxxon, etc. Flip : Gottlieb des années 80 (Spirit, Amazon Hunt, ...), Baby Pac Man. Divers :  Ice Cold Beer => Trois fois rien quoi ! :D
Ma séance sur le divan : c'est grave Docteur ? :-\
Ma gaming room, ma storage room

pet

Un peu en retard..mais superbe environnement de travail!

Vu les résultats avec des composants pattes pliées je vais investir dans un fer à dessouder HAKKO, ça mettra mon dremel à dessouder au repos.

Tu as un assembleur 8080 ou tu fais "à la main"?
Un clavier AZERTY en vaut deux

Little_Rabbit

#25
Salut,

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Tu as un assembleur 8080 ou tu fais "à la main"?

Je laisse répondre F4brice car je sais qu'il bosse sous Linux exclusivement :).

Pour ceux qui seraient sous Windows, on peut facilement se créer un environnement similaire, et programmer en assembleur 8080 grâce à Cygwin ! C'est Spectro qui m'avait expliqué tout ça et mis le pied à l'étrier. C'est grâce à cela que j'avais pu faire ma version 1.3 de l'EPROM de test, et même une pseudo démo Gamoover en 8080 sur PCB Space Invaders :D.

Ensuite, grâce à MAME en mode debugger, cela te permet de tracer pas à pas ton programme, comme si tu le testais sur le vrai hardware Midway : c'est top !  ^- J'avais fait ça pour essayer de trouver l'origine des glitches que j'avais sur mon PCB Space Invaders en panne, mais cela n'avait rien donné.

A+
Recherche bornes dédiées ou PCB originaux: Miss Pacman, Dig Dug, Galaga, Mappy, Asteroids, Battlezone, Missile Command, Tempest, Star Wars, Donkey Kong (+ Jr), Mario Bros, Moon Patrol, Defender, Joust, Frogger, Gyruss, Pooyan, Space Tactics, Zaxxon, etc. Flip : Gottlieb des années 80 (Spirit, Amazon Hunt, ...), Baby Pac Man. Divers :  Ice Cold Beer => Trois fois rien quoi ! :D
Ma séance sur le divan : c'est grave Docteur ? :-\
Ma gaming room, ma storage room

pet

#26
Mame j ai pratiqué  en mode debugger pour modifier/corriger des eproms de flipper et faire mes roms de test (bally et gottlieb).
Le debugger m avait grandement facilité les mises au point.
Un clavier AZERTY en vaut deux

f4brice

#27
Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Un peu en retard..mais superbe environnement de travail!

Merci.
L'établi a été fabriqué sur mesure par mon Papa !  :-*

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Vu les résultats avec des composants pattes pliées je vais investir dans un fer à dessouder HAKKO, ça mettra mon dremel à dessouder au repos.

Excellent achat, testé et conseillé par Little_Rabbit.
Je me suis laissé convaincre et je ne regrette pas.
C'est le seul outil à aspiration qui fonctionne réellement.
Tous ceux que j'ai pu tester avant étaient de la crotte en barre.
Il est actuellement en promo chez Batterfly (c'est là que j'ai acheté le mien) : lien.

Citation de: pet le Mercredi 27 Janvier 2021, 21:56:44 PM
Tu as un assembleur 8080 ou tu fais "à la main"?

Comme l'a dit Little_Rabbit, je bosse exclusivement sous Linux.
Mon seul PC sous Zindoz est un vieux portable pour faire fonctionner mon programmateur d'EPROM.
Avant, j'avais réussi à l'utiliser depuis une machine virtuelle via un bridge USB, mais depuis une mise à jour de la machine virtuelle, ça ne fonctionne plus.

Sous Linux, j'utilise :

  • pour l'assembleur et l'éditeur de lien : "ASxxxx" d'Alan R. Baldwin : lien
    l'outil est dispo pour de multiples plateforme, dont Linux, Zindoz truc, Zindoz machin, etc...
  • pour la conversion Intel HEX => binaire de 2kB prêt à écrire dans une EPROM : "hex2bin" de Jacques Pelletier : lien

Je ne me fais pas iéch à lancer l'assembleur en ligne de commande manuellement.
Timothy Shiels héberge sur son site l'archive contenant le code source de la Spectro-ROM de test.
J'y ai complété le makefile et il suffit de lancer "make" pour que tout le boulot soit fait proprement.

f4brice

Citation de: Little_Rabbit le Mercredi 27 Janvier 2021, 08:45:48 AM
À moins que ton PCB soit équipé d'un 8080 un peu holé holé qui ne remette pas ses registres à 0 à la mise sous tension ! :D

Par acquis de conscience, maintenant que les RAMs sont OK, j'ai reflashé une ROM de test mais en ayant mis en commentaire la correction de bug de la version 1.3 :


Le bug fix était d'effacer le registre "E" du CPU, qui contiendra les RAM en erreur de la colonne "G" (les RAM 1 à 8 ).
J'ai mis en commentaire cette ligne.
Je lance le test, donc sans le fix du bug de la version 1.3 :


Bon, je crois que la réponse est là.

On pourrait croire que mon CPU est buggé, mais il n'en est rien du tout.
Voici un extrait du "User Manual" du CPU :


Il est clairement indiqué que :

  • au démarrage (power-up), tous les registres contiennent des données aléatoires (rouge)
  • il faut balancer un RESET qui va forcer le PC (program counter) à 0x0000 (vert)
  • ce RESET n'a aucun effet sur les autres registres, qui vont conserver leur valeur précédente (magenta)

Notez que sur la photo, la RAM "7" n'est plus vue en panne.
C'est la seule RAM que j'ai changé.

Il y avait bien un "vrai" bug dans la Spectro-ROM de test version 1.2, qui a été corrigée dans la 1.3 !  ^-

Little_Rabbit

Salut,

Citation de: f4brice le Jeudi 28 Janvier 2021, 21:05:51 PM
Il y avait bien un "vrai" bug dans la Spectro-ROM de test version 1.2, qui a été corrigée dans la 1.3 !  ^-

On est bien d'accord ! :)

Oui la routine était bien buggée, car elle n'initialisait que la moitié de la paire de registre DE !

Je m'en suis rendu compte en novembre 2018, et j'ai corrigé le source de façon similaire à la tienne, mais en une seule instruction :).

Ta correction :

;---------------------------------------
; First RAM test
;---------------------------------------
ramtest::   mvi     d,0x00       ; clear the error register
            mvi     e,0x00


Ma correction :

;---------------------------------------
; First RAM test
;---------------------------------------
ramtest::   lxi     de,0x0000    ; clear the error register


On est bien d'accord, cela revient exactement au même ! :D

Mais j'ai dû mal m'exprimer sur ma surprise de ton test au résultat erroné dès la mise sous tension.

Durant mes essais, qui se chiffrent en dizaines et dizaines d'exécution de la routine de test en version 1.2, après une mise sous tension, son exécution donnait TOUJOURS un bon résultat. J'ai bien noté le passage de la doc Intel qui mentionne que les registres ont un contenu aléatoire à la mise sous tension, mais il faut croire que certaines spécimens de 8080 ont leur registre DE déjà à 0 car je t'assure que chez moi c'était le cas :-\ ! Sinon, le bug aurait été démasqué immédiatement :).

Quant aux versions successive du test de RAM, la 1ère que tu as utilisée, celle cachée dans ton bazar, c'était bien une version 1.2 et non 1.1 :).

Souviens-toi, voici l'historique :

version 1.0 => version de Spectro qui affiche 1 code erreur à la fois, avec un zigouigoui derrière le n° de RAM
version 1.1 => version que tu as améliorée en supprimant le zigouigoui de fin de ligne (+makefile, + etc.)
version 1.2 => version de Spectro super améliorée qui affiche d'un coup les erreurs présentes sur les 16 RAM
version 1.3 => identique à la 1.3, avec l'initialisation correcte de la paire de registres DE, qui fonctionne parfaitement à la mise sous tension, et surtout après un RESET

Tout cela n'a aucune importance, je sais, mais c'est juste histoire d'être précis :D.

Comment ça je serais psychorigide ???  :-[

:D

A+
Recherche bornes dédiées ou PCB originaux: Miss Pacman, Dig Dug, Galaga, Mappy, Asteroids, Battlezone, Missile Command, Tempest, Star Wars, Donkey Kong (+ Jr), Mario Bros, Moon Patrol, Defender, Joust, Frogger, Gyruss, Pooyan, Space Tactics, Zaxxon, etc. Flip : Gottlieb des années 80 (Spirit, Amazon Hunt, ...), Baby Pac Man. Divers :  Ice Cold Beer => Trois fois rien quoi ! :D
Ma séance sur le divan : c'est grave Docteur ? :-\
Ma gaming room, ma storage room

Maitre_Poulpi

Il est trop bien ce wip, on apprend pleins de truc et le tout avec un ton léger  ^-^

J'ai un pistolet à dessouder sur ma station que j'avais acheté il y a des années chez conrad.



Ça m'avais permis de passer un niveau en m'embêtant un peu moins.
Par contre c'est sûr que je n'arrive pas au même résultat. L'afficheur de droite est hs (je ne peux plus régler la température) et il faut nettoyer souvent parce que ça se bouche. Je recharge en soudure aussi pour arriver à aspirer mieux mais c'est pas toujours aussi évident.
En tout cas, le résultat que tu montres en photo est super propre. Y a bien une raison pour que le budget soit plus élevé  :)
May the Gamooforce be with you !
À partir du moment où un fou sait qu'il l'est, peut-on toujours le nommer ainsi ?
Boulot, rétro, dodo... et un peu (beaucoup) de TATC© (Touche A Tout Compulsif)...
Le WIP en slip et le hack Sega en Pijama !

Little_Rabbit

Re,

@Poulpi : oui, et un autre avantage du pistolet à dessouder HAKKO, c'est que c'est très compact ! Tu n'as pas la grosse station à côté, juste le pistolet, ça ne prend pas de place sur l'établi. Moi qui ai un tout petit atelier pour mes bricolages électroniques, j'apprécie. Mais il arrive aussi à ce modèle de se boucher :-\. J'essaye alors de le déboucher en le mettant en chauffe à la position maximale, et j'utilise les tiges fournies avec... Toutefois, une fois je n'y arrivais pas, j'ai essayé avec un tout petit forêt, sauf que maladroitement j'ai fini par casser le forêt dans la buse ! :'( Là c'est mort, impossible de l'en déloger je pense... Il faut d'ailleurs que je rachète cette taille de buse, je n'en ai plus qu'une à présent.

A+
Recherche bornes dédiées ou PCB originaux: Miss Pacman, Dig Dug, Galaga, Mappy, Asteroids, Battlezone, Missile Command, Tempest, Star Wars, Donkey Kong (+ Jr), Mario Bros, Moon Patrol, Defender, Joust, Frogger, Gyruss, Pooyan, Space Tactics, Zaxxon, etc. Flip : Gottlieb des années 80 (Spirit, Amazon Hunt, ...), Baby Pac Man. Divers :  Ice Cold Beer => Trois fois rien quoi ! :D
Ma séance sur le divan : c'est grave Docteur ? :-\
Ma gaming room, ma storage room