TILTAUDIO95

[flip78]

Microcontrôleur avec plus d'I/O, oui possible mais faudra le souder en version cms.
Il ne faut pas perdre de vue que ce qui circule sur le bus d'adresse et données vers la carte vidéo est très rapide.
Il faut consituer une image "bitmap" en 4 niveaux de gris (ou orange si vous préférez), et serialiser le tout en direction du DOT.
Pour moi une chose est sure (C'est mon avis, et sans doute cela ne plaira pas a tout le monde), il faut "bypasser" tout cela et envoyer le tout sur du HUB75, adieu les écrans plasma (Et leur haute tension) et autres solution de remplacement à led ...
Après si on veut coloriser ... Ben les bonnes âmes sont les bienvenues pour bosser sur ce projet !

[Franckb78]

Le pcb fait partie intégrale d'un projet. En parler n'est pas une dérive.

J'ai envie de dire brut de fonderie que le STM n'est peut être pas le meilleur choix.

Il fait du décodage d'adresse et transfère vers le son (ADAUI401 ou NXP1334 pas très clair) probablement en utilisant un protocol standart .
Et pour DMD, idem avec peut être ton histoire HDMI HB75 pas encore claire.

Jusqu'a la c'est la description parfaite d'un petit FPGA, ou au lieu d'écrire du soft tu écris du hardware. Ca semble plus ardu a mettre en place mais pas tant que ça je pense.

La petite de chez lattice est dispo sous le nom "FPGA development board iCEBreaker".

Je prendrais plutôt ca comme base de départ plutôt que le STM32 pour construire tout le traitement du signal vers le DMD

Un STM pédale à combien, 16Mhz, 20 maybe. Le bus du WPC, allez 1MHz, ca te laisse pas beaucoup d'instructions en code machine pour faire un traitement compliqué.
Et si de temps en temps il loupe un ordre du WPC, ton oreille n'entendra pas le glitch

Souder n'est pas un problème tant qu'en évite les BGA.
Mettre en profusion de module est valable pour un proto.
Un carte arduino ne sert à rien, le ATMega en QFP suffit toujours seul et ce reprogramme sur place.

[Wpc Guru]

Pour moi une chose est sure (C'est mon avis, et sans doute cela ne plaira pas a tout le monde), il faut "bypasser" tout cela et envoyer le tout sur du HUB75, adieu les écrans plasma (Et leur haute tension) et autres solution de remplacement à led ...
Après si on veut coloriser ... Ben les bonnes âmes sont les bienvenues pour bosser sur ce projet !

Oui, c’est ce que je disais plus haut, plus de de plasme, juste de la ram vers hub75 et dans l’ideal HDMI en plus (ou autre plus simple) afin d’avoir deja le dmd au format numerique et eviter de mettre un trepied avec 3 cameras sur le coté (qui doit d’ailleurs etre assez génant pour le competiteur) avec seulement 2 camera au dessus du fronton au niveau de la cle de fronton et cette output dmd qui sera fusion dans un soft pour partir en streaming.

Si tu penses que le soft est jouable, je vais commencer a faire l’inventaire du bus I/o du wpc et voir comment on peut construire l’electronique et si on tombe d’accord sur un schema alors je ferai le pcb.

[Wpc Guru]

Le pcb fait partie intégrale d'un projet. En parler n'est pas une dérive.

J'ai envie de dire brut de fonderie que le STM n'est peut être pas le meilleur choix.

Il fait du décodage d'adresse et transfère vers le son (ADAUI401 ou NXP1334 pas très clair) probablement en utilisant un protocol standart .
Et pour DMD, idem avec peut être ton histoire HDMI HB75 pas encore claire.

Jusqu'a la c'est la description parfaite d'un petit FPGA, ou au lieu d'écrire du soft tu écris du hardware. Ca semble plus ardu a mettre en place mais pas tant que ça je pense.

La petite de chez lattice est dispo sous le nom "FPGA development board iCEBreaker".

Je prendrais plutôt ca comme base de départ plutôt que le STM32 pour construire tout le traitement du signal vers le DMD

Un STM pédale à combien, 16Mhz, 20 maybe. Le bus du WPC, allez 1MHz, ca te laisse pas beaucoup d'instructions en code machine pour faire un traitement compliqué.
Et si de temps en temps il loupe un ordre du WPC, ton oreille n'entendra pas le glitch

Souder n'est pas un problème tant qu'en évite les BGA.
Mettre en profusion de module est valable pour un proto.
Un carte arduino ne sert à rien, le ATMega en QFP suffit toujours seul et ce reprogramme sur place.

Donc, le HUB75 est le format utilisé par les dalles couleurs qui sont utilisés par le pin2dmd.

Le projet pin2dmd est un stm32 (j’ai pas en tete lequel) qui deserialise la trame plasma (donc le connecteur video qui va au display) et a l’origine le transfomait juste au format HUB75 (je ne sais pas si hub75 decrit le protocole, la connectique ou les 2). Le dmd plasma etant sur 4 niveaux de gris donc sur 2 bits dans la ram, la carte video dmd utilise la persistance retinienne pour simuler des niveau de gris sur le plasma qui n’existe pas. En gros 00 c’est noir, 01 c’est 2 fois eteint 1 fois allumé, 10, c’est 1 fois etient 1 fois allumé, et enfin 11 c’est 3 fois allumé. Un truc comme ca….

Ensuite, sur les version 2 de pin2dmd, il ont commencé par pourvoir remplacer les niveau de gris par une palette de 4 couleurs, et par la ensuite, il faisait une detection de séquence video a l’aide de detection de signature, qui peut simplement etre altéré par le changement de langue ou alors le point qui indique un defaut au demarrage sur les wpc. Grace a cette detection, il modifie la palette à la volée. Mais ca restait toujours 4 couleurs parmis un palette de 16. Ensuite, il ont ajouté des mask, le 64 couleurs avec replacement complet des graphisme d’origine. Bref, un truc bien beton qu’un stm32 fait à la volée sans brocher. C’est pour cela que j’ai assez peu de doute quand a la puissance du stm32 de faire cela, sachant que par rapport au projet pin2dmd, ma version serait de se plugger directement sur le bus I/0 du wpc pour sauver en ram du stm32 plutot que de deserialiser le connecteur video du plasma, en gros c’est kif kif.

Personnelement j’ai besoin d’apprendre a coder le stm32 car c’est un pros standart, j’ai integré le 328p directement sur mon projet de carte driver universelle, (pas d’arduino)

Mon gamin commence école d’inge électronique en septembre, et je fais pas mal d’electronique avec lui et j’ai besoin de bosser avec lui sur du projet concret, a l’ecole c’est malheureusement trop de theorie, et des projets souvent jamais comme un produit fini.

Tu me propose ton FPGA, c’est surement bien, mais je suis pas trop pret a passer a cela en ce moment je dois completer mon rattrapage sur les microcontroleur actuel, j’en suis resté au 68hc11 de 92 a 95 ou je développais en asm.

[Freeman98]

Pouah les gars, que c'est beau toute cette science en électronique ! bon perso chui largué, mais je suis le projet avec attention et c'est vraiment intéressant tout ça !

Bravo pour toutes ces initiatives Marc, tu gère !

Et Keep Cool les gars, n'oubliez pas qu'on a tous cette passion du quadrupède en commun ( l'électronique hardware et software en plus pour certains ! ) Et c'est avec l'expérience, la bienveillance et la passion de chacun que les projets avancent !

[Franckb78]

je met deux trois liens pour éventuellement plus tard si faire du HDMI,


https://hackaday.com/2019/07/26/hdmi-from-your-arduino/
https://github.com/techtoys/HDMI-Shield ... a8876_Lite
https://www.raio.com.tw/data_raio/Datas ... 11_Eng.pdf

ADAUI401
https://www.analog.com/en/products/adau1401.html
NXP1334
https://www.nxp.com/docs/en/data-sheet/UDA1334ATS.pdf


la carte tiltaudio version 3.0 ( 2020)
https://image.easyeda.com/histories/726 ... 549c44.png
qui se branche sur le connecteur J601 / J202(cpu)
Sur ce schéma il n'y a pas de 'blackpill' , le PI lit la donnée latchée dans le LS574 et agit.

la même en version 3.10 (2022)
https://image.easyeda.com/histories/024 ... 9133a6.png
'blackpill' remplace le LS139/LS574 et vu l'ajout SDA/SCL, pilote directement le DAC (ADAUI401+UDA1334)
Le PI devient optionnel (si j'ai bien lu)
J'ai récupéré une carte buspirate (jamais utilisée) qui devrait aider a reconstituer l'échange sur la ligne SDA/SCL

Clairement pas besoin de FPGA pour le son.


schéma WPC95
https://www.pinwiki.com/wiki/images/9/9 ... 0159.3.pdf
La carte a remplacer à partir de la page 8

Et à éclaircir qui dégage (U26 et les rom??) ou utilisation à partir de J603 pour la partie video.

[Wpc Guru]

Je ne comprends pas bien ou tu veux en venir

Car il y a 2 sujets dans ce thread

1* ma carte dont j’ai fait deja le pcb qui contient les schema originaux de la carte dot + tiltaudio a ma sauce sur laquel j’ai refait un partie du schema apres le PI.

Ou alors 2*

Repenser tout le truc et avoir blackpill (pour faire un proto) et apres st32 soudé sur circuit qui émule la carte video dot quo va transformer CPU I/o vers hub75 et qui en meme temps on essaie de faire la carte son sans le PI ?

[Wpc Guru]

J'ai réalisé un banc de test afin de pouvoir débugger mon premier proto de carte driver.

il y a 1 mois, je me suis équipé d'une station pour souder un peu plus pro de chez JBC, les pannes sont interchangeables en 1 seconde et cela descend à 0,1mm, un pur bonheur. cela passe de 0 degrée à 400° en quelque secondes, il se mets en mode hibernation automatiquement, bref fini les pannes détruites quand t'oublie le truc branché. je suis pro JBC à cause de l'école d'électronique qui imposait cette marque à l'époque et j'ai gardé des JBC tout le temps.

j'au vi qu'ils ont des station spécialisé pour le smd, notamment à air chaud (je pense souvent aux aventures de Franck Niro quand il me raconte ses aventures à réparer les Nodes de chez stern), mais ca coute pas mal et je voudrais etre sur de l'utiliser souvent avant de franchir le pas

j'ai aussi acheté recemment un oscillo plus leger que mon hameg ou mon tektronic, c'est sympa, mais j'avoue que j'ai un peu de mal, rien de vaut un vielle analogique, car tu mets assez peu en doute le sgnal que tu vois, a part la calibrage de la soude. Par contre, lors de mon 1er proto de driver, j'avais mis le RIGOL sur le 5V, j'appuie sur le bouton AUTO, et la je me retrouve avec un beau signal alternatif. je comprenais rien à l'oscillo, il venait d'arriver, je me dit c'est quoi ce truc de mer..... au final, l'oscillo avait raison, j'avais oublié le condo de filtrage 100uF sur la sortie 5V ca n'a pas pardonné.

enfin, j'ai acheté un analysant Salea (une copie je crois) que j'ai jamais mis en route ne ne sais pas comment ca fonctionne.

[Wpc Guru]

si dessous, j'ai fait une photos des schemas de la partie décodage d'adresse de la carte DOT(en haut) et de la carte son preDCS (en bas)
- nous avons en commun :

D0 à D7 (bidirectionnel pour la carte son et uni pour a carte dot)
A0 à A15 (unidirectionel) , carte son n'utilise que A0 à A4 afin de savoir quel registre est sélectionné, faudra décortiquer cela plus loin.
R/W (uni) pour les 2 cartes

- la carte SON :
WDEN et c'est son ce signal qui nous permet de savoir que le décodage concerne la carte son. Si quelqu'un pouvait ma donner la signification de WDEN, surement un data enable, mais le W.... ?
RST, utilisé uniquement sur la carte son.

- la carte DOT :
BLANK - equivalent du reset, mais je pense que la blank est plus tot un reset hardware et qu'il n'intervient pas sur des reset soft de watchdog.
I/O - c'est sur ce signal que la carte DOT sait que le bus s'adresse à elle.
WPC_E - c'est le E du 6809, je crois que c'est quand les données du bus sont stables, on peut y aller.
WPC_Q - la je sais pas trop, je crois que c'est lié à E, mais j'ai pas creusé, surement une preparation des données pour stabiliser toutes les portes du décodage d'adresse et sur le front montant de E on lit le bus, si quelqu'un peut me confirmer cela.

FIRQ (qui est le seul signal d'entrée des connecteurs I/O

[Wpc Guru]

ce dessus une partie du schéma du la carte CPU, au niveau du port I/O

on peut remarquer qu'il existe un signal IOEN qui est construit par l'asic, et qui va activer les buffers U1 U2 U3. c'est seulement à ce moment que les données seront stable sur le bus IO, et donc autant je suis sur que le signal E sera utilisable et aura lieu après que IOEN soit activé, autant j'en ai aucune idée sur Q qui vient du pros. si quelqu'un a deja regardé avec un oscillo est possede la reponse, ce serait cool.