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.