[Thomson] SDDRIVE Vidéo
Modérateurs : Papy.G, fneck, Carl
Re: [Thomson] SDDRIVE Vidéo
Carl a eu un avertissement avec mes démonstrations de streaming sur carte SD (Stan Getz). Les robots de Google sont très performants pour reconnaître la musique, surtout quand la qualité est bonne. Je ne retrouve plus cette vidéo sur youtube, par contre il en reste d'autres (Kraftwerk, Tangerine Dream, Années 80). Dans le cas de SDDRIVE Vidéo, Google reconnaît peut-être aussi l'image, pourtant ça paraît difficile avec une si faible définition.
C'est pourquoi la vidéo officielle de SDANIM7 est un film libre de droits.
@__sam__ : Je me suis renseigné : en prison on n'a pas le droit au téléphone portable, par contre on peut avoir un MO5 (sur piles). Nous serons tranquilles pour développer, sans souci de faire les courses, le ménage et les repas, sans famille autour pour nous distraire. Et Kylie Minogue viendra peut-être nous rendre visite pour nous réconforter. Les ayants droit sont quand même un peu pénibles, on leur fait plus de pub que de mal. Malheureusement ils ont la loi pour eux.
C'est pourquoi la vidéo officielle de SDANIM7 est un film libre de droits.
@__sam__ : Je me suis renseigné : en prison on n'a pas le droit au téléphone portable, par contre on peut avoir un MO5 (sur piles). Nous serons tranquilles pour développer, sans souci de faire les courses, le ménage et les repas, sans famille autour pour nous distraire. Et Kylie Minogue viendra peut-être nous rendre visite pour nous réconforter. Les ayants droit sont quand même un peu pénibles, on leur fait plus de pub que de mal. Malheureusement ils ont la loi pour eux.
Dernière modification par Daniel le 05 sept. 2018 11:42, modifié 1 fois.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [Thomson] SDDRIVE Vidéo
Faute de le voir dans Youtube les amateurs vont vouloir un contrôleur SDDRIVE. Il faut que je relance une fabrication de circuits imprimés
Comme je l'ai déjà écrit plus haut, la couleur apporte beaucoup par rapport au noir et blanc. La qualité du son est toujours excellente, mais ce qui me surprend le plus est la vitesse des changements de plan. Avec mon algorithme initial c'était impossible, les améliorations apportées par __sam__ sont incroyables.
Exécutable Windows : sddrive_spinning-around_win.zip (disponible 30 jours)
Dernière modification par Daniel le 05 sept. 2018 15:24, modifié 1 fois.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
Hmm... pas de commentaires.. pourtant l'exe marche super bien. Etrange
J'ai quelques idées non pas pour améliorer le débit mais pour améliorer les changements de plans. Si on est attentif à l'exe on remarque que j'utilise un mode de rendu "entrelacé", c'est à dire que par image j'affiche d'abord les lignes paires, puis les impaires. Cela a deux effets:
Cette technique marche pas mal quand on regarde une vidéo la 1ère fois, mais une fois habitué et en se concentrant bien, on remarque l'entrelacement ce qui impacte la qualité de l'experience visuelle. Aussi j'ai d'autres idées en tête à tester pour voir si on peut adapter le balayage de l'image pour encore mieux "gruger" le cerveau. Bref, tout n'est pas encore fini avec la vidéo SDDRIVE... affaire à suivre.
J'ai quelques idées non pas pour améliorer le débit mais pour améliorer les changements de plans. Si on est attentif à l'exe on remarque que j'utilise un mode de rendu "entrelacé", c'est à dire que par image j'affiche d'abord les lignes paires, puis les impaires. Cela a deux effets:
- on a un "floutage" des images ce qui adoucit les transitions, et
- la surface de l'écran est partiellement comblé très rapidement. L'oeil préfère cela que de voir un délais entre le haut et le bas de l'image. L'experience visuelle est meilleure.
Cette technique marche pas mal quand on regarde une vidéo la 1ère fois, mais une fois habitué et en se concentrant bien, on remarque l'entrelacement ce qui impacte la qualité de l'experience visuelle. Aussi j'ai d'autres idées en tête à tester pour voir si on peut adapter le balayage de l'image pour encore mieux "gruger" le cerveau. Bref, tout n'est pas encore fini avec la vidéo SDDRIVE... affaire à suivre.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] SDDRIVE Vidéo
Euh si! Je confirme l'exe fonctionne très sous starter mais c'est une routine sddrive pas sdanim7. Je sais, j'insiste
En un mot simple: impressionnant! La qualité du son est très bonne et la fluidité du clip est sans contexte excellente. Mais... Ben oui il y a toujours un mais On ne comprend pas toujours tout des images.
PS: Ce n'est pas une critique
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
Dans le clip d'origine aussi, mais là on travaille à 80x50 (64 couls) maxi, ce qui ne fait pas beaucoup de pixels pour reconnaitre quelque chose dans l'image parfois. Avec un clip moins fouillé en détails et plus calme ca doit être plus simple à regarder. Par exemple, celui-ci, à regarder plutôt éloigné de l'écran ou sur émulateur avec le zoom à 50%.
A noter: en N&B ca marche très bien aussi : >>ici<<
Le convertisseur est à présent capable de détecter si la vidéo est monochrome ou en couleur et choisit le mode de rendu correspondant automatiquement.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
Quelqu'un aurait-il des souhaits de vidéo à tester ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] SDDRIVE Vidéo
Pour comparer ce qui est comparable je propose la vidéo officielle de SDANIM7 proposé par Daniel
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
Ca tombe bien, elle a été convertie ce matin (lien)
On a une vidéo plein-écran s'affichant en 100ms pour 85.7% des images. Je trouve le rendu moins bon au niveau de la définition par rapport à sdanim7 qui stream à plus de 120ko/sec contre 15ko/sec avec cette version du player pour SDDrive. En gros on a 10x moins de bande passante sans Arduino vu que l'on stream bit à bit au lieu d'octet par octet. La résolution s'en ressent: 80x50=4000 pixels d'un coté contre 320x66=21120 de l'autre. M'enfin, vu de loin comme dans la 2ème partie de la vidéo, ca fait son effet sur un thomson je trouve.
(désolé pour la qualité vidéo.. Mon téléphone n'aime pas l'écran cathodique, et je suis un piètre réalisateur )
Code : Tout sélectionner
../call_on_me/spinning_a_mountain.mp4
> 80x45 i (16:9) 0h 1m 39s at 10 fps (100% zoom)
> 100% 0:01:39 (1.9x) e=0.857 a=(x-13)*1
(désolé pour la qualité vidéo.. Mon téléphone n'aime pas l'écran cathodique, et je suis un piètre réalisateur )
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
@Daniel: j'ai une question technique.
De ce que je comprends le prochain bit est donné sur présentation de la bonne adresse du bus d'adresse. Pour "sauter" par dessus des bits sans les lire on fait un "CMP <$BF" qui coute 4 cycles.
L'instruction CLR <memoire> a la particularité de présenter deux fois l'adesse en question sur le bus (1 au début en lecture, et 1 en fin en écriture). Du coup est-ce que "CLR <$BF" saute au dessus de 2 bits ? Si oui c'est intéressant car on saute par dessus 2 bits en 6 cycles au lieu de 8. Ca fait gagner 8 cycles quand on saute au dessus d'un octet, de quoi accélérer la lecture des données de comblement pour la 2e moitié des secteurs
De ce que je comprends le prochain bit est donné sur présentation de la bonne adresse du bus d'adresse. Pour "sauter" par dessus des bits sans les lire on fait un "CMP <$BF" qui coute 4 cycles.
L'instruction CLR <memoire> a la particularité de présenter deux fois l'adesse en question sur le bus (1 au début en lecture, et 1 en fin en écriture). Du coup est-ce que "CLR <$BF" saute au dessus de 2 bits ? Si oui c'est intéressant car on saute par dessus 2 bits en 6 cycles au lieu de 8. Ca fait gagner 8 cycles quand on saute au dessus d'un octet, de quoi accélérer la lecture des données de comblement pour la 2e moitié des secteurs
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] SDDRIVE Vidéo
Effectivement __sam__, tu as raison, et je n'y avais même pas pensé
Je vais essayer cette technique immédiatement.
SDDRIVE Vidéo sera peu impacté (uniquement pour la lecture des deux octets de CRC), car dans le fichier .sd les secteurs sont pleins (512 octets).
Par contre en émulation de disquette la lecture des 256 octets inutiles de chaque secteur (plus les deux CRC) sera nettement plus rapide.
Dans dcmoto il faudra faire une petite modification pour que l'émulation de l'instruction CLR effectue aussi les deux accès, comme le 6809.
Dès que possible je donnerai le résultat des tests.
[Edit 9:30]
C'était bien imaginé, malheureusement ça ne marche pas.
L'instruction CLR envoie sur la ligne MOSI (écriture vers la carte SD) un signal à zéro. Or, pendant la lecture sur la ligne MISO (lecture de la carte SD), la ligne MOSI doit impérativement rester à 1, sinon c'est considéré comme le premier bit d'une nouvelle commande. Si le 6809 avait une instruction SET pour mettre tous les bits à 1 ça marcherait.
Ca me donne une nouvelle idée qu'il faudrait creuser : plutôt que de lire les 256 octets inutiles, il est peut-être possible de faire avorter la commande CMD17, précisément en écrivant un bit à zéro au lieu de continuer à lire. Je vais me replonger dans les spécifications des cartes SD...
Je vais essayer cette technique immédiatement.
SDDRIVE Vidéo sera peu impacté (uniquement pour la lecture des deux octets de CRC), car dans le fichier .sd les secteurs sont pleins (512 octets).
Par contre en émulation de disquette la lecture des 256 octets inutiles de chaque secteur (plus les deux CRC) sera nettement plus rapide.
Dans dcmoto il faudra faire une petite modification pour que l'émulation de l'instruction CLR effectue aussi les deux accès, comme le 6809.
Dès que possible je donnerai le résultat des tests.
[Edit 9:30]
C'était bien imaginé, malheureusement ça ne marche pas.
L'instruction CLR envoie sur la ligne MOSI (écriture vers la carte SD) un signal à zéro. Or, pendant la lecture sur la ligne MISO (lecture de la carte SD), la ligne MOSI doit impérativement rester à 1, sinon c'est considéré comme le premier bit d'une nouvelle commande. Si le 6809 avait une instruction SET pour mettre tous les bits à 1 ça marcherait.
Ca me donne une nouvelle idée qu'il faudrait creuser : plutôt que de lire les 256 octets inutiles, il est peut-être possible de faire avorter la commande CMD17, précisément en écrivant un bit à zéro au lieu de continuer à lire. Je vais me replonger dans les spécifications des cartes SD...
Dernière modification par Daniel le 07 sept. 2018 15:44, modifié 1 fois.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
Hmm je me doutais d'un truc comme ca, mais j'ai peut-être une parade: faire "INC <$BF" au lieu de CLR. Avec un peu de chance (en gros si un bit entre b0 et b6 est à 0) la carry ne viendra pas perturber b7 qui est mappé sur MOSI je crois. Auquel cas le bit MOSI garde (peut-être) sa valeur antérieure à 1. On peut aussi imaginer un ROL si le b6 est forcément à 1 au moment de la lecture.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] SDDRIVE Vidéo
En fait le bit MOSI est le bit 0 de <$BF et le bit MISO est le bit 7.
Avec le contrôleur SDDRIVE connecté :
- Sur MO5, un PRINT PEEK(&HA7BF) donne 142, soit $8E.
- Sur TO8D, un PRINT PEEK(&HE7BF) donne 254, soit $FE.
Le INC fait passer le bit 0 à 1, donc ça devrait marcher.
J'ai fait l'essai. Ca marche bien sur TO8D et pas sur MO5. Je ne comprends pas encore pourquoi, car dans dcmoto le résultat est bon dans les deux cas. Encore un mystère à élucider, mais on approche de la bonne solution.
Explication probable : La lecture de <$BF en BASIC donne toujours le même résultat, mais dans le programme du contrôleur SDDRIVE c'est probablement une autre valeur qui dépend du contexte. En changeant un peu ce contexte on peut peut-être garantir b0 = 0, et alors ça devrait marcher.
Avec le contrôleur SDDRIVE connecté :
- Sur MO5, un PRINT PEEK(&HA7BF) donne 142, soit $8E.
- Sur TO8D, un PRINT PEEK(&HE7BF) donne 254, soit $FE.
Le INC fait passer le bit 0 à 1, donc ça devrait marcher.
J'ai fait l'essai. Ca marche bien sur TO8D et pas sur MO5. Je ne comprends pas encore pourquoi, car dans dcmoto le résultat est bon dans les deux cas. Encore un mystère à élucider, mais on approche de la bonne solution.
Explication probable : La lecture de <$BF en BASIC donne toujours le même résultat, mais dans le programme du contrôleur SDDRIVE c'est probablement une autre valeur qui dépend du contexte. En changeant un peu ce contexte on peut peut-être garantir b0 = 0, et alors ça devrait marcher.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
[EDIT] oops pas de PIA sur SDDrive.. désolé
Si j'essaye de lire le chemin de D0 sur le schéma
je vois qu'on tombe soit sur le CS du module catalex via un buffer à haute impédance U6.2 (donc qui ne sert que lors des écritures je suppose), soit sur le D0 de l'EPROM U1. J'imagine donc qu'on lit le b0 d'un certain octet de la ROM disk (adresse $7BF) en <$BF. Il est étrange qu'on ne trouve pas la même valeur constante du coup entre ton test en basic et la valeur dans SDDrive. Je ne vois pas quel contexte ferait changer le fonctionnement du schéma.
Hmm.. si je teste "PRINT HEX$(PEEK(&HEBF))" en basic sous DCMoto j'ai $80 et pas $FE qui est retourné pour le TO8 et $0 et pas 142 pour le MO5. Je ne comprends pas. Peut-être que je me trompe dans l'analyse ci-dessus, d'autant-plus que l'outil de mise au point m'affiche un joli $20 dans les 2 cas. L'émulation n'est peut-être pas la bonne référence.
Si j'essaye de lire le chemin de D0 sur le schéma
je vois qu'on tombe soit sur le CS du module catalex via un buffer à haute impédance U6.2 (donc qui ne sert que lors des écritures je suppose), soit sur le D0 de l'EPROM U1. J'imagine donc qu'on lit le b0 d'un certain octet de la ROM disk (adresse $7BF) en <$BF. Il est étrange qu'on ne trouve pas la même valeur constante du coup entre ton test en basic et la valeur dans SDDrive. Je ne vois pas quel contexte ferait changer le fonctionnement du schéma.
Hmm.. si je teste "PRINT HEX$(PEEK(&HEBF))" en basic sous DCMoto j'ai $80 et pas $FE qui est retourné pour le TO8 et $0 et pas 142 pour le MO5. Je ne comprends pas. Peut-être que je me trompe dans l'analyse ci-dessus, d'autant-plus que l'outil de mise au point m'affiche un joli $20 dans les 2 cas. L'émulation n'est peut-être pas la bonne référence.
Dernière modification par __sam__ le 07 sept. 2018 14:41, modifié 3 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] SDDRIVE Vidéo
Effectivement <$BF n'est pas un PIA, c'est une adresse où il n'y a rien. Sur TO le contrôleur SDDRIVE s'arrête en $E6FF et les vecteurs d'entrée/sortie commencent en $E7C0.
Dans l'électronique de SDDRIVE, b0 est connecté à MOSI de la carte SD à chaque écriture en <$BF, b7 est connecté à MISO à chaque lecture.
En absence d'écriture en <$BF, b0 est flottant. En l'absence de lecture en <$BF, b7 est flottant.
Tous les autres bits sont toujours flottants (état haute impédance).
Quand un bit est en haute impédance la lecture donne théoriquement un résultat indéterminé. En fait il ne l'est pas vraiment puisque sur TO8 ça marche (le bit doit être lu à 0) et sur MO5 ça ne marche pas (le bit doit être lu à 1). Le phénomène est difficile à analyser et la cause n'est pas évidente. L'émulateur ne peut pas apporter d'aide pour un problème purement électronique.
Dans l'électronique de SDDRIVE, b0 est connecté à MOSI de la carte SD à chaque écriture en <$BF, b7 est connecté à MISO à chaque lecture.
En absence d'écriture en <$BF, b0 est flottant. En l'absence de lecture en <$BF, b7 est flottant.
Tous les autres bits sont toujours flottants (état haute impédance).
Quand un bit est en haute impédance la lecture donne théoriquement un résultat indéterminé. En fait il ne l'est pas vraiment puisque sur TO8 ça marche (le bit doit être lu à 0) et sur MO5 ça ne marche pas (le bit doit être lu à 1). Le phénomène est difficile à analyser et la cause n'est pas évidente. L'émulateur ne peut pas apporter d'aide pour un problème purement électronique.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7987
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] SDDRIVE Vidéo
Oui via le BUFFER U6.2, mais du coté de l'EPROM si elle est active elle fournit donc des valeurs D0 à D6. Si je décode le schéma comme suit:
Code : Tout sélectionner
/CE = NOT(NOT(A10 and A9 and A8) and NOT(/Axxx) and NOT(A11))
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos