On remarquera qu'il y a 3 irq d'affilé, à chaque fois accompagné d'un coup d'OC sur U30, cela veut donc dire que pour envoyer un commande son, CPU1 envoie 3 BYTES.

j'ai oublié de dire que je suis dans le menu de test de la carte audio dans les setting, en sequenciel.

Je supprime le 6809 de la carte son, et je boote. la CPU1 ne détecte donc pas de carte audio.

je remets en mode test de la carte son en sequentiel, et je vois que les ecritures sur le port 3FDC sont toujours presents, donc la cpu1 ne désactive pas les envois de données sur la carte son quand elle n'a pas été détectée au boot, ce qui sera pratique pour les tests.

Nous allons donc devoir nous atteler a replacer le 6809 par un 328p, afin de simuler les reponses au irq, et de lire les valeurs sur le bus de données.

on notera que le temps entre 2 impulsions a un mini d'environ 1ms, il conviendra de traiter les demandes dans ce temps imparti, et suffisamment long pour gerer cela avec des interruptions sur le 328p.

Merci de partager tes recherches, c'est top 

Donc voila, je sors mon atmega2560 et je viens plugger à la place du 6809
le portA sur le bus de données
le PB0 sur l'irq
le PC0 sur l'OC de UC30 LS374, qui vient en meme temps effacer le latch de l'irq LS74

je fait ensuite un petit code arduino, qui affiche les données recupérée sur le bus à chaque interuption sur le terminal.

je recupere à chaque changement de son dans le mode test dans les menu, les groupes de valeur

126-125-127-126-125-127-3 (MAIN PLAY)
126-125-127-126-125-127-4 (GET JACPOT TUNE)
126-125-127-126-125-127-7 (M.BALL LIT TUNE)
126-125-127-126-125-127-20 (VIDEO MODE TUNE)
126-125-127-126-125-127-178 (DATABASE BACKGR.)
126-125-127-126-125-127-191 (100K AWARD)
126-125-127-126-125-127-198 (ALARM SOUND)
126-125-127-126-125-127-122-37 -> ici on recis 2 octets (GET THE CPU)
126-125-127-126-125-127-122-39 -> ici on recis 2 octets (AUTOFIRE)
126-125-127-126-125-127-122-40 -> ici on recis 2 octets (VIDEO MODE)

on dirait que la CPU1 envoie du code morse 

en tout cas, 3 | 4 | 7 | 20 | 178 | 191 | 198 | 122-37 | 122-39 | 122-40

sembles être les ID de sons en question.

Je vais aller jeter un oeil sur le fichier csv altsound du T2, et les comparer au titres qui s'affiche sur le DMD.

voila, cela correspond bien voici les fichiers en question, les valeur etant en hexa dasn les nom de fichiers.

donc, si l'octet est $7A alors la carte son attendra un 2eme octet derrière, sinon c'est un seul octel.

je pense que la séquence 126-125-127 ($7E-$7D-$7F) est probablement un sequence qui permet à la carte son de recommencer la lecture à zero et de vérifier que la chaine de comm fonctionne correctement, car il ne doit pas avoir pire qu'une carte son qui balance du n'importe quoi dans un bistrot, mieux vaut ne rien emmetre.

Bon allez, aujourd'hui, on ne lache pas le truc, et on remplace la carte wpc89 par un cpu wpc95 avec la rom de l'AFM, afin de regarder un peu si le protocol ressemble.

On recois donc des données, mais cette fois çi par groupe de 2BYTES.

donc par exemple pour l'envoie d'une sequence nous avons la suite suivante :

3:227
3:230
3:229
3:227
3:230
3:229
0:10

comme sur le protocol pre-dsc, on a bien un sequence de but de trame de 6 codes de control, mais cette fois çi 16bits à lieu de 8. après cela suis la data en elle même qui est ici 0:10 donc $000A. je vais faire un verification avec les sequence musicales de altsound.

Faut pas lacher, une version open source serait géniale  Tous les gars qui ont bossé là dessus on fait des versions sous licences. Je veux bien participer au projet si besoin 

