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

nicolas-le-jardinier

Citation de: f4brice le Mardi 05 Janvier 2010, 01:35:26 AM
J'ai trouvé cette notice 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.

gc339

#49
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+
Le repos, c'est fait pour les jeunes. Ils ont toute la vie devant eux. J. Gabin/M. Audiard





Aganyte

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

f4brice

#51
Bonsoir.

Citation de: gc339 le Mardi 05 Janvier 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 !


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.

Citation de: gc339 le Mardi 05 Janvier 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 :



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) :



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

maldoror68

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 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

gc339

#53
Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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.

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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 1er 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.

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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 ...

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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.

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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.

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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.

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
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".

Citation de: f4brice le Mercredi 06 Janvier 2010, 01:39:03 AM
Le reverse-engineering des op-codes du CPU Cinematronic est totalement réalisé sous Mame.

Donc les gens qui ont réalisés cette émulation devaient avoir des informations de bonne source, ou alors ont du investir pas mal de temps à décortiquer la carte pour les obtenir.

A+

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





maldoror68

je redéterre ce topic (j'en suis fan  :-*)

alors ? du neuf? ;)

f4brice

Citation de: maldoror68 le Vendredi 08 Janvier 2010, 10:11:37 AMalors ? du neuf? ;)

Mise à jour ce soir !  ;)

Hier soir ce matin, j'ai arrêté à 02h00 et mon lit était plus attirant que le clavier du PC.

Je pense avoir démontré un défaut sur au moins une PROM à fusibles.
La PROM ne supporte plus les lectures rapides, les glitches sur le bus de donnée ne sont pas dûs à un asynchronisme de commutation du bus d'adresse.

Ad'taleur.

Vany

Citation de: f4brice le Lundi 04 Janvier 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 !

Tu veux que je m'en occupe ?

f4brice

Citation de: Vany le Vendredi 08 Janvier 2010, 12:55:57 PMTu veux que je m'en occupe ?

Vi beaucoup !  :-*

La 2e personne est d'origine chinoise, et ne décrypte que très très partiellement le japonnais.

Vany


f4brice


Darth Nuno

et voilou... pas grand chose mais mieux que rien  ;)  :fleche:



Pour rappel, l'image original fait max 5cm, d'où la qualité moyenne une fois agrandie  :-\
 

f4brice

Citation de: Darth Nuno le Vendredi 08 Janvier 2010, 21:35:12 PM
et voilou... pas grand chose mais mieux que rien  ;) 

Merci !  <:)
Pourquoi avoir ajouté des "$" ?

Darth Nuno

Citation de: f4brice le Vendredi 08 Janvier 2010, 22:23:32 PM
Merci !  <:)
Pourquoi avoir ajouté des "$" ?

LOL... j'ai installé à l'arrache le scanner sur mon iMac, mais je n'ai qu'un soft en mode 'trial' qui ajoute lui même les $ ...

 

f4brice

#63
Bonsoir.

Voici la mise à jour d'hier soir, non faite hier soir pour cause d'yeux qui se fermaient tous seuls...  :D

J'ai commandé sur le site d'enchères mondialement connu un programmateur d'EPROM.
Mon choix s'est arrêté sur le VP280, sans réel argument très fort pour ce modèle plutôt qu'un autre.
Google m'a trouvé la liste des composants TTL qu'il sait tester, en plus de la programmation standard d'EPROMs : liste.
Il semble très complet dans cette liste.
Le manuel d'utilisation que j'ai téléchargé indique que l'on peut, moyennant programmation, tester des composants non connus de l'appareil.

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...)
Aujourd'hui, à chaque nouveau 74xxx rencontré, je dois récupèrer sa datasheet que je sauvegarde sur mon disque dur, mais j'ai rarement besoin de tous les détails.
Un résumé me suffirait.

À propos de planche à clous, j'ai déjà vu des collègues électroniciens s'en servir pour tester des cartes.
Il y a un système avec un levier monstrueux (gros comme un levier de frein à main) pour insérer/retirer les connecteurs.
Des sondes en forme de "clous" positionnées avec précision viennent effectivement mesurer un signal.

[3615 MYLIFE]
Étant môme, j'avais 2 souris (l'animal, pas le périphérique) dont une souris albinos.
C'est vrai que les yeux de souris albinos, selon l'éclairage, fond bien penser à des LEDs rouges !  ;D
[/3615 MYLIFE]


Hier soir, j'ai suivi la méthodologie expliquée dans un message précédent.
J'ai investigué le pourquoi du comment du signal "reset".

Voici le schéma de la génération du signal reset, extrait de la page 27 :


En 1, j'ai un signal qui passe à l'état bas toutes les xxx millisecondes.
Je n'ai pas pu mesurer la périodicité du signal : il passe à l'état bas seulement quelques dizaines de nanosecondes avant de retourner à l'état haut.
C'est normal car il est issu d'une bascule JK dont la clock est la CLOCK principale (environ 5 MHz) du PCB.
Pour voir 2 passages à l'état bas, je dois extrêment ralentir la base de temps de mon oscillo et ce dernier ne voit plus du tout le signal passer à l'état bas car c'est bien trop rapide par rapport à la base de temps.
D'après moi, la périodicité du signal reset serait soit celle du signal "/PROCEED", soit le double.

En 2, j'ai le signal "POWER_UP" à l'état haut. Il est issu d'un montage à 2 transistors + 1 porte inverseuse. Aucun problème ici.

