Je vais essayer de répondre dans l'ordre.
J'ai effectivement déjà testé avec une console NES et là tv fonctionne bien - donc TV OK

Une fois tout branché je n'ai toujours pas d'image même si je bascule en mode AV avec la télécommande en manuel.

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+

Avec une photo c'est peut être mieux

Citation de: ttottof le Mardi 17 Février 2026, 07:17:58 AMOk merci,
Je vais demander a Steve car c'est lui qui me la envoyer avec les connecteurs ainsi du coup je trouve bizarre.
Sinon il faudrait que je dessoude les pins et que j'en ressoude pour connecter par dessous pour laisser le blackpill dans le même sens.

Je veux bien la procédure (fichier elf etc)
car j'ai envoyé le firm 1.41 via l'interface WebUI mais plus de demarrage, j'avais donc reinstallé la V1.42

Sinon sans rien faire on ne peut pas programmer le blackpill a part ? ou sinon je met un bout de nappe entre les deux ? la nappe pourrait etre enlever ensuite ? bizarre de m'avoir envoyer ainsi le module

Hier soir j'ai téléchargé mon log file , il me semble manqué le fichier (config.raspisnd not found in /boot/firmware/data/sound/jupk_513) c'est cela que le blackpill doit creer ? ou bien il me manque un fichier à trouver ?

La procédure est détaillée ici :
https://pip.raspberrypi.com/documents/RP-003476-WP-Updating-Pi-firmware.pdf

C'est le paragraphe Updating only the firmware

Concernant le connecteur 4 broches, normalement c'est un droit qui fait la liaison entre le pill et la carte mère (comme les connecteurs 20 broches du côté du pill). Tu peux mettre une nappe/fils si tu as la place. Ce que je ferai c'est de déssouder ton connecteur 4 broches puis je prendrai un connecteur droit 4 broches ou j'enlèverai la partie plastiques noire (tu peux aussi prendre une queue de résistance) afin de le faire glisser dans le trou jusqu'à ce qu'il dépasse de la carte mère puis tu ressoude (je sais pas si je suis clair    )

Intéressant   

Ok merci,
Je vais demander a Steve car c'est lui qui me la envoyer avec les connecteurs ainsi du coup je trouve bizarre.
Sinon il faudrait que je dessoude les pins et que j'en ressoude pour connecter par dessous pour laisser le blackpill dans le même sens.

Je veux bien la procédure (fichier elf etc)
car j'ai envoyé le firm 1.41 via l'interface WebUI mais plus de demarrage, j'avais donc reinstallé la V1.42

Sinon sans rien faire on ne peut pas programmer le blackpill a part ? ou sinon je met un bout de nappe entre les deux ? la nappe pourrait etre enlever ensuite ? bizarre de m'avoir envoyer ainsi le module

Hier soir j'ai téléchargé mon log file , il me semble manqué le fichier (config.raspisnd not found in /boot/firmware/data/sound/jupk_513) c'est cela que le blackpill doit creer ? ou bien il me manque un fichier à trouver ?

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.

Bonjour,

J'avais oublié de mettre en photo l'essentiel dsl.

Je ne pensais pas qu'il fallait découper et retirer les decals au niveau des protections de pieds. J'espère que se n'est pas trop tard car maintenant ils sont bien collés....

Citation de: Aganyte le Lundi 16 Février 2026, 08:51:46 AMJe vois plusieurs chose qui ne vont pas. Déjà, tu as soudé les 4 pins de programmation du black pill vers le haut (donc le Pi ne peut pas programmer le black pill....Donc pas de sons qui arrivent du flip). Ensuite tu es en 1.42, chez moi cette version merde pas mal (elle refuse de faire la programmation auto du black pill au premier démarrage).

Effectivement en 1.42 j'ai jamais réussi à faire la programmation du blackpill donc aucun sons ne sortaient avec le flip mais c'était nickel à travers l'interface wifi. Comme l'a souligné Aganyte, regarde bien tes 4 broches du blackpill. Au cas ou si ça peut aider, en repassant en 1.38 ou 1.41, mon raspberry 3B+ ne bootait plus (Échec d'alimentation Type A -> séquence de clignotement de le led verte), il a fallu que je fasse une mise à jour du firmware (je peux retrouver la procédure, il fallait remplacer les fichiers start.elf et un autre que je me souviens plus...)...

Justement tu as essayé en manuel ?