[Thomson] Vidéo sur MO5

[Daniel]

Le mode SPI de la carte SD utilise une horloge asynchrone. Un top d'horloge (et un seul) est envoyé pour chaque lecture/ecriture de bit. Le débit n'est pas régulier, car il dépend du traitement effectué pour chaque octet. Je ne crois pas qu'il soit possible d'utiliser le timer, car il serait trop compliqué de synchroniser les entrées/sorties avec l'horloge. Ce n'est qu'une intuition, il faudrait quand même approfondir cette piste.

Le déplacement non signé, avec la technique de sam, apporte une légère amélioration (moins d'octets envoyés inutilement). Ce n'est pas suffisant s'il y a trop de différences d'une image à l'autre, comme vous pouvez le constater dans la vidéo "Mickey Plays Papa" :
http://dcmoto.free.fr/tmp/mickey-papa_win.zip

[__sam__]

Pour la lecture, l'étape élémentaire est un

Code : Tout sélectionner

ldb  ,u
aslb
rola

soit 8 cycles. Donc avec quelque chose comme

Code : Tout sélectionner

orcc #$50   ; on ne veut pas être perturbe
...
ldd  #8
std  $E7C6  ; horloge sur 8 cycles
lda  #$12   ; timer en mode répétition auto sans generation d'irq
sta  $E7C5  ; top départ. dans 8 cycles l'horloge fera 'top'
nop
.. attente 8 cycles ..
nop         ; ici l'horloge produit son top
ldb  ,u     ; et donc on peut lire
aslb
rora
.. 7 fois ..
inc  $E7C5  ; stop de l'horloge
ldb  ,u
aslb
rora

C'est un squelette, mais ca donne l'idée. Il faut voir si électriquement on a bien un 'top' correct. Il est possible de devoir faire passer le front descendant programmatiquement par un tst $E7C6, mais il me semble que le timer doit pouvoir générer des tops tout seul (il le fait en mode écriture de K7). Il faudra peut-être fagociter les routines de programmation du timer pour l'ecriture k7. Bon c'est un peu plus complexe que la solution actuel, mais ca peut être instructif concernant l'utilisation du timer. Le débit est alors à la louche en incluant le temps du BSR autour de 100µS par octets, soit 10Ko/sec. Juste un x2 en perspective. C'est bien, mais pas le plus rapide qui soit non plus.

Heu... est-ce qu'on peut faire "LSR ,U" pour cumuler le LDB + ASR en une seule opération? Il y a quoi de connecté en sortie en ",U" ?

Pour augmenter la bande passante, reste le coté soft. On voit que lorsqu'un changement a lieu, les lignes juste en dessous sont aussi affectées. Je pense que le big-offset qui encode un offset sur 13 bits et une répétition sur 1 à 5 lignes est intéressant. Mais on obtiendrait quel gain? Si je prends le cas favorable d'un bloc 5x8 affecté (5 lignes), en offset courts on a 10 octets à traiter, en octets longs seulement 7. Ca fait un gain de 30% (au maximum), mais il n'y a plus besoin de faire du "padding" inutile pour aller d'un bout à l'autre de l'écran. Allez disons 35% au mieux.

Sinon, les changements étant rarement isolés, même sur les déplacements courts, un autre format de codage est intéressant pour le format court:

• de v=0 à $7F, déplacement plus changement de 1 octet
• de v=$80 à $FF, aucun déplacement, mais recopie de (v & $7F) octets horizontaux.

Ca devrait augmenter la bande passante. On peut même mixer une recopie horiz et verticale en faisant ainsi: Dans le cas (v & $80)!=0, si (v & 40) == 0, on prends comme offset dans le leay la valeur 1, sinon la valeur 40. Ainsi si b6 est à 1 on recopie (v & $3F) octets verticalement, sinon horizontalement. Le bloc 5x8 est codé en 6 octets seulement. C'est même mieux que les big-offsets.

Code : Tout sélectionner

 PLAY1
9E6F 8D3E                  BSR   RBYTE         lecture octet deplacement
9E71 2B10                  BMI   EXTENS        mode etendu
9E73 2716                  BEQ   RETOUR        fin de fichier
9E75 31A6                  LEAY  A,Y           incrementation index ecran
9E77 8D36                  BSR   RBYTE         lecture octet image
9E79 A7A4                  STA   ,Y            affichage de l'octet
                      PLAY2
9E7B 301F                  LEAX  -1,X          decrementation compteur
9E7D 26F0                  BNE   PLAY1         nouvelle lecture
9E7F 8D0E                  BSR   RBIT16        lecture deux octets CRC
9E81 20E3                  BRA   PLAY0         lecture bloc suivant

; RECOPIE ETENDU: 1bnnnnnn
; b=1 => verticalement
; b=0 => horizontalement
; n    =>  taille de la recopie

EXTENS
    LDB    #1
    BITA   #%0100000
    BNE    EXTENS2
    LDB    #40
EXTENS2
    PSHS   Y
    ANDA   #%00111111
EXTENS3
    PSHS   D
    BSR    RBYTE
    STA    ,Y
    PULS   D
    LEAY   B,Y
    DECA
    BNE    EXTENS3
    PULS   Y
    BRA    PLAY2

[Edit] j'ai ajouté le code pour le mode "recopie" horiz/verti.

[Daniel]

Pour l'instant, la machine cible est le MO5, j'oublie donc provisoirement le timer.

La dernière idée est bonne, car elle permet d'augmenter le nombre de modifications par trames.
Dès que j'aurais un peu de temps je l'essaierai.

de v=0 à $7F, déplacement plus changement de 1 octet
de v=$80 à $FF, aucun déplacement, mais recopie de (v & $7F) octets horizontaux.

Plus compliqué, mais peut-être encore plus bénéfique :
- traiter l'image par colonne
- compresser les modifications en RLE, un peu comme le format MAP.

[__sam__]

- traiter l'image par colonne

est l'un des cas que j'ai ajouté dans mon message ci-dessus. C'est pas compliqué. En fait je traite le cas vertical et horizontal de la même façon. L'offset passe de 1 à 40 entre le mode vertical et horizontal. Ca peut même s'écrire de façon super compact si on s'autorise à utiliser du code auto-modifié

sam (quoi pas propre l'auto-modifié? Oui mais c'est 'achement plus rapide)

[Daniel]

J'avais bien compris l'idée des répétitions verticales, mais quand une colonne est traitée il faut bien remonter pour traiter la suivante. Il est assez compliqué de faire à la fois des répétitions horizontales et verticales, car on se balade tantôt vers la droite, tantôt vers le bas, mais il ne faut pas laisser de côté certaines zones de l'écran. C'est pourquoi je voulais essayer de faire uniquement des répétitions verticales, pour simplifier.

Je crois qu'après le brain-storming il faudra faire des essais concrets pour valider nos théories. Je propose d'utiliser la vidéo de Mickey pour essayer d'améliorer les mauvais passages. Je peux fournir les images de départ sous forme de fichiers .bmp.
http://demo.ovh.com/fr/6bab885656b435b0 ... 4239fc134/

L'auto-modification du code est une technique dont il ne faut pas abuser en temps normal. Quand il est vital de gagner quelques cycles tout est permis, et je l'utilise aussi. De même que l'instruction qui semble ne rien faire, mais qui fait quelque chose si on se branche au milieu (un seul octet de plus au lieu de deux pour un BRA).

[6502man]

Le download du fichier est corrompu !!!

[Daniel]

Ce n'est pas la première fois qu'ovh me fait le coup du fichier corrompu
Je l'ai mis chez un autre hébergeur : http://www.partage-facile.com/97K0LX3IY ... p.zip.html

[Carl]

la demo sur un vrai MO5 est bluffante !
encore bravo Daniel

pour ceux qui n'ont pas la carte SDMOTO :




carl

[jester]

C'est bien joli tout ça mais sans toolkit je vois pas ce que mémé Simone va pouvoir en faire ?
Moi j'attends l'API Java pour l'exploiter...

[DataPro]

Magnifique... j'espère avoir le temps d'expérimenter tout çà... moi qui n'est pas encore trouver de carte compatible avec mon interface SD DB9...

[Daniel]

Normalement toutes les cartes SD et SDHC sont compatibles. Si, par hasard un modèle ne l'est pas il faut l'étudier pour trouver le problème. Je ne veux pas qu'il y ait le moindre doute sur le fonctionnement de l'interface.

Avec SDMOTO, je n'ai eu jusqu'à ce jour aucun échec. Avec DCMO, il y a eu des problèmes au début, ils sont tous résolus maintenant et je publierai le schéma dans les prochains jours. A noter qu'une tension d'alimentation du MO5 anormalement faible peut provoquer des erreurs : s'il est alimenté en 12V la régulation produit environ 4,4V. Le MO5 fonctionne, mais les niveaux en sortie du PIA 6821 sont trop faibles pour certaines cartes SD. Si vous avez des problèmes, vérifiez la tension d'alimentation de l'interface, elle doit être comprise entre 4,8V et 5,2V. Sinon il est toujours possible d'utiliser une alimentation extérieure.

Attention aussi de ne pas mélanger les programmes et les démonstrations pour TO8SD et SDMOTO d'une part, MO5SD et SDMO d'autre part. Il n'y a aucune compatibilité entre les deux systèmes pour les programmes de lancement, et la plupart des fichiers .sd sont différents (plus précisément tous sont différents, sauf mickey-papa et simon-s-cat).

Pour compléter la vidéo, je fournis enfin la boîte à outil qui va bien pour faire des démos, jester n'a plus d'excuse.

jester-s-toolkit.jpg (27.16 Kio) Consulté 3698 fois

[6502man]

Ou est il possible de commander la Jester's Toolkit ?

[Daniel]

ici : http://www.melissaanddoug.com/take-along-tool-kit

[6502man]