Bonjour.

Allez, on est vendredi soir, c'est le week-end, je me permets un petit teasing :



Je vous propose de jouer au jeu des sept différences.
Regardez bien la photo, et comparez avec les autres photos de ce WIP. 

À suivre : bah d'après vous ?

Citation de: f4brice le Vendredi 13 Février 2026, 23:04:00 PM

Je vous propose de jouer au jeu des sept différences.
Regardez bien la photo, et comparez avec les autres photos de ce WIP. 

À suivre : bah d'après vous ?

Citation de: f4brice le Lundi 26 Janvier 2026, 21:00:57 PM

J'aime bien le jeu des 7 erreurs, mais j'avoues que je sèche   
1 transistor en haut à droite qui n'a pas le même boitier
Les coups de tampons sur la carte ??
4 roms effaçable UV en bas à gauche sur une carte et sur l'autre 1 rom effaçable UV en haut à gauche 
Je n'arrête pas d'alterner entre ces 2 photos et les différences ne sont pas flagrante    l'avantage, c'est que les photos se superposent presque 

Je continue ma recherche 

Écriture au marqueur différente... une autre PCB, pour un autre jeu vectoriel compatible ?

Ah bah en fait c'est beaucoup plus simple que ça.
Les 2 PCB sont des PCB de Lunar Lander.
C'est juste que celui en photo dans le WIP était présent dans la borne, alors que le 2e m'a été fourni en spare avec la borne.
Donc j'ai simplement deux PCB originaux de Lunar Lander.
Le premier fonctionne, le deuxième ‒ objet du teasing ‒ ben on va voir...

2 Pcb originales, j'avais bien vu que c'était 2 Pcb de lunar lander, mais je pensais que tu venais d'en dénicher une seconde avec quelques différences 
WIP de dépannage que je vais suivre 

Bonjour.

Voici le début du complément du WIP.
Aujourd'hui, je démarre le test du PCB de spare que @spectroman m'a remis lorsque j'ai récupéré la borne.
Grand merci à lui pour cette délicatesse.
Ce PCB, tout comme l'était la borne, est parfaitement untested.

Sachant que ma borne fonctionne, il est maintenant facile de le tester.
Je commence par désoxyder les pistes avec le côté bleu de ma fameuse gomme Maped d'écolier.
Sur la photo, les 4 pistes de gauche n'ont pas encore été nettoyées, alors que toutes les autres l'ont été :



Le PCB est installé dans la borne, et connecté.
Au moment où je mets la borne sous tension, là je vois immédiatement que ce n'est pas comme avec le 1er PCB.
Je n'ai pas d'image, la sécurité "spot killer" de l'écran vectoriel est active, et les lampes du panel clignotent.
Et bien ce PCB va devoir passer par la case "réparation" !
Par chance, je possède une belle alim de labo (récupérée à la benne car en panne ‒ je l'ai réparée) capable de sortir 3 tensions séparées.
Elle sort du 3,3V ou 5V régulé et deux fois de 0 à 32V sous 3,2A max. Ces deux sorties peuvent être parallélisées (pour avoir jusqu'à 6,4A) ou sérialisées (pour avoir jusqu'à 64V avec point milieu).
C'est cette dernière option que j'utilise. Ainsi j'ai du -32V, du 32V et du 5V.

Je m'installe un petit banc de test douillet (pour moi ; je suis une vieille merde, j'ai besoin de mon petit confort), et je commence les vérifications habituelles.

• le +5V est vraiment bas (4,8V) mais on va continuer comme ça
• la clock du CPU est OK
• les diverses ROM sont bien sélectionnées
• le signal /RESET bouge à fond, c'est la fête du slip

Contrairement à certains processeurs plus récent (par exemple le MC68000), le MOS 6502 n'a aucun moyen de contrôler sa pin /RESET.
Pour lui, c'est exclusivement une entrée contrôlée par un circuit extérieur.
Sur ce PCB Atari, ce circuit extérieur s'appelle un WATCHDOG hardware.
Le /RESET qui bouge à fond m'indique donc que ce WATCHDOG est très régulièrement activé.
Les angliches disent "triggered". Moi j'aime bien dire qu'il "aboie".



