[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

jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE Vidéo

Message par jasz »

C'est impressionnant de voir ce qu'il faut maitriser pour une simple petite animation sonore :shock:
__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 : 13 août 2018 08:35 Mais il me semble que l'octet $FF est toujours envoyé avant $FE, même pour les cartes ultra-rapides lues très lentement.
Donc en fin de bloc de 512 octets on doit s'attendre à 4 octets: CRC1, CRC2, $FF (signifiant carte en train de chercher le bloc suivant), $FE (signifiant données du bloc suivant prêtes à être lues).

Il nous faut donc 4 échantillons audio intercalaires.

Dans le découpage actuel que j'ai en tête, il y a une trame de 3 octets encodant: 1 échantillon audio 6 bits, et 4 octets vidéos ou-exclusif une position absolue dans l'écran + un octet video (plus d'infos sur les avantages de cet encodage plus tard).

Un bloc de 512 contient donc 170 trames + 2 octets. De ces 2 octets finaux je dois tirer 4 échantillons audio intercalaires. Je serais bien tenté de perdre 2 bits par échantillon intercalaire et dire qu'on a 4 + 4 + 4 + 4 = 2 octets finaux. on perds un peu en qualité pour ces 4 derniers échantillons, à voir si c'est supportable.

Est-ce que le $FF est vraiment toujours là? S'il était absent et qu'on tombe sur $FE juste après la lecture du CRC, je pourrais découper les 16 bits finaux en 6 + 5 + 5 c'est à dire qu'on ne perdrait qu'un seul bit sur les deux derniers échantillons audio. Ca passerait inaperçu à coup sur.

[EDIT] héhé, j'ai trouvé un truc pour avoir le 6+5+5 tout en ayant les 4 octets à lire. Miam, j'ai hâte de pouvoir mettre ça en pratique.
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, comme je l'ai écrit plus haut, je ne suis sûr de rien pour le nombre d'octets $FF. J'ai la vague intuition que c'est presque toujours un et un seul, mais rien ne le prouve. Il faudrait avoir le courage (et le temps) de faire un test sérieux avec plusieurs cartes et des débits différents.

L'autre solution, nettement plus empirique, est de faire l'hypothèse de quatre octets inter-blocs et d'écouter si on entend des craquements. J'ai aussi l'intuition qu'un octet de plus ou de moins sera indétectable à l'oreille. On entend un craquement s'il y a une grosse différence entre deux échantillons successifs, mais si on rate un échantillon ou si on joue deux fois le même on ne le remarque pas.

[Edit]
Une info pouvant être utile pour une démo : Les blocs de 512 octets de la carte sont lus bit par bit. Il n'y a aucun avantage (ni désavantage d'ailleurs) à les grouper par octet. On peut très bien les lire par groupes de 6 bits, ou même par groupes de longueur variable. L'alignement sur des frontières d'octets n'apporte rien.

Et une autre constation : SDDRIVE peut lire 20000 octets par seconde. C'est très loin des 116667 octets par seconde de SDANIM7 et il sera impossible d'obtenir la même fluidité, sauf si on choisit un type d'image qui s'y prête bien. Avec Simon's cat c'est presque parfait, avec une vidéo en couleur c'est beaucoup plus difficile.
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 : 12 août 2018 22:07 Pour aller plus vite il faut pouvoir lire les octets en une fois.
Eh eh ! C'est mon nouveau projet pour remplacer SDDRIVE. Mais chut, c'est encore ultra secret, ne le répétez pas : il s'appelle ARDDRIVE.
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 : 15 août 2018 09:01 SDDRIVE peut lire 20000 octets par seconde. C'est très loin des 116667 octets par seconde de SDANIM7 et il sera impossible d'obtenir la même fluidité, sauf si on choisit un type d'image qui s'y prête bien. Avec Simon's cat c'est presque parfait, avec une vidéo en couleur c'est beaucoup plus difficile.
C'est là que le mode video 80x50x64 couls vaguement évoqué ici prends tout son sens.
Image
A l'heure actuelle j'arrive avec l'ébauche de mon player à streamer de l'audio à 5khz avec de la video au rythme de 8 pixels en 600µs. Cela permet dans le pire des cas de changer l'intégralité de l'écran en 300ms à partir de SDDrive, c'est à dire sans Arduino ce qui rend ce player utilisable par plus de monde. Le rendu gfx n'est pas top (4000 pixels en tout et pour tout), mais c'est pas mal quand même (cf gif ci-dessus.)
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
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par 6502man »

Pas mal le player couleurs et sons :D
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ »

@Daniel, dans SDDrive, j'ai vu que le player est logé en $9900. Je comprends que cette adresse existe sur MO comme sur TO7/70 et au delà. Mais sur le TO7 sans extension il n'y a rien là bas il me semble. Du coup le player n'ira pas sur le TO7 "de base".

Y a t'il une raison à ne pas choisir l'implantation en $6300 qui existe tant sur MO que TO "de base" ? Certes cela interfère avec la page zéro du basic TO, mais comme SDDrive vidéo est autoboot ca n'est pas gênant.
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 »

Le choix d'une adresse commune aux TO et MO est simplement de la paresse, pour éviter d'écrire un programme translatable (ou deux versions du même programme). De toutes façons l'émulation de disquette avec SDDRIVE ne fonctionne pas sur le TO7 sans extension mémoire (les lecteurs de disquettes Thomson non plus), car il n'y a pas assez de mémoire de base pour charger le DOS.

Par contre les démos comme SDDRIVE Vidéo et SDDRIVE Music n'utilisant pas le DOS ni le Basic, il est possible de les charger en $6300, et même à une adresse encore plus basse. Mais ce n'est pas suffisant, car il faut penser aussi au programme SDDRIVE.SEL permettant de choisir le fichier .sd à charger. Il utilise des tables en RAM pour stocker le répertoire de la carte SD et il lui faut au minimum 8 Ko pour fonctionner correctement. Il n'y a donc pas de solution pour le TO7 sans extension mémoire, à moins de faire une version spéciale de SDDRIVE.SEL limitant à deux ou trois le nombre de fichiers .sd sur une carte.

La bonne question serait de savoir s'il y a encore beaucoup d'utilisateurs n'ayant qu'un TO7 de base. Ils ne doivent pas être nombreux. Et en plus le TO7 limite la palette à 8 couleurs, c'est une contrainte supplémentaire pour les démos.
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__ »

Bon ca avance pas mal de mon coté. J'ai un truc qui "marchote" a peu près comme je le veux sous émulateur. J'ai cependant un truc curieux que je ne pige pas: quand le player reboucle il fait bien un saut en $A028/$E028 pour stopper le stream (CMD12) et reboucle ensuite la routine pour repartir de zero tout comme le fait sddrive_video.asm. Sauf qu'au 2e passage en $A028/$E028 pour la CMD18 la carry est retournée à 1 et je n'obtiens plus jamais le $FE de début de bloc: l'émulation SD ne retourne plus que des $FF. De ce que j'ai pu tracer, cela vient du fait que les 256 dernières valeurs lues sur le bit SPI sont restés à 1 alors qu'on attendais un 0 à un moment.

Qu'est ce que je fais mal? Y a t'il une subtilité autour des appels en $A028/$E028 que je ne respecte pas style lancer les CMD12 et 18 uniquement après une fin de bloc ?

(Pour tester: https://www.cjoint.com/doc/18_08/HHuvJc ... Around.zip)
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 »

Aussitôt essayé avec SDDRIVE sur TO8 puis sur MO5. Premières impressions :
- Pour un connaisseur, c'est extraordinaire :D
- Pour un djeun habitué à la TV HD et quadriphonie c'est nul de chez nul :twisted:

Techniquement :
- A la fin du morceau la vidéo reboucle bien au début avec SDDRIVE.
Je vais essayer dès que possible avec dcmoto, il doit y avoir un petit bug dans l'émulateur.
- Avec le MO5 il y a un problème de couleur.
(peut-être parce que les octets couleur des MO et des TO n'ont pas la même structure).

Le plus surprenant est la rapidité de l'animation et surtout des changements de plan. Avec ma méthode ils durent plusieurs secondes, ici ils sont presque parfaits. Pourrait-on diminuer un peu le nombre d'images par seconde et afficher en plein écran ?

Le talent de __sam__ n'est plus à prouver, mais chaque démo est toujours une nouvelle bonne surprise !

@__sam__ : Si tu es rentré de vacances, je t'offre immédiatement un contrôleur SDDRIVE, sinon j'attends ton retour.
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__ »

Merci pour la proposition Daniel. Je l'accepte volontiers. Je suis toujours en vacance jusqu'à la fin du mois, mais je repasse chez moi vendredi. Ce sera trop juste je pense pour la poste. Donc autant repousser cela au début septembre (je rentre le 1er).

Tu as donc testé sur le vrai matériel. C'est une excellente nouvelle que ca tourne aussi là dessus. Pour l'émulation, en faisant

Code : Tout sélectionner

LOOP
  LBSR $A028
  BCS LOOP
j'ai bien le rebouclage sous DCMoto. Oui il doit y avoir un bug quelque part au niveau de l'émulation SD.

Concernant la couleur sur MO5 oui c'est normal c'est un travail-en-cours. Pour l'instant je teste en N&B exclusivement. La couleur viendra naturellement quand j'aurais tracké le dernier bug relatif à l'audio.

Concernant le bug audio: Je pense que l'un des chemin d’exécution du player ne boucle pas exactement à 199µs, ce qui fait que le morceau la440.sd ne joue pas exactement la même note pendant l'apparition du fond au début qu'à la fin avec le fond statique (qui est joué légèrement plus aigu). C'est un bug bizarre car même si je me suis trompé de quelques µs, je ne pensais pas pouvoir entendre une variation de tonalité du LA440.

Techniquement le player joue la musique (en principe) à 199µs (5.05khz) même pendant les inter-blocs. Je confirme que l'émulateur envoie $FE sitôt la fin de bloc atteinte sans envoyer de $FF semble-t'il (voir "FIN_SPECIAL" dans le code). Durant ces 199µs une trame de 3 octets est lue. Elle contient l'échantillon sonore 6bits, et un marqueur permettant d'interpréter les 2 octets suivants de plusieurs façon:
  • 2 octets = affichage 8 parties de pixels videos suivit d'un déplacement de 4 octets. C'est pratique pour les changements d'écran massifs. L'écran complet contient 80*50*3=12 000 parties de pixels qui sont rafraîchis en 298.5ms dans le pire des cas. Le débit de 3fps minimum est assuré sans compression. C'est le grand "plus" de ce player: il est rapide.
  • 2 octets = 1 déplacement de 8 bits (1 à 256) suivi de l'affichage de 4 parties de pixels videos, suivit du déplacement de 2 octets en mémoire video. C'est le mode "normal".
  • 2 octets + 1 bit du marqueur = changement du pointeur video à une adresse arbitraire (13bits=8ko) + affichage de 2 parties de pixels. Ca sert quand il faut reboucler en haut de l'écran ou s'il y a des changements très éloignés les uns des autres à l'écran.
Oui la performance est au rendez-vous, et le player "aime" bien les débits rapides, à tel point que la compression est meilleure avec une video 30fps qu'à 8fps. En effet à 30fps les différence d'une image à la suivante sont mineures et l'encodage les représente de façon hyper-efficace.

Le fichier SD est n'est plus à présent réalisé par un script Perl combiné à libMagick, mais est 100% fait en LUA. Il sera ainsi plus facile à diffuser. Mais avant de rendre définitivement public le code je dois aussi ajouter le calcul du fps et du facteur de zoom optimal par le convertisseur comme avec celui de SDANIM7.

Autres trucs à tester: https://www.cjoint.com/doc/18_08/HHviMz ... dvideo.zip
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 »

Les nouveaux morceaux sont, comme le premier, excellents. J'ai une très mauvaise oreille et je n'entends pas de défauts dans le son. Avec la modif du player, le mode "boucle" fonctionne maintenant aussi bien dans dcmoto qu'avec le vrai matériel, et les octets couleur sont bons sur MO comme sur TO.

Concernant l'émulateur, c'est sûr qu'il ne retourne pas d'octet $FF avant l'octet $FE de début de bloc. La carte SD en retourne probablement un, mais il faudrait le vérifier.

J'ai essayé de corriger le bug sur la commande CMD12, mais l'émulation de la carte SD est tellement compliquée que plus rien ne marchait après la modification, alors j'abandonne provisoirement. Pour que cette commande fonctionne avec l'émulateur je crois qu'il faut l'envoyer après la lecture d'un octet complet. Dans dcmoto le même compteur de bits sert pour la lecture et l'écriture, une vraie carte SD n'a pas cette contrainte.
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 : 21 août 2018 15:08 Pour que cette commande fonctionne avec l'émulateur je crois qu'il faut l'envoyer après la lecture d'un octet complet.
Oui, ca doit venir de là alors, car je détecte la fin de la video en lors des accès en mémoir vidéo en $1FFF avant même des décoder le 1/2 octet restant. [EDIT] ok, c'est confirmé. Je viens d'ajouter la lecture du 1/2 octet restant et je n'ai plus besoin du test sur la carry :D

Concernant le bug audio: J'ai vérifié toutes les branches d’exécution et toutes tournent à 199µs exactement. Je ne comprends donc pas ce qu'il se passe avec le LA440 qui donne l'impression d'être joué plus bas en début de video quand le fond se dessine, et plus haut à la fin quand le fond est devenu statique. J'ai analysé le spectre du LA440 joué par sddrive:
i4.png
i4.png (820.04 Kio) Consulté 6475 fois
Ce qu'on voit ce n'est pas un changement de fréquence du pic ce qui suggère que le timing à 199µs est correctement respecté. En revanche on voit qu'au bout de 1.8 sec environ, le spectre change complètement d'aspect. Outre le pic à 440hz (et ses harmonique: 880hz, 1200hz), on voit tout d'un coup plein d'harmoniques parasites apparaître. Ca doit être cela que je j'entends en fait. Le LA440 n'est plus pur et se voit polluer par des notes aigues parasites. Je ne vois pas d'où elles viennent ni pourquoi ca démarre à 1.8sec et pas dès le début. Visuellement ca démarre pile au dernier changement graphique visible. C'est curieux cette coïncidence.
Dernière modification par __sam__ le 21 août 2018 20:07, modifié 1 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 »

Il y a des chances que le fautif soit dcmoto. As-tu essayé, dans les options, de changer la fréquence d'échantillonnage ?

Pour calculer l'échantillon, j'intègre la valeur de sortie du CNA sur la période d'échantillonnage. Mais le calcul se fait à la fin d'une instruction, donc pas au cycle près, et il peut y avoir de petits décalages et arrondis qui faussent un peu la valeur. Selon les instructions le décalage peut varier d'un échantillon à l'autre, c'est peut-être audible. Sans compter les erreurs toujours possibles dans le décompte des cycles. Tout ça pour dire que dcmoto n'est pas une référence, il faudrait enregistrer la sortie son du Thomson.

[Edit]
Enregistrement en sortie de MO5 avec SDDRIVE : http://dcmoto.free.fr/tmp/440Hz.wav
Sur les Thomson la sortie son est pas mal parasitée par l'activité sur le bus, je ne sais pas si c'est facile à analyser.
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 »

Nouvel enregistrement en sortie du MO5 : sultans.zip (disponible 30 jours)
Mot de passe pour décompresser l'archive : sddrive
Daniel
L'obstacle augmente mon ardeur.
Répondre