	DE LA PROGRAMMATION DES CARTES GRAPHIQUES


	Beaucoup d'Ataristes se sont, comme moi, sentis limits par
l'affichage standard qu'offre leur Mega ST(E) ou leur TT et ont aquis une
carte graphique. C'est alors que commence une longue qute: dnicher
quelques softs compatibles avec leur nouvelle machine...

	Les problmes commencent trs tt, j'en veux pour preuve que le
bureau standard de Magic 5 ou de l'AES 4.01 sous MultiTOS affichent en
32768 couleurs des icnes mconnaissables: le codage des pixels est celui
du Falcon et non celui des drivers VDI de la carte NOVA que j'utilise.
Programmation propre?... Le grand Calamus SL, lui mme, ncessite un
programme AUTO pour tourner en 32K sur carte NOVA.

	Cet article se propose de vous fournir quelques informations
essentielles afin que vos affichages soient corrects sur une carte
graphique de type NOVA (informations valables aussi pour le 256 couleurs
sur une Matrix ou une Cyrel).


	Le mode 32768 couleurs
	----------------------

	Commenons par le High Color (32768 couleurs). Sur un Falcon comme
sur une NOVA, les pixels sont rangs ligne par ligne et de gauche  droite
sur un mot chacun (deux octets).
	Sur Falcon: RRRRRVVV VVVBBBBB (rouge, vert bleu)
	Sur NOVA:   VVVBBBBB xRRRRRVV (octets inverss! Bit x ignor).

	Voici comment convertir une image se trouvant  l'adresse
image_adr et de dimensions image_x et image_y:

	BSS

image_adr: ds.b 320x240x2	; assez pour du 320x240xTC
image_x: ds.w 1
image_y: ds.w 1

	TEXT

;
; conversion de Falcon vers NOVA
;
; Utilise A0,D0-D1
;
; 36 octets d'assembleur, programmeurs Falcon, pensez  nous!
;

Falc_2_Nova:
   	lea image_adr,a0
	move image_x,d0
	muls image_y,d0		; nombre total de pixels de l'image
				; DO devient un LONG
.loop:
	move (a0),d1		; Falcon: xxxxxxxx xxxxxxxx RRRRRVVV VVVBBBBB
       	ror.l #5,d1		; BBBBBxxx xxxxxxxx xxxxxRRR RRVVVVVV
	lsr #1,d1		; BBBBBxxx xxxxxxxx xxxxxxRR RRRVVVVV
	rol.l #5,d1		; xxxxxxxx xxxxxxxx xRRRRRVV VVVBBBBB
	ror #8,d1		; xxxxxxxx xxxxxxxx VVVBBBBB xRRRRRVV
	move d1,(a0)+		; remplace par le codage NOVA
	subq.l #1,d0		; un pixel de moins
	bne.s .loop		; si non nul, pas termin
	rts

;
; conversion de NOVA vers Falcon
;
; Utilise A0,D0-D1
;
; 34 octets d'assembleur: programmeurs sur carte, pensez au Falcon!
;
Nova_2_Falc:
	lea image_adr,a0
	move image_x,d0
	muls image_y,d0		; nombre total de pixels de l'image
				; DO devient un LONG
.loop:
	move (a0),d1		; NOVA: VVVBBBBB xRRRRRVV
	ror #5,d1		; RRRVVVVV BBBBBxRR
	lsr.b #1,d1		; RRRVVVVV 0BBBBBxR, (CCR bit X=R)
	roxr #2,d1		; RRRRRVVV VV0BBBBB, (CCR bit X=x)
	move d1,(a0)+		; remplace par le codage Falcon
	subq.l #1,d0		; un pixel de moins
	bne.s .loop		; si non nul, pas termin!
	rts

	On remarquera au passage que le Falcon utilise rellement 16 bits
alors que la carte NOVA n'en utilise que 15, d'o une lgre perte de
qualit de l'image.

	Le mode 256 couleurs
	--------------------

	Passons maintenant au mode 256 couleurs qui se trouve tre le mme
sur une NOVA que sur une Matrix ou une Cyrel (quelques connaissances aux
Etats-Unis). Contrairement au mode prcdent, le travail est ici plus
lourd car la diffrence de codage est de taille!
	Carte graphique: 1 pixel = 1 octet (0  255). Ce codage trs
simple permet un travail au niveau du pixel d'une grande rapidit et d'une
grande simplicit (les deux vont souvent de paire).

	Sur un Falcon, il en va tout autrement, les pixels sont regroups
