Daniel a écrit :On peut tout imaginer, mais après, pour développer, il faut des dizaines ou des centaines d'heures de travail. L'arduino a un mode SPI "hard", utilisé pour communiquer avec la carte SD. Mais on peut faire aussi du SPI par soft, pour communiquer avec le Thomson. Après il faut faire communiquer les deux SPI, c'est sûrement possible, mais bon courage à qui s'y lancera
Ah oui je comprends. C'est un max de boulot. Je pensais, faute d'avoir lu les sketchs attentivement, que l'arduino pilotait la carte SD comme le module CD91-280 coté thomson. En fait non. Tu utilises des bibliothèques qui fournissent des accès "haut niveau" au dessus du SPI. Du coup la passerelle TO-SD n'est pas directe comme je l'imaginais naïvement.
Re: [Thomson] Vidéo avec son en streaming
Publié : 29 août 2015 15:03
par Fool-DupleX
Au niveau du hardware, on peut effectivement imaginer beaucoup de choses mais comme le dit Daniel, ca necessite du temps pour le developpement et la mise au point. Temps qui nous fait tous défaut, hélas.
Avec un hardware approprié et électroniquement beaucoup plus simple que l'Arduino, on pourrait monter avec un Thomson a beaucoup plus que 120 Ko/s en vitesse de transfert. ahem. vraiment beaucoup plus. Le 6809 n'est pas le point bloquant. C'est le PIA qui est aujourd'hui le frein.
Toutefois, on se heurte a une autre limite qui est celle du traitement des données ainsi chargées. Ultimement, la partie limitative c'est le décodeur vidéo.
Enfin, un petit mot concernant l'Arduino, dont chacun ici aura maintenant compris que je n'en pense que du mal : le micro-controleur qui équipe l'Arduino est capable d'atteindre sans souci et sans forcer 1 Mo/s sur son interface SPI. Donc vous me permettrez, je l'espere, de continuer à préférer d'autres concepts fondés sur le même micro-contrôleur, comme par exemple mon cher Teensy.
Re: [Thomson] Vidéo avec son en streaming
Publié : 29 août 2015 16:34
par Daniel
Tu as raison sur tous les points, mais mon raisonnement est également irréfutable :
- Un LDA direct prend 4 cycles. On ne peut pas dépasser 250 Ko/s, sans rien faire d'autre.
- On peut aller encore plus vite avec un LDD direct : 5 cycles pour deux octets, 400 Ko/s sans rien faire d'autre.
- Avec l'Arduino je sais lire la carte SD à 500 Ko/s. L'Arduino est suffisant et ne limite pas le débit.
J'ai choisi l'Arduino, car il est accessible à tous, même aux plus limités intellectuellement, ou manuellement, ou financièrement.
Les ressources disponibles sont infinies et compréhensibles, les montages faciles, l'Arduino Pro Mini chinois coûte aujourd'hui 1,39€.
Avec l'Arduino, nous faisons du streaming audio sur 6 bits et même sur 1 bit, du streaming vidéo en noir et blanc ou en couleurs. J'aurais pu, si j'avais voulu y consacrer deux ou trois jours, faire un simulateur de magnétophone Thomson. Il y a des applications qui tournent et que l'on peut montrer, même sur YouTube. Il ne reste plus qu'à relayer sur les réseaux sociaux, mais ça doit être déjà fait car beaucoup de visiteurs de la section Bricolage du site dcmoto viennent de Facebook. J'espère voir bientôt autant de développements sur Teensy.
Re: [Thomson] Vidéo avec son en streaming
Publié : 30 août 2015 00:44
par __sam__
En fait on peut théoriquement aller encore plus vite avec des techniques de codeur fou.
Imaginons qu'au lieu d'adresser un ou 2 octets, par PIA il existe un montage permettant de rendre accessible en mémoire un bout de 256 ou 512 (voire plus) octets d'un fichier SD. Si ce fichier, au lieu de contenir des données qu'un LDA <$XX ou LDD <$XX va lire, il contenait directement du code 6809: LDA #$XX et LDD #XXXXX, on irait encore vachement plus vite! C'est la technique qui a été utilisée sur PC dans 8088 Domination.
Mais pour le hardware c'est limite un truc de fou à la unix avec des fichiers mappés en RAM/ROM via un matériel ad-hoc!
Re: [Thomson] Vidéo avec son en streaming
Publié : 30 août 2015 11:19
par Fool-DupleX
Je ne suis pas un grand fan de la technique utilisée dans 8088 domination. C'est astucieux, mais c'est totalement rigide et lié à une application unique. Je suis intéressé par un système de transfert souple utilisable aussi pour charger des programmes standard.
Cela étant dit, il y a plusieurs approches pour le hardware. Mais dans aucun cas, il ne s'agit d'un truc de fou.
250 Ko/s et 400 Ko/s ne sont pas des vitesses réalistes avec l'approche LD. Car une fois LD un octet, il faut bien le ST quelque part. Considérons le code suivant, en faisant l'hypothèse bien sûr que les interruptions sont désactivées et que X est l'endroit en RAM ou l'on veut charger nos données, par exemple un secteur de 512 octets :
Total : 13 cycles pour deux octets, soit environ 154 Ko/s. Vous noterez que cela suppose déjà l'abandon du PIA pour un contrôleur qui propose un registre en lecture sur 16 bits avec auto-incrémentation à chaque accès en lecture. Mais ca, c'est trivial à faire.
Pourtant, les vitesses mentionnées par Daniel ne sont pas inatteignables pour un transfert en RAM. Mais il faut être un peu créatif. Voici une autre proposition :
Total : 11 cycles pour deux octets, soit environ 181 Ko/s. Ce code demande toutefois une contrainte forte au niveau du hardware. Celui-ci doit fournir une ROM contenant le code et à chaque adresse qui comporterait le #$0000, il devrait présenter la donnée à la place. Ce n'est en réalité pas beaucoup plus difficile à faire que le premier contrôleur, car il suffit d'ajuster le décodeur d'adresse interne au contrôleur en conséquence.
Las ! Le gain d'environ 30 Ko/s est tout de même bien faible au prix d'une certaine complexité. Il serait intéressant de trouver quelque chose de mieux. Décrétons cependant que la complexité du hardware n'est pas tant un problème et tâchons d'être créatif sur le plan du software. Les paris sont ouverts, je prends le pari et souvenez-vous :
[...] les vitesses mentionnées par Daniel (250 et 400 Ko/s) ne sont pas inatteignables pour un transfert en RAM. [...]
PS. Notez également que si quelqu'un trouve une solution à 400 Ko/s, ce sera vidéo non compressée 25 fps plein écran pleine couleur à gogo
Re: [Thomson] Vidéo avec son en streaming
Publié : 30 août 2015 11:41
par __sam__
Fool-DupleX a écrit :PS. Notez également que si quelqu'un trouve une solution à 400 Ko/s, ce sera vidéo non compressée 25 fps plein écran pleine couleur à gogo
Si on oublie les problèmes techniques et qu'on a un contrôleur hard capable de fournir 8 octets qui se mettent à jour automatiquement, le code suivant
LDU #$XXXX adresse de la zone mémoire "magique" du controlleur
PULU D,X,Y,S
PSHS D,X,Y
lit 8 octets (dont 6 utiles: S récupère l'adresse mémoire où placer ces valeurs) en (5+8) cycles, et en écrit 6 en (5+6) cycles. Si je compte 3 cycles pour le LDU on aura écrit en mémoire 6 octets en 27cycles, soit 222ko/sec = 27 fois 8ko/sec.
Ca ne fait pas une grosse différence avec les autres solutions. Dans tous les cas avec 27 fois 8ko/sec on aurait du temps réel sans compression, mais grâce à l'encodage des adresses dans les données, la compression est aussi possible puisqu'on peut faire des sauts.
Re: [Thomson] Vidéo avec son en streaming
Publié : 30 août 2015 15:18
par Fool-DupleX
Bien joué Sam.
Grâce à ta solution, on passe quand même de 154 à 222 Ko/s et en se payant le luxe de placer les données un peu partout en RAM. Il y a un petit peu de gaspillage car on doit obligatoirement utiliser des blocs de 6, même si les octets restent inchangés (dans le cas d'une vidéo) mais tout de même, le gain est intéressant, surtout dans l'approche compression. Pas de problème pour implémenter ce contrôleur en hard.
512 n'est pas divisible par 6, c'est un petit peu embêtant pour le passage de secteur, mais pas si grave. Et l'usage des mouvements de pile est effectivement un des secrets pour débloquer la *puissance* de nos Thomson.
Allez, essayons de smasher la première barrière de 250 Ko/s fixée par Daniel. On y est presque pour celle-la.
Re: [Thomson] Vidéo avec son en streaming
Publié : 30 août 2015 17:25
par __sam__
Si on ajoute DP dans la liste, on transfert 7 octets en 29cycles soit 241ko/sec. C'est pas loin mais pas assez.
On peut aussi ne pas utiliser la donnée de S comme une adresse:
LDU #$XXXX * zone mémoire magique
PULU DP,D,X,Y,S
LDU #$YYYY * adresse destination modifiée par code auto-modifiable
PSHSU DP,X,Y,S
ce qui nous fait 9 octets en (3+5+9)*2=34 cycles, soit un peu au dessus de 264ko/sec. Bingo!
Bon ok, comme il faut modifier le $YYYY à coté, ca fait moins. Ouais
...Sauf à dérouler le code en mémoire en pré-calculant les $YYYY. Comme le code fait 10 octets pour 9 octets copiés, pour recopier 8001 octets de la RAM video (bon ca déborde de 1, mais c'est divisible par neuf), il faut une zone de code de 8890 octets. Ca se trouve.
Ca n'est pas une solution très élégante car c'est de la force brute, mais ca pourrait marcher si on a l’électronique "qui va bien".
Re: [Thomson] Vidéo avec son en streaming
Publié : 30 août 2015 23:41
par Fool-DupleX
S'il ne s'agit que de dérouler par exemple les 8 Ko entiers d'un coup dans la page video, tu peux te contenter de ne fixer S qu'une seule fois au début et de l'utiliser.
LDS #$YYYY Adresse de destination
Répète X fois:
LDU #$XXXX 3
PULU DP,D,X,Y 12
PSHS Y,X,D,DP 12
[Epilogue: octets restants, parce que 7 c'est pas terrible pour les divisions]
Total : 27 cycles pour 7 octets, soit environ 259 Ko/s pour un code simple, relativement compact et ne necessitant que d'exposer les données sur une zone contigue de 7 adresses cote controleur. On notera par contre que les données sont chargées de bas en haut. Mais je suis bon prince, je reconnais que c'est un peu moins rapide que ta solution.
Bien, cette premiere barrière de 250 Ko/s a été franchie aisément semble-t-il !
Allons-y en tout de même en douceur et posons-nous maintenant la question si on peut passer 300 Ko/s.
Re: [Thomson] Vidéo avec son en streaming
Publié : 31 août 2015 08:43
par Daniel
Rêver c'est bien. Faire tourner une démo sur les vraies machines serait beaucoup plus convaincant pour les néophytes
Re: [Thomson] Vidéo avec son en streaming
Publié : 31 août 2015 10:32
par Fool-DupleX
Aaah, je reconnais bien là le dynamisme et la fougue du jeune fou impatient qu'est Daniel !
Devant tant de pression, je me vois donc contraint et forcé de poster ceci :
Mais je dois malheureusement dans la foulée tempérer les ardeurs : pour le moment, ce proto ne fonctionne pas. Si quelqu'un par ici maitrise l'assembleur Atmel et aurait du temps à consacrer au développement du firmware, je suis preneur, car il m'a fallu deux mois pour arriver à ce premier résultat et je n'arrive absolument pas à dégager du temps pour ca.
Comme souvent avec moi, les protos restent protos et se contentent de marchotter. Le seul produit final que j'ai réalisé est le ROMDisk NG.
Re: [Thomson] Vidéo avec son en streaming
Publié : 31 août 2015 20:41
par Daniel
Pour revenir à SDANIM7, la prochaine version aura les améliorations suivantes :
- Choix du fichier .sd dans le répertoire de la carte SD
- Suppression du programme Basic de lancement (tout est en langage machine)
- Démarrage beaucoup plus rapide de la vidéo (plus de DATA à lire, ni d'initialisation d'écran en Basic))
- Choix du mode couleur ou du mode noir et blanc
Je viens de finir les tests ce soir. Finalement ce n'était pas si facile avec les codes couleur en mémoire vidéo différents pour MO et TO, et la transmission sur un seul bit dans le sens Thomson vers Arduino. J'ai du jouer sur les temporisations pour envoyer des commandes différentes : un créneau court a une signification, un créneau long en a une autre. Finalement ça marche sur MO, sur TO et dans dcmoto (sauf que dans dcmoto on ne lit pas le répertoire, on se contente de jouer le fichier chargé, comme avant).
Reste à mettre les programmes au propre pour les publier, probablement dans le courant de la semaine.