[Thomson] SDDRIVE Vidéo

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel »

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.
Dernière modification par Daniel le 05 sept. 2018 11:42, modifié 1 fois.
Daniel
L'obstacle augmente mon ardeur.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel »

__sam__ a écrit : 05 sept. 2018 08:12 Du coup, pour me venger voici le fichier SD sans protection: >>ICI<<
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 :wink:

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)

##.png
##.png (1.56 Kio) Consulté 6117 fois
Dernière modification par Daniel le 05 sept. 2018 15:24, modifié 1 fois.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

Hmm... pas de commentaires.. pourtant l'exe marche super bien. Etrange :roll:

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. :)
Plus précisément le player affiche jusqu'à 4 octets video par trame de 3 octets lus en 199µs, cela nous fait donc 299ms pour l'ensemble de l'écran dans le pire des cas. C'est pas mal au dessus de la persistence rétinienne (qui va jusqu'à disons 100ms). En entrelaçant l'info, l'image est partiellement affichée en au plus 150ms. En pratique ce sera moins, et on sera plus proche de la persistence rétinienne qui nous ferra voir l'image partielle apparaitre instantanément. Avec un entrelacement bien choisi, cette demi-image se mêle avec la demi-image précédente et l'oeil a l'impression de voir une image complète apparaitre d'un coup. C'est cela qui produit les changements de plans "rapides" que Daniel a observé. En fait il n'y a pas d'accélération du player, mais uniquement une analyse fine de la façon dont la vision fonctionne. (L'art de la démo est de savoir tricher ;) )

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
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE Vidéo

Message par jasz »

__sam__ a écrit : 05 sept. 2018 14:17 Hmm... pas de commentaires.. pourtant l'exe marche super bien. Etrange :roll:
Euh si! Je confirme l'exe fonctionne très sous starter mais c'est une routine sddrive pas sdanim7. Je sais, j'insiste :roll:

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 :mrgreen: On ne comprend pas toujours tout des images. :?

PS: Ce n'est pas une critique :wink:
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

jasz a écrit : 05 sept. 2018 22:12 On ne comprend pas toujours tout des images. :?
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
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

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
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE Vidéo

Message par jasz »

Pour comparer ce qui est comparable je propose la vidéo officielle de SDANIM7 proposé par Daniel ;)
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

Ca tombe bien, elle a été convertie ce matin (lien)

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
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 :twisted: )
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
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

@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 :D
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
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel »

Effectivement __sam__, tu as raison, et je n'y avais même pas pensé :oops:

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.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

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
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel »

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.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

[EDIT] oops pas de PIA sur SDDrive.. désolé :oops:

Si j'essaye de lire le chemin de D0 sur le schéma
Image
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
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel »

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.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

Daniel a écrit : 07 sept. 2018 14:17 Dans l'électronique de SDDRIVE, b0 est connecté à MOSI de la carte SD à chaque écriture en <$BF
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))
Sur l'adresse on a $A7BF, donc A10,A9,A8 sont tous à TRUE (1), /Axxx est à FALSE et A11 à FALSE aussi (mais on s'en fiche), ce qui donne après calcul /CE = TRUE, et zut l'EPROM n'est pas active, les sorties sont flottantes. On ne doit donc lire que du bruit moralement :(. Ca aurait été bien de pouvoir lire la ROM à cette adresse. Dommage. :cry:
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
Répondre