en ligne par paquets de 16. Appelons A le premier jusqu' P le seizime,
ils sont dfinis ainsi sur 8 bits chacun:
	A = a7,a6,a5,a4,a3,a2,a1,a0
	...
	P = p7,p6,p5,p4,p3,p2,p1,p0

	On trouve alors en mmoire, sur un Falcon, 8 mots ainsi dfinis:
	1er mot:  a0,b0,c0,.........,p0
	2me mot: a1,b1,c1,.........,p1
	...
	8me mot: a7,b7,c7,.........,p7

	Le premier mot contient tous les bits de poids faible des 16
pixels, jusqu' huitime mot qui lui contient tous les bits de poids fort
des 16 pixels.

	Par chance (tout n'est pas compltement noir), l'ordre hardware
des indexs de couleur est EXACTEMENT le mme sur NOVA, MATRIX, CYREL et le
mode Atari standard! De ce fait, on peut trs bien raliser la conversion
sur des graphiques au format Shifter (ceux directement affichables).

	Une petite explication: les instructions de dcalage (ASR, ASL,
LSR, LSL, etc...) laissent dans le bit X du CCR la valeur du dernier bit
dplac. Les instructions ROXL er ROXR permettent de rcuprer ce bit,
c'est ainsi que je fais 'voyager' les 0 ou 1 d'un codage  l'autre.

	Voici les routines pour passer d'un mode  l'autre (on supposera,
pour simplifier, que l'image a une largeur multiple de 16 pixels):

	BSS

image_adr: ds.b 640x480		; du VGA standard
image_x: ds.w 1
image_y: ds.w 1

	TEXT

;
; Conversion du Falcon 8 plans entrelacs vers carte Graphique
;
; Utilse A0-A2 et D0-D7
;
; 92 octets d'assembleur: ne vous en privez pas!
;
Falc_2_Nova_256:
	lea image_adr,a0	; image  modifier
	move image_y,a2		; compteur de lignes
.loop:
	move image_x,d2		; largeur
	lsr #4,d2		; nombre de paquets de 16
	subq #1,d2		; pour DBF
.ligne:
	move d2,a1		; sauve le compteur
	movem.w (a0),d0-d7	; 8 plans
	swap d1			; conserve le plan
	move #15,d1		; pour 16 pixels
.pixels_16:
	swap d1			; compteur D1 dans le mot suprieur
				; et retour du plan dans le mot infrieur
				; les valeurs suivantes de D7 sont celles
				; de la premire des 16 boucles (pixel A)
	lsl.l d7		; D7=xxxxxxxx xxxxxxxa7 b7...i7 j7...p7 0
	swap d7			; D7.w = xxxxxxxx xxxxxxxa7
	lsl d6
	roxl d7			; D7.w = xxxxxxxx xxxxxxxa7a6
	lsl d5
	roxl d7			; D7.W = xxxxxxxx xxxxxxa7a6a5
	lsl d4
	roxl d7			; D7.W = xxxxxxxx xxxxxa7a6a5a4
	lsl d3
	roxl d7			; etc...
	lsl d2
	roxl d7
	lsl d1
	roxl d7
	lsl d0
	roxl d7			; D7.W = xxxxxxxx a7a6a5a4a3a2a1a0=pixel A
	move.b d7,(a0)+		; un pixel
	swap d7
	swap d1      		; retour au compteur
	dbf d1,.pixels_16
	move a1,d2		; compteur pour une ligne
	dbf d2,.ligne
	subq #1,a2 		; une ligne de moins
	cmp #0,a2		; pas encore 0?
	bne.s .loop		; non, retour  la boucle
	rts


	La routine qui suit peut encore tre optimise en crivant 256
sous programmes qui selon la valeur d'un pixel remplissent simplement les
bits  1 dans chaque plan. On traite  peu prs 60% d'informations en plus
dans le mme temps! C'est cette mthode que j'utilise dans M_Player pour
afficher une image 256 couleurs sur un TT sans carte graphique (donc en
8 plans entrelacs). Cette routine tait un peu trop 'longue' pour la
retranscrire ici...

;
; Carte graphique vers Falcon 8 plans entrelacs
;
; Utilise A0-A2, D0-D7
;
; 100 octets d'assembleur
;
Nova_2_Falc_256:
	lea image_adr,a0	; image  modifier
	move image_y,a2		; compteur de lignes
.loop:
	move image_x,d2		; largeur
	lsr #4,d2		; nombre de paquets de 16
	subq #1,d2		; pour DBF
.ligne:
	move d2,a1		; sauve le compteur
	move #15,d1		; pour 16 pixels
.pixels_16:
	swap d1			; sauve le compteur
	move.b (a0)+,d5		; un pixel sur un octet
	lsr.b d5
	roxl.w d0		; bit de poids faible
	lsr.b d5
	roxl.w d1		; puis suivant...
	lsr.b d5
	roxl.w d2
	lsr.b d5
	roxl.w d3
	lsr.b d5
	roxl.w d4
	lsr.b d5
	roxl.w d6		; d6 contient deux plans
	swap d6
	lsr.b d5
	roxl.w d6
	swap d6
	lsr.b d5
	roxl.w d7
	swap d1			; retour au compteur
	dbf d1,.pixels_16	; jusqu' 16 points
	move d6,d5		; le deuxime plan de D6
	swap d6
	movem.w d0-d7,-16(a0)	; remplace par le codage Falcon
	move a1,d2
	dbf d2,.ligne
	subq #1,a2 		; une ligne de moins
	cmp #0,a2		; pas encore 0?
	bne.s .loop		; non, retour  la boucle
	rts


	La dtection d'une carte
	------------------------

	Certaines cartes installent un cookie qui permet de les
identifier. Mais, sur Mega STE et TT, comme elles sont connectes sur le
port VME, il suffit de vrifier que Physbase (fonction XBIOS) renvoit une
adresse de l'cran dans la plage VME:
	- sur TT de $FE000000  $FEFFFFFF
	- sur Mega STE de $A00000  $DFFFFF

	Ainsi on s'affranchit des cookies (diffrents pour chaque carte)
et on touche galement les cartes inconnues (c'est ce qui s'est pass avec
M_Player et la carte Cyrel que je ne connaissais pas: le programme a
tourn sans problmes).

	Voici la routine correspondante:

	BSS

machine: ds.l 1			; valeur du cookie _MCH
carte: ds.w 1			; flag (0=pas de carte, $FF une carte)
physbase: ds.l 1		; adresse de l'cran

	TEXT

carte_ou_non:
	clr.l machine		; par dfaut, c'est un ST...
	sf carte		; par dfaut, pas de carte graphique

	pea cookies
	move #38,-(sp)
	trap #14    		; appel  Supexec, lit le cookie _MCH
	addq.l #6,sp

	move #2,-(sp)
	trap #14    		; physbase
	addq.l #2,sp
	move.l d0,physbase

	cmp.l #$00010010,machine	; un Mega STE?
	bne.s .suite		; non, autre test

	cmp.l #$a00000,d0	; c'est un Mega STE, verif des bornes VME
	bmi.s .fin		; en dessous, pas de carte
	cmp.l #$e00000,d0
	bpl.s .fin		; au dessus, pas de carte

	st carte
	bra.s .fin		; sinon, on a a faire au port VME!!

.suite:
	cmp.l #$00020000,machine	; un TT?
	bne.s .fin		; non, termin

	swap d0
	lsr #8,d0		; octet suprieur de l'adresse
	cmp.b #$fe,d0		; gal  FE dans le VME
	bne.s .fin

	st carte		; sinon, c'est une carte VME

.fin:
	rts

cookies:
	move.l $5a0,a0		; adresse cookie jar
	cmp.l #0,a0		; nulle?
	beq.s .fin		; oui, pas de cookies
.suite:
	move.l (a0)+,d0		; le cookie
	beq.s .fin		; si 0, fin de liste
	cmp.l #'_MCH',d0	; machine?
	bne.s .autre           	; non, on saute
	move.l (a0)+,machine	; oui, on conserve la valeur
	bra.s .fin		; et on sort
.autre:
	addq.l #4,a0		; saute la valeur
	bra.s .suite		; boucle
.fin:
	rts


	On pourrait largement amliorer cette routine en l'largissant 
toutes les machines. Par exemple un mode suprieur  16 couleurs sur un
ST, Mega ST, STE, Mega STE signale forcment une carte graphique, plus de
256 couleurs sur un TT galement ou plus de 65536 couleurs sur un Falcon.


	Conclusion
	----------

	J'espre que cet article aidera les possesseurs de cartes 
programmer leur nouveau matriel plus en profondeur et surtout l'ensemble
des programmeurs  adapter leurs routines  ces tranges Ataris qui, par
une amlioration de leur hardware, se trouvent paradoxalement lss.

	J'attends donc avec impatience une version TT+NOVA de tous les
jeux True Color tournant sur Falcon, merci d'avance!

	Vos ractions sont les bien venues sur Internet gtello@planete.net
ou  la rdaction qui transmettra.

	Guillaume Tello.