En 3, j'ai le signal "/PROCEED". Ce signal est un signal périodique à environ 38 Hz généré exclusivement à partir de nombreuses divisions de la clock principale.
D'après moi, ce signal sert à 2 choses :

  • activation temporaire du compteur mécanique de crédits
  • chien de garde : vérification périodique que le signal "OPERATING" (flèche 5 sur mon extrait de schéma) est bien actif
Aucun problème ici.

En 4, j'ai le signal "/RESET" inversé ; c'est normal quand on considère que le signal "OPERATING" est à 0

En 5, le signal "OPERATING" est en permanance à 0.
Je pense que c'est la conséquence d'une panne détectée par l'électronique du PCB.
J'observe sur le schéma que si ce signal venait à passer à 1 avant l'arrivée du front montant de /PROCEED, alors il ferait passer le signal de la flèche 4 à 0 et viendrait donc bloquer le fonctionnement de la bascule JK de gauche.
Le chien de garde serait muselé.

La porte NOR à 3 entrées dont il est issu semble fonctionner, mais je n'ai pas encore investigué en détail là pour le moment.

L'une des 3 entrées de cette porte NOR est le signal "/COLD_START".
Ce signal est généré directement par la PROM IC138 (32 × 8 bits).
Mon oscillo montre les monstrueux glitches présents sur ce signal.
Ces glitches ne sont pas la cause directe de mon problème sur le signal de la flèche 5.
Mais ils sont bien le fruit de la PROM elle-même, car ils sont présents même quand j'isole la broche (le composant étant sur support, il me suffit de plier à peine la broche pour ne pas qu'elle soit insérée dans son contact tulipe quand je remets le composant en place).


signal "/COLD_START", broche 6 de IC138

Du coup, et c'est ce que j'ai fait hier soir, j'ai décortiqué méticuleusement les signaux autour de cette PROM.
GC339 avait indiqué à juste titre qu'un asynchronisme de commutation sur le signal du bus d'adresse pouvait être la raison de ces glitches.
En effet, supposons 2 signaux X et Y qui doivent par exemple passer de X=0,Y=0 à X=1,Y=1.
Si X change un micro-chouilla avant Y ou inversement, alors de manière très fugitive, on aura X=0,Y=1 (si Y a commuté avant X) ou bien X=1,Y=0 (si X a commuté avant Y).
Cette valeur fugitive parasite peut tout à fait expliquer un glitch de lecture : la PROM voit une demande de lecture à une certaine adresse et a le temps de trouver la donnée avant que tous les signaux aient fini de prendre leur valeur voulue.
Les PROMs à fusible étant des composants très rapides, ce scénario est tout à fait plausible.

C'était l'objet de mes investigations de hier soir.

Mon problème est que je ne dispose d'un oscillo qui ne possède "que" 2 voies.
Il peut lire 2 signaux en même temps mais moi, je voudrais en lire 9...
Un analyseur logique TTL à 9 canaux (ou plus) coûte la peau des glaouis.
J'ai donc synchronisé le déclenchement de mon oscillo sur un signal précis : le front montant du signal "/RESET" qui me gêne tant.
Ainsi toutes mes mesures vont être synchronisée sur une référence commune ; je peux donc faire autant de mesures que je veux, il me suffit ensuite d'assembler les captures d'écran avec un logiciel de dessin.

Voici le fruit de pas mal de boulot :


En 1er, j'ai mis le signal /RESET, source de synchro.
Ensuite viennent les 4 bits du bus d'adresse.
Les signaux "/COLD_START", "/VECTOR" et "/PAR2" sont 3 des bits du bus de données.

Chaque trait vertical rouge correspond à un changement sur un bit du bus d'adresse.
Entre les zones 2 et 3, le trait est épais car a2 et a3 n'ont pas commutés pile-poil en même temps. C'est a3 qui a commuté un micro-chouilla avant a2. La mesure n'est pas précise, mais l'ordre de grandeur est inférieur à 16 ns (ça fait 16 milliardièmes de secondes).

D'après le dump de la PROM, voici ce que j'aurais dû trouver sur le bus de données :

Zonea4/a3/a2/a1/a0/COLD_START/VECTOR/PAR2
11/1/1/1/1111
21/1/0/1/1110
2 bis1/0/0/1/1111
31/0/1/1/1111
41/1/1/1/0111
La zone 2 bis est la zone qui correspond au court instant où a3 a déja changé alors que a2 ne l'a pas encore fait.

Observations :

  • pour tout ce relevé, le signal /COLD_START aurait dû être toujours lu à 1 ; hors il se mange 2 glitches
  • même chose pour /VECTOR : il devrait être toujours lu à 1 sur la période de mon relevé, mais il souffre de 2 glitches lui aussi
  • /PAR2 est correctement lu, mais il a aussi la maladie du glitch
  • il semble que c'est une commutation sur a3 qui provoque les glitches (à confirmer par d'autres mesures)

Conclusion :
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

Finalement, je ne suis pas sûr que la PROM soit réellement malade...
J'ai vérifié que pour la génération du signal "OPERATING" (voir flèche 5 de mon 1er schéma), les glitches de /COLD_START n'ont pas d'effet sur la porte logique NOR.


À suivre : suite des investigations en marche arrière. Je vais tenter de trouver pourquoi le signal "OPERATING" reste à 0, faisant aboyer le chien de garde.

EDIT : orthographe