Mémoire physique ou mémoire logique
Il y a deux types de mémoires pour la vidéo sur un atari ST:
La mémoire/écran physique: c'est le contenu de cette mémoire qui est affiché à l'écran.
La mémoire/écran logique: c'est celle qui est utilisée pour générer une image avant affichage.
Pour éviter de consommer de la mémoire, du temps CPU, il faudrait préparer une nouvelle image à afficher pendant le retour du faisceau en haut à gauche de l'écran directement en mémoire physique. Ainsi, l'image traitée s'afficherait directement pendant le nouveau balayage. Cependant, ce laps de temps où le faisceau passe du point en bas à droite au point en haut à gauche de l'écran est très court. Comme il n'est pas évident de pouvoir effectuer tous les calculs d'une nouvelle image pendant ce retour (D'autant plus qu'il y a d'autres choses à faire pendant ce laps de temps, comme gérer le curseur de la souris, le son, ...), le plus simple est de travailler ailleur que dans la mémoire physique pour préparer cette image, ce sera en mémoire logique. Mémoire physique sur laquelle nous ne fairons dés lors rien, donc celle-ci conservera l'image précédente à afficher. Il restera à permuter les écrans logique et physique lorsque le travail sur la nouvelle image sera terminé et justement, pendant le retour du faisceau en haut à gauche afin d'éviter un effet de scintillement. Cette permutation pourra d'ailleurs se faire très rapidement, puisqu'il suffira de changer le vecteur de la mémoire vidéo sur la mémoire logique (qui deviendra ainsi physique). L'ancienne mémoire physique devenant mémoire logique...
Les fonctions disponibles sont pour le GFA BASIC:
XBIOS(2) : retourne l'adresse de la mémoire physique
XBIOS(3) : retourne l'adresse de la mémoire logique
XBIOS(5;L:physique;L:logique;W:résolution) : permet de définir les érans physique et logique (ainsi que la résolution).
Evidemment, c'est les même fonctions en assembleur...
Sauf que le résultat se retrouve pour XBIOS(2) et XBIOS(3) dans le registre D0 sur 32 bits. et que XBIOS se traduit par TRAP #14. Les paramètres sont passés dans la pile. C'est dans la pile, ce qui veut dire qu'il faut passer le dernier paramètre et revenir au premier de la fonction avant de déclencher la fonction. Enfin corriger la pile après execution...
Voici un petit exemple qui va remplir l'écran physique avec des colonnes...
On récupère d'abord l'adresse de l'écran physique
move.w #2,-(sp)
trap #14
addq.l #2,sp
movea.l d0,a0
Le registre d1 sera utilisé pour dessiner une colonne
move.l #$f0f0,d1
L'écran fait 32000 octets. En travaillant en long (32 bits), il faut
effectuer 8000 opérations pour dessiner dans l'écran
move.w #8000,d0
bcl:
Ici, on dessine dans l'écran
move.l d1,(a0)+dbra d0,bcl
Pour voir le résultat, lecture avec attente d'un caractère au claviermove.w #1,-(sp)
trap #1
addq.l #2,sp
Fin du programme
clr.l -(sp)
trap #1
Télécharger le bout de code:
On constate un petit problème à travailler ainsi: la souris nous fait un carré contenant l'image précédente lorsque nous la bougeons.
C'est normal, le système mémorise l'image de l'écran avant de dessiner le curseur. Lorsque l'on bouge la souris, il redessine donc l'image d'origine sur celui du curseur afin de restaurer le contenu de l'écran. Puis il remémorise l'image et redessine le curseur aux nouvelles coordonnées. Pour éviter ce problème, il faut simplement désactiver le dessin de la souris pendant le temps du calcul de l'image.
Vous pourrez utiliser les fonctions vdi ou, plus rapide à programmer, les fonctions du lineA pour desactiver/activer le pointeur de la souris (Voir chapitre sur la gestion de la souris).