TiltAudio95

[Bio STEIN]

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.

[flip78]

Excellent !

[Aganyte]

  

[Bio STEIN]

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.

[Bio STEIN]

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.

[Bio STEIN]

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 ?

[Bio STEIN]

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...

[Aganyte]

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).

[Bio STEIN]

https://youtu.be/-JO7b50fyts

[Bio STEIN]

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

[Aganyte]

Là pour le coup il n'y a que le créateur de la Tilt Audio qui pourrait te dépanner je pense.

[Bio STEIN]

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.

[Bio STEIN]

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é.

[Bio STEIN]

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.



 

[Bio STEIN]

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.

[Bio STEIN]

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.