Ce WATCHDOG commence par un compteur en "D5" clocké à 3kHz.
Après un certain nombre de cycles d'horloge, ce compteur va venir écrire un 1 dans le composant D4.
La sortie complémentée "/Q" (qui sera donc à 0) de D4 est reliée à la pin "/RESET" du CPU et va générer un reset justement.
Après le même nombre de cycles d'horloge, c'est un 0 qui sera ensuite écrit et le CPU va seulement alors pouvoir redémarrer.
Si la ROM du jeu a la bonne idée d'écrire à une certaine adresse (Atari a choisi arbitrairement l'adresse 0x3400), alors le signal "/WDCLR" sur le PCB va être actif un court moment (le temps de l'écriture), et il va forcer le compteur à repartir depuis zéro et l'empêcher de réaliser le reset.
C'est une course contre la montre, à celui qui reset l'autre en premier.
Si le CPU remet à zéro périodiquement le watchdog, alors celui-ci reste invisible, sinon il va aboyer et forcer un reset.
Ça permet de rebooter le PCB si le jeu plante par exemple.

Donc je sais que le CPU n'arrive pas à museler le WATCHDOG.
Il me faut trouver pourquoi.
Il y a de très nombreuses possibilités :

• WATCHDOG en vrac
• CPU en vrac
• pb de décodage d'adresses
• pb de corruption des données lues en ROM
• activation d'une sécurité logicielle pour forcer un reset
• etc...

Le jeu Lunar Lander n'utilise que 15 des 16 bits du bus d'adresse du CPU.
Pourtant, à l'oscillo, je vois que ce dernier bit d'adresse A15 ‒ donc normalement inutilisé ‒ bouge beaucoup.
C'est un indice fort pour identifier une corruption des ROM du jeu.
Je les dump avec un lecteur de ROM / EPROM.
Il y a une manip que j'aime bien faire avec cet outil.

• je lui fait lire une 1ère fois le contenu de la ROM
• j'utilise sa fonction "VERIFY" pour relire à nouveau la ROM et la comparer avec ce qu'il vient de lire juste avant

Pour 3 des 4 ROM, l'outil me dit que la vérification a échoué :



En gros, ça veut dire que la lecture du composant n'est pas fiable.
Pour certaines adresses, 2 lectures de suite ne donnent pas la même data à chaque fois.
Donc le CPU, quand il va lire la ROM pour obtenir la prochaine instruction à exécuter, il reçoit une donnée erronée, et il va exécuter une instruction qui n'est pas du tout celle prévue.

Je décide donc de flasher 4 EPROM avec le dump de Mame "llander".
Sauf qu'il me faut 4 EPROM 2716 et je n'en ai plus que 2 dans mon stock de bazar pourtant bien fourni.
En parlant de ça avec spectroman, il me dit : "ne t'embête pas avec des 2716 ; tu prends des 2732 (deux fois plus grosses et bien plus courantes) qui sont pin-compatibles et tu dupliques ton dump pour qu'il soit présent deux fois dans l'EPROM."
Héhé, c'est une très bonne idée, car des 2732, j'en ai encore 5 ou 6 en stock et mon outil les connait mieux.
La différence 2716 vs 2732, c'est uniquement la broche #21.
Pour la 2716, elle ne sert que lors de la programmation du composant.
Pour la 2732, c'est le bit d'adresse supplémentaire A11 qui n'existe pas sur la 2716.
Donc aucune modification hardware à faire sur le PCB.

En plus, Atari a câblé cette broche #21 à VCC :


En théorie, je peux me contenter de ne flasher le dump Mame que dans la 2e moitié de l'EPROM, et laisser la 1ère moitié non programmée, puisqu'elle ne sera jamais lue.
En pratique, il est plus simple pour moi de concaténer deux fois le même dump de 2kB pour EPROM 2716 en un double dump de 4kB pour EPROM 2732.
Je donne à manger à mon outil de flashage d'EPROM le fichier de 4kB et je n'ai pas à gérer son stress de ne pas avoir un fichier de la bonne longueur pour la référence d'EPROM que je lui indique.

Voici mes EPROM flashées et installées sur le PCB, qui est installé sur mon le banc de test, qui est installé sur mon bureau :



Mon oscillo, en plus des 4 voies analogiques classiques, dispose de 16 entrées numériques.
Ça tombe bien, le bus d'adresse du CPU fait 16 bits. Je branche patiemment et avec minutie les 16 grips-fil sur le CPU.
La sonde jaune est connectée à la pin /RESET du CPU.

Et ce petit montage me permet de faire des mesures sympa.
Lorsque le /RESET devient inactif (quand il passe de 0 à 1) c'est là que le CPU est libéré délivré et qu'il boote.
La doc du CPU 6502 nous explique ce qu'il se passe lors d'un démarrage :



Le silicium du CPU va lire les adresses 0xFFFC et 0xFFFD pour obtenir 2 data de 8 bits chacune (dans le jargon, on appelle ça le "vecteur RESET"), et obtenir ainsi à quelle première adresse il doit commencer à exécuter du code.
Voici ce que mon oscillo mesure au moment du démarrage :



Après un petit moment (la doc dit 6 cycles), on voit que le CPU accède effectivement aux adresses 0xFFFC puis 0xFFFD.
Ma mesure ne dit pas quelles données il a pu recevoir (il me faudrait un oscillo avec 24 voies numériques).
Ensuite, il est allé lire en 0x7B84, puis 0x7B85, etc...
Donc semble-t-il qu'il a reçu 0x84 puis 0x7B. Il recolle ça en 0x7B84 et c'est là qu'il commence à exécuter les premières instructions.
Les adresses 0xFFFC et 0xFFFD correspondent à la ROM "034569-02" située en B1.
Si je vais voir le dump de Mame à cet endroit, voici ce que je lis :



Pas mal, non ?
Donc mon CPU démarre correctement, lit correctement les datas dans l'EPROM que je viens de lui flasher, trouve la bonne adresse et commence à exécuter le code prévu.
Vu que le code source ATARI de Lunar Lander est disponible, chose extrêmement rare et ô combien géniale, je ne résiste pas à jeter un coup d'œil au code source Atari.
La syntaxe de l'assembleur 6502 requise pour l'outil d'Atari en 1979 est un peu toxique, mais on arrive à peu près à comprendre la sémantique.
À l'emplacement 0xFFFC et 0xFFFD, Atari indique une adresse en ROM appelée "PWRON" :



Et quand on regarde le code source à cet endroit, on voit des trucs intéressants :



En <1>, on initialise le pointeur de pile (stack). C'est en effet très important, mais l'utilisation de la pile nécessite une RAM qui fonctionne.
En <2>, on éteint tous les générateurs de bruit (mode mute si vous préférez).
En <3>, on efface toute la RAM "zero page". Le code est très beau, il utilise le fait que les registres du CPU sont 8 bits, et qu'incrémenter la valeur 0xFF va faire repasser le registre à la valeur 0x00.
En <4>, on regarde si l'interrupteur "TESTSW" de la borne est actif ou non. Si on lit 1, c'est qu'il est ouvert donc inactif et on va au label PWRINT.
L'instruction BCS veut dire "Branch if Carry is Set", c'est à dire que le LSR (Logical Shift Right) juste avant a fait sortir un bit qui était à 1.
Sinon en <5>, on va au label "RAMTST".
En gros, si le switch de test de la borne (situé près des monnayeurs) est fermé = actif, on va en RAMTST, sinon on va en "PWRINT".


À suivre : la suite du la réparation de ce PCB.

Intéressant   

Salut,

Merci pour ce rapport détaillé de ton dépannage ! 

En effet, la syntaxe de cet assembleur 6502 est assez surprenante et me paraît assez éloignée des souvenirs que j'ai de l'époque où je programmais mon ATARI 800XL en assembleur 6502 . Lire en parallèle le code désassemblé sous MAME donnerait quasiment quelque chose de plus lisible...

Vivement la suite !

A+

Vraiment impressionnant le niveau... je vais relire tout ça à tête reposée demain!
Merci en tous cas de partager tout ça avec nous de manière aussi claire.

  
C'est impressionnant tout ces détails    J'avoue ne pas tout comprendre à 100% mais j'arrive à suivre la logique 

Super f4brice, bien vu pour la broche css qui est sur a11.
Tu as choisi la bonne solution.
Ça avance bien.

Bonjour.

Voici la suite du complément du WIP.

La dernière fois, j'avais vu le CPU démarrer correctement.
Il trouve la bonne adresse en ROM où il doit démarrer, et semble bien parti.
En faisant le parallèle avec le code source Atari, je me rends compte qu'en fait...
... ben le PCB dispose de son propre diagnostique intégré dans la ROM de jeu :



Il suffit juste de mettre le switch dédié en position "TEST".
C'est ce que je me dépêche de faire.

Finalement, je n'ai aucun son.
Sur mon banc de test, j'observe à l'oscilloscope que le PCB va bien écrire à l'adresse du générateur sonore.
Après examen visuel et à l'oscillo, je découvre qu'un condo dans le circuit audio a une broche arrachée :



C'est un condo non polarisé assez banal.
J'en ai quelques-un de cette race, mais pas de la bonne valeur.
Du coup, je soude un condo d'un autre type, mais qui fera tout aussi bien l'affaire :



Maintenant, avec le circuit audio réparé, j'entends bien les bips de la séquence de test.
Donc du point de vue du PCB, la RAM du CPU et la RAM du générateur de vecteurs semblent bonnes.
Cependant, je n'ai pas d'image sur l'écran de la borne.
La sécurité "spot killer" de l'écran est active.

Si je démarre en mode "normal" (c'est à dire pas en mode test), alors le PCB est reseté par le WATCHDOG.
Pourtant, sur mon banc de test en mode "normal", le PCB semble réparé :



Sur l'oscilloscope en mode X-Y, je reconnais l'attract-mode du jeu :



Il y a donc une différence entre mon banc de test et la borne, qui fait que le PCB fonctionne sur le banc de test mais pas sur la borne.
En réalité, les différences banc de test vs vraie borne sont nombreuses :

• alim stabilisée +28V DC / -28V DC à la place du 2 × 36V AC
• aucune connexion au pannel (potard du réacteur + lampes)
• mon oscillo connecté sur les sorties X-Y a une très grande impédance d'entrée (plusieurs MΩ),
  ce qui n'est pas le cas de l'écran Electrohome (1 kΩ pour X et Y, 220 Ω pour Z)
• rien de connecté sur la sortie Z
• la position : à plat sur mon banc de test vs vertical dans la borne

À suivre : essayer de faire tomber en marche le PCB aussi dans la borne !

Bonjour.

Voici la suite ‒ aujourd'hui cosmétique ‒ du complément du WIP.
J'ai réussi à trouver sur ibé un vendeur sympa en France qui a de l'EPROM 2716 en stock à prix raisonnable.
J'en ai donc commandé 10, en espérant que mon programmateur sache les écrire.
Mon idée, c'est juste de remettre ce 2e PCB de Lunar Lander proche de son état d'origine.
Même si les 2732 que j'ai mises en place précédemment sont techniquement 100% adaptées, j'ai une préférence pour utiliser ‒ quand c'est possible ‒ la bonne référence.
La différence est uniquement dans ma tête de névrosé psychopathe.

Ce matin, je reçois une petite enveloppe à bulles :



Les EPROMS semblent NOS, en tout cas elles sont en parfait état et sans aucune trace d'oxydation.
Ce soir, je tente la programmation d'une EPROM, et ça passe tip-top.
Du coup, j'en programme trois autre avec le reste du dump Lunar Lander de Mame.
Au passage, j'ai aussi sorti l'étiqueteuse qui va bien :



Les EPROM 2732 sont retirées et rangées.
Les EPROM 2716 fraîchement programmées sont mises en place sur le PCB :



Petit test rapide, toujours sur le banc de test : le PCB fonctionne toujours.
Tout va bien, l'échange d'EPROM est réussi.

À suivre : essayer de faire tomber en marche le PCB aussi dans la borne !

Bonjour.

Voici la suite du complément du WIP.
La dernière fois, j'avais juste changé mes EPROM 2732 par des 2716 programmées avec amour, car plus proches des composants d'origine.
Ça ne change rien, sauf à mes yeux !

Je constate que le PCB fonctionne sur mon banc de test, mais dès que je le mets dans la borne, il déconne.
Les différences entre mon banc de test et la borne sont nombreuses : alim, panel, écran, position mécanique...

Je procède par élimination...

1/ la position mécanique

Le PCB, connecté au banc de test, est maintenu vertical par mes petits doigts pas musclés => il fonctionne toujours.
J'en profite aussi pour appuyer à droite et à gauche, voir si je peux mettre en évidence un faux-contact, etc...
Toujours aucun problème, le PCB fonctionne très bien.

2/ l'alimentation

J'installe le PCB dans la borne, mais je déconnecte complètement l'écran + le panel + les monnayeurs.
Il ne reste que l'alim et la sortie audio de connectés.
J'installe aussi l'oscillo pour observer les sorties X et Y, à l'identique du banc de test.
Là je constate que le PCB déconne :



Je suppose donc que le problème vient de la différence entre les alims.
Mon alim de labo fournit de belles tensions DC bien régulées, tandis que la borne envoie du 36V AC que le PCB doit redresser et réguler.
D'ailleurs la partie logique du PCB (qui n'utilise que le +5V) fonctionne.
C'est la partie générateur de vecteurs qui semble ne pas fonctionner.
Et c'est aussi ce générateur de vecteurs qui a besoin des autres alims.
Je note aussi que je n'ai pas capkité le PCB : il y a 11 condos à changer dont 6 sont liés à l'alim.

Suite à un post de Petit_Lapinou, j'ai commandé les 11 condos chez le nantais E44 car les frais de port étaient raisonnables.
Chez DigiKey, les frais de port représentaient 200% du montant de la marchandise, donc j'ai laissé tombé.

À suivre : capkit.