forum.system-cfg.com

@sam : Le changement de bloc + l'attente de l'octet $FE dure en moyenne une dizaine de cycles. C'est très peu par rapport aux 60 cycles entre deux échantillons, et je ne pense pas que ça puisse dépasser. D'ailleurs, si ça dépassait, il y aurait une chance non négligeable de tomber sur un bit 7 à zér...

Je découvre tout juste le logiciel, et je n'ai pas trouvé le moyen d'afficher les valeurs hexadécimales sur la représentation graphique. Par contre les échantillons capturés peuvent être exportés dans différents formats de fichier, en particulier en binaire. En ouvrant le fichier binaire avec un édi...

A mon avis mieux vaut ne pas toucher le programme Thomson et adapter l'Arduino. Il y a des temporisations partout et il est très facile de les ajuster. Reste à comprendre quel octet vidéo est décalé. C'est probablement un déplacement, mais j'ai beau chercher avec l'analyseur, je ne trouve pas. L'err...

Oui, nous sommes bien d'accord, il y a 56 cycles. Par rapport à une boucle normale de 60 cycles il y a donc 4 µs en moins. L'arduino, lui, reste à la cadence d'une boucle normale, il envoie peut-être un ou plusieurs octets vidéo un peu trop tard. Je vais essayer de les écrire encore plus tôt (à la l...

A la fin le MO5 est planté. Par contre hier, quand il se synchronisait mal, il finissait normalement sur un bit 7 à zéro.

As-tu une explication pour les 4 µs manquantes entre les deux premiers bits de synchronisation de chaque bloc ?
C'est une cause possible de décalage.

Le moniteur Thomson n'a rien changé : même problème de plantage. En plus, galère supplémentaire (loi de Murphy ?) : un des plantages a détruit un secteur du fichier boot.sd de la carte micro SD où sont stockés mes programmes. Heureusement, j'avais une sécurité. J'ai eu peur pendant un moment, d'avoi...

Pour la fin de bloc,il y a un JMP PLAY7 (+4cycles) qui est ajouté. Ce qui signifie que l'octet son de fin de bloc est lu avec 4µs de retard par rapport à ce qui est attendu. Je crois qu'à l'oreille on ne peut pas le discerner. Pour l'arduino ça n'a aucune importance, puisqu'il attend le bit de sync...

J'ai modifié le programme arduino pour obtenir ce nouveau timing : 0,3 - 8,3 - 15,3 - 24,3 - 34,3 - 41,3 - 50,3 Ca ne change rien à la vidéo. L'hypothèse d'octets parasites en début de fichier semble assez plausible. Dans ce cas la vidéo redevient-elle normale au bout de quelques images, ou alors es...

Dans l'initialisation de l'Arduino, les interruptions sont désactivées pour éviter toute perturbation dans la vitesse d'exécution. Je n'ai pas encore compris pourquoi l'analyseur détecte au début des octets alternativement à $00 et $FF. Pour l'instant ça reste un mystère et cache certainement une er...

Le chanteur bouge beaucoup, et pourtant il n'y a aucun décrochement de l'image.
On peut faire des démos extraordinaires avec un Thomson

J'ai édité le post précédent et j'ai retrouvé le moral.
Ca va marcher. Peut-être demain, peut-être dans un mois, mais ça va marcher.

Je viens de faire un essai avec une démo arduino qui fonctionne bien : SDPLAY44, qui joue de la musique à 44,1 kHz. Dans le haut-parleur de la télé j'entends bien la musique de CCR. L'analyseur donne un résultat incohérent avec des $00 et des $FF (mais aussi quelques autres valeurs). Le bit de synch...

Pour l'instant je suis dans le brouillard complet. Avec l'analyseur j'obtiens un truc qui n'a strictement rien à voir avec le contenu du fichier .sd. En haut le bit de synchronisation envoyé par le MO5, dessous les bits b0 à b6 de l'octet envoyé au MO5 (b7 n'est pas analysé). Il doit y avoir une err...

L'accès aux machines du réseau et l'accès aux fichiers partagés fonctionne beaucoup mieux avec des IP fixes, c'est évident, je l'ai déjà expérimenté plusieurs fois par le passé. L'impossibilité pour XP d'accéder à l'imprimante partagée de Windows 10 est un problème d'une autre nature : même quand Wi...

Pour le fun, j'ai remis "partage simple" sur la machine XP et j'ai perdu l'accès au fichiers partagés de la machine Windows 10.
La remarque de yo_fr est donc très pertinente