Bonjour
en suite d'un article que j'avais commencé sur Flipjuke et que je désire migrer ici
https://www.flipjuke.fr/viewtopic.php?f=58&t=150380
Pour résumer, je me suis mis à la réalisation d'un PCB qui regroupe le schéma original de la carte DMD, et de TILTAUDIO, afin de faire une carte unique qui remplace en plug&play la carte WPC95 originale.
j'ai fini par cablé le PCB de proto, et après de nombreuses heures de déboire, j'ai enfin réussi à voir l'image.
Maintenant, il reste à cabler à partie Audio de la tiltaudio sur le pcb de proto.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/13/20230713121124-Bio%20STEIN-IMG_6333.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/13/20230713121124-Bio%20STEIN-IMG_6333.jpg)
Excellent !
^-^ :-*
Aujourd'hui, j'ai reçu quelques composants qui me manquait pour continuer mes test.
Je finis donc le cablage de la carte jusqu'au convertisseur DAC PCM1702A que je branche directement sur des box à entrée jack3,5 afin de laisser le cablage des amplis de puissance à plus tard.
Je démarre le flip, rien ne brule, c'est dejà cela.
En premier lien, la carte son est bien détecté par la cpu, car sans elle fait une pause au boot assez longue, et la le chargement est normal. La version detectée est 7.97. cela veut dire que la black-pill est bien programmée en mode WPC, et qu'elle répond aux commandes de la cpu.
Je vais dans les menu du WPC dans les tests de son, et je fais tourner les sons en boucle, les uns après les autres. Tout est normal.
Je sors des tests WPC et je lance une partie, et là mes soucis commencent. La cate son fait n'importe quoi. c'est inexplicable comme phénomène, on dirait que la cpu envoie des commandes erronées, et la musique de fond est incapable d'être jouée. Au démarrage du jeu normal, il y a normalement une bande son avec un narrateur à la radio qui explique l'attaque des martiens. Ce son commence 1 seconde, s'arrête, et ensuite remplacé par un autre son qui tourne en boucle et coupé toutes les secondes.... pendant le jeu, si je fais aller des contact, il y a bien les sons correspond, mais rien à faire avec la bande son de backgroud, on dirait qu'elle est constamment interrompue.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725074647-Bio%20STEIN-IMG_6399.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725074647-Bio%20STEIN-IMG_6399.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725074647-Bio%20STEIN-IMG_6400.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725074647-Bio%20STEIN-IMG_6400.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725075343-Bio%20STEIN-IMG_6406.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725075343-Bio%20STEIN-IMG_6406.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725075120-Bio%20STEIN-IMG_6405.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725075120-Bio%20STEIN-IMG_6405.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725075829-Bio%20STEIN-IMG_6407.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725075829-Bio%20STEIN-IMG_6407.jpg)
En premier lieu, j'incrimine la cpu, qui est neuve, et qui a des circuit TTL des port I/O en HTC244/245 plutot qu'en technologie LS. Je vais donc chercher une carte cpu originale dans mon champion-PUB, et je l'installe sur l'afm à la place de la neuve. -> rien n'y fait, même problème. J'avais déjà installé des resistances de 100 ohms sur le bus, plutôt que de 50, donc j'étais un peu septique. Maintenant, je ne comprends toujours pas pourquoi il mets des resistances de valeur si faible sur tout le bus d'adresse et de donnée SAUF D0 ou il ajoute un 10K en parallèle... bizarre, faudrait que je regarde si une tiltaudio original fonctionne cablée en 10K sur le bus.
il y a quelque jours, j'avais installé une tiltaudio normal dans un docteur-who, et je sais qu'elle fonctionne. Je me dis donc que je vais reproduire la même configuration dans le WPC, c'est à dire installer une carte DMD ORIGINAL et une TILTAUDIO normal et voir comme ca fonctionne....photo en dessous...
Et bien non, cela ne fonctionne pas, même problème, et je me demande donc si quelqu'un a reussi à faire fonctionner cette configuration, afin de laisser la carte AV95 originale dans le tiroir à l'abris des destruction de certains composants aujourd'hui pratiquement introuvables.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725081621-Bio%20STEIN-IMG_6403.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725081621-Bio%20STEIN-IMG_6403.jpg)
Allez, dernière possibilité. Tiltaudio normale, avec la carte AV95 orginal.
ET bien oui, cela fonctionne, malgré le fait que sur le bus il y a 2 cartes son qui répondent en même temps au mêmes commandes, cela fonctionne...
Si quelqu'un a une idée du pourquoi, sur un WPC95, la tiltaudio a besoin de la présence de la carte son original pour focntionner, je suis preneur, car pour l'instant je suis bloqué !
ce qui est étrange, c'est que le WPC avec la carte son DCS, c'est pratiquement la même chose, alors pourquoi ca fonctionne là et pas ici ?
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725082142-Bio%20STEIN-IMG_6404.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725082142-Bio%20STEIN-IMG_6404.jpg)
Bon...
par acquis de conscience, j'installe la carte sur le medieval madness qui n'est pas loin...
Et là, tout fonctionne bien !!!!!!! carrement délire, je me demande vraiment pourquoi cela ne fonctionne pas sur un AFM...
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/25/20230725091209-Bio%20STEIN-IMG_6409.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/25/20230725091209-Bio%20STEIN-IMG_6409.jpg)
Sur le monster bash j'ai déjà testé les 2 cartes sons (originale + Tilt audio) et effectivement ça marche bien.
Pour le reste on dirait un problème de lecture du bus (peut être une histoire de pull-up ou autres qui seraient présente sur la carte originale). Maintenant pourquoi ça marche sur le MM ? ils ont peut être tout simplement changé la vitesse de communication du bus (une vitesse plus basse serait moins gênée par des soucis sur le bus).
https://youtu.be/-JO7b50fyts
J'aimerais vraiment savoir si quelqu'un a déjà essayé la tiltaudio avec un simple carte dmd89 à la place de la carte AV95 originale. autant j'arrive à faire fonctionner sur MM, autant sur l'AFM et le JY, cela ne fonctionne pas. J'ai l'impression que la CPU attends une confirmation de commande de la carte son que la tiltaudio n'envoie pas, et donc la cpu fait des retry en permanence. Peut-etre la présence en parallele de la carte AV95 orignal cache le bug, car elle envoie elle même les réponses. je ne vois pas d'autres explications.
2021-01-27 10:41:29.382 DEBUG SndServi [playMusicWithFadeInAndPos] [sdl_sound.c:1530] loaded music from '/boot/data/sound/jy_12/0x0002-main_theme.ogg' loop=1
2021-01-27 10:41:29.385 DEBUG SndServi [playMusicWithFadeInAndPos] [sdl_sound.c:1553] Playing Music id=2(0x0002), 'main_theme:0' gain:50, from /boot/data/sound/jy_12/0x0002-main_theme.ogg
2021-01-27 10:41:29.385 DEBUG SndServi [getVolumeForSample] [sdl_sound.c:1058] getVolumeForSample: sample->gain: 50, gainByType: 50, res: 35
2021-01-27 10:41:29.385 DEBUG SndServi [setMusicVolume] [sdl_sound.c:529] setMusicVolume to 35 (musicVol=35, ducking=100)
2021-01-27 10:41:33.295 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:33.296 DEBUG isr wpc [wdenInterrupt] [pincom.c:309] wpc cmd 00001 000 0x00 00000000 len: 2
2021-01-27 10:41:33.297 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x00 0x00 0x00 0x00, id: 0
2021-01-27 10:41:33.468 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:33.503 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00001 085 0x55 01010101 len: 4
2021-01-27 10:41:33.504 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00002 170 0xaa 10101010 len: 4
2021-01-27 10:41:33.505 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00003 071 0x47 01000111 len: 4
2021-01-27 10:41:33.506 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00004 184 0xb8 10111000 len: 4
2021-01-27 10:41:33.506 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x55 0xaa 0x47 0xb8, id: 85
2021-01-27 10:41:33.506 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2071] Setting volume to 71
2021-01-27 10:41:33.506 DEBUG SndServi [setVolume] [sdl_sound.c:335] volume: 35
2021-01-27 10:41:33.506 INFO SndServi [minidisplay_setText] [minidisplay.c:93] print 0,40: 'M: WPCDCS V: 35 '
2021-01-27 10:41:33.520 DEBUG MiniDSer [miniDisplayHandler] [minidisplay.c:114] processing message 'M: WPCDCS V: 35 '
2021-01-27 10:41:33.590 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:33.591 DEBUG isr wpc [wdenInterrupt] [pincom.c:309] wpc cmd 00001 000 0x00 00000000 len: 2
2021-01-27 10:41:33.591 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x00 0x00 0x00 0x00, id: 0
2021-01-27 10:41:33.592 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:33.593 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00001 002 0x02 00000010 len: 2
2021-01-27 10:41:33.593 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x00 0x02 0x00 0x00, id: 2
2021-01-27 10:41:33.594 DEBUG SndServi [playMusicWithFadeInAndPos] [sdl_sound.c:1530] loaded music from '/boot/data/sound/jy_12/0x0002-main_theme.ogg' loop=1
2021-01-27 10:41:33.598 DEBUG SndServi [playMusicWithFadeInAndPos] [sdl_sound.c:1553] Playing Music id=2(0x0002), 'main_theme:0' gain:50, from /boot/data/sound/jy_12/0x0002-main_theme.ogg
2021-01-27 10:41:33.598 DEBUG SndServi [getVolumeForSample] [sdl_sound.c:1058] getVolumeForSample: sample->gain: 50, gainByType: 50, res: 35
2021-01-27 10:41:33.598 DEBUG SndServi [setMusicVolume] [sdl_sound.c:529] setMusicVolume to 35 (musicVol=35, ducking=100)
2021-01-27 10:41:37.509 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:37.510 DEBUG isr wpc [wdenInterrupt] [pincom.c:309] wpc cmd 00001 000 0x00 00000000 len: 2
2021-01-27 10:41:37.510 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x00 0x00 0x00 0x00, id: 0
2021-01-27 10:41:37.682 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:37.717 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00001 085 0x55 01010101 len: 4
2021-01-27 10:41:37.717 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00002 170 0xaa 10101010 len: 4
2021-01-27 10:41:37.719 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00003 071 0x47 01000111 len: 4
2021-01-27 10:41:37.719 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00004 184 0xb8 10111000 len: 4
2021-01-27 10:41:37.719 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x55 0xaa 0x47 0xb8, id: 85
2021-01-27 10:41:37.720 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2071] Setting volume to 71
2021-01-27 10:41:37.720 DEBUG SndServi [setVolume] [sdl_sound.c:335] volume: 35
2021-01-27 10:41:37.720 INFO SndServi [minidisplay_setText] [minidisplay.c:93] print 0,40: 'M: WPCDCS V: 35 '
2021-01-27 10:41:37.722 DEBUG MiniDSer [miniDisplayHandler] [minidisplay.c:114] processing message 'M: WPCDCS V: 35 '
2021-01-27 10:41:37.804 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:37.805 DEBUG isr wpc [wdenInterrupt] [pincom.c:309] wpc cmd 00001 000 0x00 00000000 len: 2
2021-01-27 10:41:37.805 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x00 0x00 0x00 0x00, id: 0
2021-01-27 10:41:37.805 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00000 000 0x00 00000000 len: 2
2021-01-27 10:41:37.807 DEBUG isr wpc [wdenInterrupt] [pincom.c:355] wpc cmd 00001 002 0x02 00000010 len: 2
2021-01-27 10:41:37.807 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:2062] wpcSoundHandler cmd: 0x00 0x02 0x00 0x00, id: 2
2021-01-27 10:41:37.808 DEBUG SndServi [playMusicWithFadeInAndPos] [sdl_sound.c:1530] loaded music from '/boot/data/sound/jy_12/0x0002-main_theme.ogg' loop=1
2021-01-27 10:41:37.812 DEBUG SndServi [playMusicWithFadeInAndPos] [sdl_sound.c:1553] Playing Music id=2(0x0002), 'main_theme:0' gain:50, from /boot/data/sound/jy_12/0x0002-main_theme.ogg
2021-01-27 10:41:37.812 DEBUG SndServi [getVolumeForSample] [sdl_sound.c:1058] getVolumeForSample: sample->gain: 50, gainByType: 50, res: 35
2021-01-27 10:41:37.812 DEBUG SndServi [setMusicVolume] [sdl_sound.c:529] setMusicVolume to 35 (musicVol=35, ducking=100)
2021-01-27 10:41:40.500 DEBUG MHD-sing [requestHandler] [httpservice.c:2103] url: /raspin.log, method: GET, version: HTTP/1.1, connCtx: 0x0000
2021-01-27 10:41:40.500 INFO MHD-sing [handleLogFileRequest] [httpservice.c:1796] request for logfile
Là pour le coup il n'y a que le créateur de la Tilt Audio qui pourrait te dépanner je pense.
bon, globalement, je n'aurai pas d'aide de l'auteur de tiltaudio pour résoudre mon problème, il m'a répndu au debut et après plus rien.
En conclusion, ne pas faire des développements sur des codes informatiques que tu ne maitrises, surtout quand ils ne sont pas ouverts.
J'ai donc passé quelques jours à essayer de comprendre ce qui ne fonctionnait pas et mon analyse est la suivante :
le CPU d'un wpc communique avec les connections suivantes vers une cartes son, et cela est valable pour les 3 types de carte son, pre-dcs, DCS et AV95, si on considère que les 2 dernières sont différentes, mais cela ne semble pas vrai en pratique, on le vérifira par le temps.
- le Bus de données D0 à D7
- le bus d'adresse A0 à A4
- le signal WDEN
- le signal R/W
- le signal IRQ
concernant le signal IRQ venant de la carte audio (car l'irq est aussi sur la carte son) il semble qu'il n'ai pas été utilisé, j'ai trouvé le jumper non cablé sur les carte pre-dcs, et sur la AV95 de mon AFM, j'ai levé la resistance du transistor qui gère l'irq, j'ai toujours le son comme il faut, mais pas la video (peut-etre il y a des phases du jeu qui l'utilise, mais je n'ai pas approfondi plus que cela, mais dans un premier, temps, on va admettre que l'irq n'est pas utilisé pour les 3 types type de carte son.
Dans un premier temps, nous allons analyser le schéma de la carte son pre-dcs, et plus précisement le fonctionnement des commuications entre la cpu de la carte audio et la cpu principale. on va appeler CPU1 pour la carte mere et CPU2 pour la carte son.
le 6809 de la carte CPU2 tourne avec un oscillateur de 8Mhz, comme la carte CPU1 principale. cela pose un probleme de com, car quand la cpu1 envoie des données sur le bus de données en baissant le signal WDEN, la cpu2 a cause de l'execution du code généré par l'irq n'a pas le temps de recuperer les données directement. il y a donc un systeme de Latch basé sur des LS3734, un pour l'entrée des données (R/W à write), l'autre pour la lecture (R/W à read)
les port utilisés sont
- $3FDC pour les données en entrée et sortie des datas
- $3FDD est un bus de control qui est imortant de comprendre.
pour déclencher un son, la CPU1 va ecrire sur le port $3FDC une valeur en 8bit qui correspondra à un son à jouer, donc dans le cas de la carte pre-dsc, 256 sons possible. les caractéristiques de chaque son music, jingle, etc..(loop ou autres) ne sont pas gérés par la cpu, mais encodés dans le rom de la carte son pour chaque son. jusque la tout va bien, on va dire que cela simplifie les chose pour le décodage du protocole de comm. donc quand la CPU1 envoie une data sur le port $3FDC, il fait tomber le signal WDEN pendant 350us. Comme cela génére une irq sur la cpu2 et que la gestion d'une irq est assez lourde à cause de la mise en stack, cette cpu2 n'a pas le temps de prendre la donnée directement, et cela fait bien longtemps que la CPU1 est passée à autre chose. Donc la valeur est stockée dans le latch U30, et la cpu2 viendra chercher cette valeur un peu plus tard, juste le temps de mettre en route son IRQ. Bon juste pas, pas trop compliqué. Ce qui est malin, c'est que le coup de clock de WDEN, va déclencher le latch LS74 U24b qui décenche l'irq de la CPU2, mais quand la CPU2 va lire la valeur de U30, cela va remettre ce lactch U24b à zero sans que cela ne soit géré séparément. une fois que la CPU2 a géré la valeur demandé par CPU1, elle sort d'interruption, et se mets à nouveau en attente d'autre commandes.
Jusque là, on avait pas besoin de plus et la carte son pourrait tres bien fonctionner en ecoutant seulement le port $3FDC. Mais au démarrage du flip, on peu remarque que dans les menus au debut, le DOT affiche la version de rom de la carte SON !!!!! a ben comment fait-elle donc ???
comme j'ai expliqué la cpu2 n'est pas assez rapide pour repondre à la cpu1, donc un systeme à été mis en plus pour rendre la communication bi-directionnele ASYNCHRONE. En gros, la CPU2 va lire le port de commande $3FDD et voir si le bit 7 est à 1 (pourquoi avoir choisi le bit 7, je sais pas, peut-etre il font un shift et cela lève une carry dans le 6809 et ca va plus vite) Si le bit 7 est à zero, pas de données presente dans le latch U29, donc rien à faire. si le bit7 est à un, alors cela indique à la cpu1 qu'un donnée est presente du le port $3FDC et qu'elle peut la lire. la cpu fait donc une lecture du port $3FDC et cette lecture efface au passage le flag qui se trouve dans U24a, afin que la donnée ne soit pas lue plusieurs fois.
Si vous débrancher la nappe de la carte son d'un WPC, on peut remarquer que la cpu mets plus de temps à s'initialiser. EN fait, elle doit surement faire des lecture sur le port de control $3FDD en répétition, jusqu'a ce que le cpu2 soit bootée et qu'en mette la version de rom sur le PORT $3FDC.
les premières versions de TILTAUDIO implémentaient seulement un decodage d'addresse à l'aide de TTL et le raspberry mettait trop de temps à booter pour certains flip, et ne présentait pas la valeur de le ROM sound suffisament vite pour la CPU1 et mettait donc la carte son en défaut. le projet tiltaudio à donc évolué, et une blackpill STM32 à remplacé le décodage d'adresse en TTL, afin qu'il presence lui meme la sound rom (il repond surement n'importe quoi) car le STM32 boot beaucoup plus vite. Mais ensuite, le STM32 ne fait plus d'écriture dans la CPU1 et ne repondra plus jamais à des demande de lecture de la part de la cpu1, car c'est comme cela que cela à été implementé.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730075139-Bio%20STEIN-Capture%20d%C3%A9cran%202023-07-30%20%C3%A0%2008.50.42.png) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730075139-Bio%20STEIN-Capture%20d%C3%A9cran%202023-07-30%20%C3%A0%2008.50.42.png)
Alors, pour quelle raison j'analyse tout cela.
Tiltaudio est un projet interessant, car il permet d'envoyer des commandes à un petit arduino (ou autre) grace à une programmation LUA dans l'interface, chose qu'une pinsound ne sait pas faire. J'ai besoin de ces events pour un projet plus goblal sur l'AFM. Comme je désire ne plus mettre en route mes carte audio av95 car des composants dessus sont devenus rares ou indisponible et que cela ne va pas s'arranger dans le temps, j'ai donc réalisé le project tiltaudio95 qui fusionne les schémas de la carte DOT89 et ceux de la tiltaudio, afin de faire une carte véritablement plug&play sur un wpc95, et non pas le bricolage qu'il faut faire actuellement avec un tiltaudio basique ou une pinsound.
Donc je démarre ma tiltaudio95 sur mon AFM pour la première fois et là gros probleme. le son du theme démarre, mais il redemarre au debut toutes les 3sec. je passe dans les logs de la tiltaudio et effectivement, la CPU1 envoie un commande de démarrage du même theme toutes les 3 sec, une sorte de retry en permanence. je repart depuis le debut et je monte une tiltaudio normale, avec un dot89 sur mon afm, et le MEME PROBLEME, le theme redemarre toutes les 3sec.... zut, pourquoi cela. Je remets donc la carte AV95 à la place de la carte dot89, et la tiltaudio original en paralelle le TOUT FONCTIONNE BIEN... tiens tiens.
cela veut donc dire que sur l'afm, la carte son av95 original reponds à des commande que la tiltaudio ignore, et c'est la raison pour laquelle cela fonctionne, mais si on enleve la carte son d'origine, la tiltaudio ne peut pas fonctionner seule sur un AFM.
Par acquis de conscience, j'ai mis ma tiltaudio95 sur me medieval, et la surprise, tout fonctionne bien. par contre sur le Junk-Yard cela ne fonctionne pas. J'en déduit que à partir du MM, les programmeurs WPC ont changé un truc dans la gestion du son, et sur l'afm, la cpu1 doit demander à la carte son si ce qu'il a demandé de joué à bien été prise en compte en faisant un lecture dont je doit determiner la teneur, alors que cette confirmation à surement été supprimé sur le MM. Je n'ai pas encore fait des test sur des flip qui sont apparu apres le MM, tel le MB, il faudra que je test.
Donc pour moi, dans l'état actuelle des chose, le ne peut continuer avec le projet tiltaudio, car le source n'est pas disponible et l'auteur n'est pas disposé à corriger ce probleme. Pour info, j'ai essayé avec un pinsound sans la carte av95 et cela fonctionen bien, pinsound implémente bien le protocol de comm au complet.
je vais donc essayer de décoder par mes propres moyens le protocol de comm de la carte son, afin d'obtenir les event son dont j'ai besoin pour mon projet.
Dans un premier temps, on va analyser tout cela sur un vielle carte son pre-dcs.
je fais donc un montage sur mon banc de test wpc, avec un cpu WPC89 avec la rom du T2 dans un premier temps.
le carte audio n'a pas de 6809 et je viendrai y mettre sur son support une petit proto avec un 328p sur lequel je vais y installer le bootloader arduino, et pour le reste du décodage, on utilisera le schéma initial de la carte pre-dcs.
En gros, je dois lire le bus de donnée D0-D7 du 6809, quand une irq se presente, en n'oublient pas de donner le coup de clock sur la broche 1 de U30, afin d'effacer l'irq.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730090052-Bio%20STEIN-IMG_6435.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730090052-Bio%20STEIN-IMG_6435.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730090052-Bio%20STEIN-IMG_6436.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730090052-Bio%20STEIN-IMG_6436.jpg)
j'ai mis une carte son fonctionnelle.
en haut, le signal de l'irq qui arrive sur le 6809. on voit que le CU mets 13us don 26 cycles pour aller lire la donnée.
en bas, le signal de OC (outpout control, broche 1 des U30) pendant la lecture de la valeur du 374.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730105601-Bio%20STEIN-DS1Z_QuickPrint1.png) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730105601-Bio%20STEIN-DS1Z_QuickPrint1.png)
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.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730110038-Bio%20STEIN-DS1Z_QuickPrint3.png) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730110038-Bio%20STEIN-DS1Z_QuickPrint3.png)
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.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730192339-Bio%20STEIN-IMG_6439.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730192339-Bio%20STEIN-IMG_6439.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730192339-Bio%20STEIN-IMG_6440.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730192339-Bio%20STEIN-IMG_6440.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730192339-Bio%20STEIN-IMG_6441.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730192339-Bio%20STEIN-IMG_6441.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730192710-Bio%20STEIN-IMG_6442.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730192710-Bio%20STEIN-IMG_6442.jpg)
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 :D
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.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/30/20230730200902-Bio%20STEIN-Capture%20d%C3%A9cran%202023-07-30%20%C3%A0%2021.08.20.png) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/30/20230730200902-Bio%20STEIN-Capture%20d%C3%A9cran%202023-07-30%20%C3%A0%2021.08.20.png)
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.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/31/20230731083714-Bio%20STEIN-IMG_6444.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/31/20230731083714-Bio%20STEIN-IMG_6444.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/31/20230731083714-Bio%20STEIN-IMG_6445.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/31/20230731083714-Bio%20STEIN-IMG_6445.jpg)
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/31/20230731083714-Bio%20STEIN-IMG_6446.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/31/20230731083714-Bio%20STEIN-IMG_6446.jpg)
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 ?
Regarde la section audio de cette page.
https://www.npmjs.com/package/wpc-emu/v/0.34.5#pre-dcs-a-12738
background music: plays as long the file lasts (optional timeout or looping)
sound effect: is mixed to background music
voice callout: is mixed to background music.
jingle: is mixed but background music is paused or lowered, then resumed
single: as jingle but no resume, background music stops after single
Tu tires quelle conclusion pour le jingle et le single ?
Citation de: Aganyte le Lundi 31 Juillet 2023, 13:10:37 PMJe ne vois pas de quoi tu parles, une adresse = un son non ?
ça me semble clair. Il faudra gérer le module audio en fonction de ça. On peut le faire depuis l'Atmega.
Pour la gestion, soit tu fais des dossiers (façon pinsound), soit chaque titre de fichier son contient un numéro d'identification pour savoir de quel type il est.
On peut aussi imaginer une carte SD contrôlé directement par l'Atmega qui contient un fichier txt ou csv avec l'identification de chaque fichier.
Lol, delire, je vais de regarder les schémas du wavtrigger, exactement comme j'imaginais pouvoir le faire :
- 1 stm32
- 1 dac
Le probleme c'est que le code n'est pas ouvert, on est pas avancé à ce niveau mais au moins avec ce modules, on peut deja voir si cela tiens la route au niveau hardware et surtout on a les schémas electroniques et les composants sont standards et perreins.
Les schemas dates de 2014 et deja il mixait 14 pistes, donc cela enleve mes doutes quand a la capacité d'un st32 de faire ca.
Les schemas sont sous eagle. Je les ai ouvert. Donc intégrable sur notre pcb.
ah oui, tu veux carrement refaire le Wavtrigger. Là ça va être un peu plus chaud pour le code sur le STM32.
Non, c'est pas ce que je veux dire.
Dans un premier temps, on fait un proto sur la carte de sparkfun. Si on voit que c'est viable, alors on se passe de la board de sparkfun en faisant non meme notre board, mais toujours avec les sources qui ne sont pas de sparkfun mais d'une autres personne, regarde dans la section firmware.
Et peut etre un jour on trouvera un moyen d'ecrire les sources du firmaware nous meme, car la y'a du taf quand meme.
Je vois le soft de programmation mais il n'est pas stipulé qu'il sert à flasher la carte.
Effectivement, il y a des firmwares en bas de page. Par contre, il faudra voir si il n'y a pas un système de protection.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/07/31/20230731165520-aganyte-Sans%20titre.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/07/31/20230731165520-aganyte-Sans%20titre.jpg)
Mais pourquoi donc sparkfun donnent-ils les sources eagle si le firmware ne fonctionne qu'avec les boards sparkfun sous licence ;D . On dirait tiltaudio, qui fait croire a de l'open source en donnant les schemas eagle pour piquer les clients pinsounds, mais c'est toujours aussi fermé. C'est du semi-open source 🤣🤣🤣
Aujourd'hui, je boote la cpu AFM, et je regarder les comm sur le port $3FDC sans aucune carte son qui ne répond.
en allant dans le menu, nous avons ERROR SOUNDBOARD, normal
3:231
3:231
3:231
3:231
3:231
3:231
3:232
3:232
3:232
3:232
3:232
3:232
0:0
85:170
127:128
ALors, on va remettre à plus tard, l'analyse de la séquence de boot, et nous allons nous concentrer sur le pourquoi une tiltaudio ne fonctionne pas avec un AFM sans la carte son d'origine en paralèle de celle-çi.
j'ai donc fait un bricolage comme je les déteste bien, afin de lire le bus de données qui sort de la carte cpu et la réponse de la carte AV95 dans les 4 conditions suivantes
port DATA en ecriture $3FDC donnée venant de la cpu
port DATA en lecture $3FDC donnée venant de la carte AV95
port CTRL en ecriture $3FDD donnée venant de la cpu
port CTRL en lecture $3FDD donnée venant de la carte AV95
pendant la mise en test en mode séquenciel, la carte CPU va aller demander les sons suivant de 1 à 7
SON n°1
- ecriture de 2 octets 0:2 donc $0002 sur le port DATA $3FDC
- lecture du port CTRL $3FDD -> 2 possibilités la carte AV retourne $3F(pas de données à lire) ou $BF(Donnée disponible)
(je pense que sur une carte pre-dcs c'est différent, car je ne vois sur les schémas qu'un latch sur le Bit 7, à vérifier)
- en cas de donnée disponible, lecture de DATA $3FDC qui retoune un octel en fonction de la musique en cours dans le cas du son 1 -> $82
SON n°2 0:4 donc $0004 retour de la carte AV: $84
SON n°3 0:5 donc $0005 retour de la carte AV: $85
SON n°4 0:8 donc $0008 retour de la carte AV: $88
SON n°5 0:11 donc $000B retour de la carte AV: $8B
SON n°6 0:10 donc $000A retour de la carte AV: $8A
SON n°7 0:16 donc $0010 retour de la carte AV: $90
donc nous voyons un cohérence entre l'id du theme demandé et la réponse en 8bit, il semble que la réponse c'est le poid faible de l'ID +$80, une sorte de checksum en gros.
selon les log, la demande n'est faite que pendant les musique de theme et pas sur les effets sonores, car les sons sont probablement trop court.
Cette confirmation est faite périodiquement avec une periode assez courte, moins de 1 secondes. Je pense que cela sert a la cpu de savoir quand le morceau du theme sera fini, et qu'il pourra le remettre en route en relancer la demande du meme ID. Comme la tiltaudi ne fait pas cette réponse, la cpu pense que le morceau est terminé, alors il redemande a jouer le morceau.
Je comprendre donc pourquoi une tiltaudio ne relance pas le theme quand il sont terminé, j'avais remarqué cela sur le docteur who.
(https://gamoovernet.pixhotel.fr/pics_gamoovernet890px/v2/2023/08/01/20230801201117-Bio%20STEIN-IMG_6449.jpg) (https://gamoovernet.pixhotel.fr/pics/v2/2023/08/01/20230801201117-Bio%20STEIN-IMG_6449.jpg)
Bravo, tu connais maintenant la cause du problème.
Citation de: Bio STEIN le Lundi 31 Juillet 2023, 17:12:21 PMMais pourquoi donc sparkfun donnent-ils les sources eagle si le firmware ne fonctionne qu'avec les boards sparkfun sous licence ;D . On dirait tiltaudio, qui fait croire a de l'open source en donnant les schemas eagle pour piquer les clients pinsounds, mais c'est toujours aussi fermé. C'est du semi-open source 🤣🤣🤣
Tu peux très bien avoir des boards open-source avec un firmware qui ne l'est pas. Les licences open-source sont très différentes entre hardware et software. Par exemple, le hardware de la Wav Trigger est Attribution-ShareAlike 3.0 (https://creativecommons.org/licenses/by-sa/3.0/) selon Sparkfun, ce qui le rends diffusable et modifiable a volonté (même avec un usage commercial) si par exemple tu veux coder ton propre Wav Trigger. Par contre, la partie soft développée par Robertsonics est protégée et non open-source.
Rien ne dit (j'ai pas cherché), qu'il n'existe pas un firmware open-source pour aller avec ce hardware (et rien ne t'empêche de faire le tien non plus).
Ok,
Comment Sparkun gagne de la tune, si je peux prendre leur schéma et faire mes propres board ? quel est leur business model ?
Citation de: ɐɹqoƆ‾ɥƃᴉH le Mercredi 02 Août 2023, 04:51:29 AMTu peux très bien avoir des boards open-source avec un firmware qui ne l'est pas. Les licences open-source sont très différentes entre hardware et software. Par exemple, le hardware de la Wav Trigger est Attribution-ShareAlike 3.0 (https://creativecommons.org/licenses/by-sa/3.0/) selon Sparkfun, ce qui le rends diffusable et modifiable a volonté (même avec un usage commercial) si par exemple tu veux coder ton propre Wav Trigger. Par contre, la partie soft développée par Robertsonics est protégée et non open-source.
Rien ne dit (j'ai pas cherché), qu'il n'existe pas un firmware open-source pour aller avec ce hardware (et rien ne t'empêche de faire le tien non plus).
Voila, je termine mes investigations en analysant le processus de boot d'un AFM avec la carte AV95
sans la carte AV, la cpu envoie les infos suivantes sur le port $3FDC
$03-$E7 et cela 6 fois consécutives
$03-$E8 aussi 6 fois consécutives
$00-$00
$55-$AA
$7F-$80
lorsque nous branchons la carte le boot est différent
en premier, il faut rappeler que la cpu demande si il y a une donnée à lire sur le PORT$3FDC en consultant le PORT $3FDD et vérifie si la réponse est $3F (rien à lire) et $BF(donnée disponible)
donc au debut, la cpu va demander des dizaines de fois (je n'ai pas compté) si une donnée est dispo, et la plupart du temps la carte audio va répondre $3F, et puis à un moment, la réponse sera $BF, et donc lire les données suivantes qui seront présentées par la carte audio
la cpu reçois $00 - $79 - $01, j'ai aurais tendance à penser que c'est la version du soft dans la carte AV, qui est affiché en dessous de la version de rom des sons mais il est affiché sur le DMD 3.77 et une date en 1999, il faudra plus tard jouer avec la chaine envoyé par la carte pour vérifier cette théorie
à ce moment, la cpu va envoyer la séquence $03-$E7 et demande à nouveau une réponse qu'elle n'aura pas dans un premier temps et fera donc un retry en demandant à nouveau $03-$E7 et la carte carte AV va repondre $10 qui corespondrait au numéro de verson de la ROM 1.0. je considère donc que le code de commande $03E7 demande la version de rom des sons
ensuite la cpu envoie la commande $03-$E8, à quoi la carte av va répondre 00. je n'ai plus d'info qui me permette de déterminer à quoi correspond cette commande.
ensuite la CPU va envoyer la séquence $0 - $0 je ne sais pas à quoi cela correspond
ensuite $55-$AA-$7F-$80; qui correspond au volume à 15 qui est à parametrer au démarage de la carte AV, car elle n'a pas de sauvegarde hors alim. si j'augmente le volume avec les bouton (vol 16), je vois la séquence $55-$AA-$87-$78, donne l'incrément est bien plus que 1. à appronfondir l'encodage de la valeur du son.
voila.
Citation de: Bio STEIN le Mercredi 02 Août 2023, 09:20:46 AMOk,
Comment Sparkun gagne de la tune, si je peux prendre leur schéma et faire mes propres board ? quel est leur business model ?
Les 99.9% des gens qui n'ont pas les compétences/le temps/l'envie de refaire tirer et surtout monter des cartes que tu peux acheter toutes faites (avec les contrôles qualité et potentiellement la garantie qui va avec).
Le tout avec un délai de livraison relativement court...
De mémoire la commande $00-$00 arrête tous les sons et musiques en cours mais en plus il me semble remet le volume à zéro.
Ah oui, plutot logique.
T'as reussi a avnacer sur le st32 ? Moi je bloque grave, compliqué d'ide de ST....
Citation de: flip78 le Samedi 05 Août 2023, 16:33:54 PMDe mémoire la commande $00-$00 arrête tous les sons et musiques en cours mais en plus il me semble remet le volume à zéro.
Hello,
Comme promis, j'ai profité de mes vacances pour regarder ton post.
L'idée est très interessante.
Comme nous en avions brièvement parler, pour la gestion du son, il faut que tu utilises ALSA.
Un petit lien vers le Wiki ALSA, entre autre : https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture
Je vais suivre ton avancé.
A+
Ok, will, mais faudra attendre un peu.