Effectivement c'est super intéressant tout ça ! Je suis entièrement d'accord que le côté closed source des Pin2DMD/GoDMD/TiltAudio est vraiment relou. C'est n'est pas un problème de sousous avec l'achat de la licence mais de partage de l'info. Effectivement l'auteur répond volontiers au debut et arrête du jour au lendemain sans permettre le maintien à jour de ses cartes, ce qui est bien dommage ...
Bon courage, c'est très sympa de te lire et de te voir avancer.

Oui, avoir un truc open source serait vraiment super. Mais je n'ai pas la compétence seul pour aller jusqu'au bout. En dehors dehors des phases des verification de version de la carte son au démarage, il restera a voir pourquoi un AFM demande une verification du son joué en cours apres avoir démarré un theme, et comment il le fait. Ca j'en fait mon affaire.

Mais apres, je suis un peu dans le flou sur avec quel type de pros (microcontrolleur ou plus puissant) il faudra jouer les sons. Sur le wpc95 c'est 6 canaux a jouer en paralelle, et cela ne semble pas aussi simple que de démarrer un mp3 et puis basta....

Aganyte a l'air de penser qu'un atmega ca fait le job. Je suis septique et j'aimerais bien qu'il nous indique son idée ici.

C'est parceque tu te mets en tête de gérer le son avec le microcontroleur. Si tu prends un module à part comme le WavTrigger, les choses deviennent tout de suite plus simple 

https://www.robertsonics.com/wav-trigger

Donc ton truc, faut juste le manager avec des commandes start stop, etc. Ok, faut regarder le protocol de comm du biniou. Car il faut au moins qu'il balance l'info a l'atmega qu'une track vient de finir.


Par exemple, il y a des sons qui ont un effet sur les autres canaux en cours. Par exemple le son de la loterie fait baisser le theme en cours pendant le calcul de la loterie.

Mais cela serait fun si cela fonctionnait.

Pinsound a au moins le merite de ne pas faire semblant. C'est un produit commercial, pro, sans bug. Mais irréparrable et fermé. J'avais une pinsound+ qui trainait dans un tiroir depuis 2 ans, et j'ai halliciné la prise de tête pour installer un simple pack de son de l'afm car ils ont tout protegé au cause du projet tiltaudio, la pinsound 1 c'etait tellement plus simple. La tu sais meme plus comment acceder a tes sons....


Tiltaudio/pin2dmd, ce sont les gars qui te font croire que c'est open en filant les schema et brd de la carte, mais il suffît d'essayer de contacter l'auteur d'un des projets, pour comprendre que tu n'auras jamais aucun support, et en plus cette equipe tiltaudio-pin2dmd sont d'une arrogance demesurée envers tout ce qui n'est pas casque a pointe.... Mais bon, ils savent au moins mettre entre autres des idées en communs en rangeant leur fierté, ce qui n'est pas trop le cas chez nous (ceux qui savent en france et qui ne veulent pas m'aider se reconnaitrons, car je sais qu'ils lisent ce thread)

Quand je parle d'aider, c'est aider a casser un protocol et apporter de l'idée, et surement pas m'expliquer comment on fait une sérigraphie sur un brd de proto....

Citation de: Sebinouse le Lundi 31 Juillet 2023, 10:19:14 AMEffectivement c'est super intéressant tout ça ! Je suis entièrement d'accord que le côté closed source des Pin2DMD/GoDMD/TiltAudio est vraiment relou. C'est n'est pas un problème de sousous avec l'achat de la licence mais de partage de l'info. Effectivement l'auteur répond volontiers au debut et arrête du jour au lendemain sans permettre le maintien à jour de ses cartes, ce qui est bien dommage ...
Bon courage, c'est très sympa de te lire et de te voir avancer.

Je vais potasser la doc du Wavtrigger quand j'aurai 5 minutes mais je pense que ça devrait le faire.

Ok aganyte, mais il faut étaler ici les différents types de sons wpc, en gros comprendre les paramètres des fichiers altsound, tu les connais toi ?

Citation de: Aganyte le Lundi 31 Juillet 2023, 12:04:15 PMJe vais potasser la doc du Wavtrigger quand j'aurai 5 minutes mais je pense que ça devrait le faire.

Je ne vois pas de quoi tu parles, une adresse = un son non ?