encore une chtite question - Page 9

Groumpf, je voulais dire (W,H)=(16,8)

ds.b 1 octroie 1 octet, plus généralement ds.b n en met n.
dc.b 0 te mettra par conter un octet à 0, de même dc.b n mettra un octet à n.
(cf manuel du 68000)

sauf si le programme est archivé

Flanker
: sauf si le programme est archivé

ou compressé.

Bref, il ne faut jamais se fier à ce que les variables globales restent intactes pour la prochaine exécution (ni l'inverse, d'ailleurs)!

Quelle version ?

Passage des paramètres par les registres. Comme pour TIGCCLIB.
Réfère-toi au header pour savoir dans quels registres précisément sont attendus les paramètres.
C'est un header pour le C, il contient les prototypes des fonctions :
void Sprite16_OR_R(short x asm("%d0),short y asm("%d1"),short h asm("%d2"),short *sprt asm("%a1"),void *dest asm("%a0"));
Ce qui signifie que le paramètre x est attendu dans le registre d0.w (short = word), y dans d1, h dans d2, sprt dans a1 et dest dans a0.

En fait, tu peux aussi utiliser des fonctions qui prennent leurs paramètres sur la pile (comme les ROM_CALLs).
Les fonction dont le suffice est _R prennent leurs paramètres par les registres, sinon, c'est sur la pile.

Martial Demolins
: ah zut alors, donc pour tout ce qui est paramètres et autres, il vaut mieux faire un fichier externe alors?

Oui.

Et au fait, ptite question par rapport à ExtGraph, lorsqu'on a installé la lib, on se débrouille avec comme pour les appels à tigcclib?

Oui.

lea 1(A0),A0 ;passe au byte suivant add.w #2,D2 ;offset du bit à tester (côté droit de la voiture)

Ce n'est pas valable, ça. Il se peut que tu dépasses 7, et que tu dois donc dans ce cas ne pas avancer (et non pas avancer de 2 octets) et soustraire 6 plutôt que ce que tu fais.

EDIT: Correction: Les numéros de bits sont LSB-first, donc si on déborde, on passe à l'octet d'avant, pas d'après.

Martial Demolins
: non, d'abord je soustrais 5 (et non 6),

Et pourquoi ça? +2-8==-6.

Alors c'est ton add #2 qui devrait être un add #3. -5+8==+3.

Martial Demolins
: Il faut créer un fichier avec le code de toutes les fonction,

Non, surtout pas! Il faut faire beaucoup de fichiers (compilés séparément, pas de hacks avec include, sinon ça ne sert à rien) avec le code d'une fonction chacun, pas l'inverse! Sinon, au linkage, le linker linkera toutes les fonctions.

faut-il exporter leur nom?

Oui. Sinon, tu penses que le linker va la trouver comment, ta fonction? Par clairvoyance?
(Au fait, techniquement parlant, le linker peut voir les symboles locaux (non-exportés) si on a assemblé avec les bonnes options, mais ils sont locaux, donc pas considérés pour la résolution de références.)

Et qu'est-ce que le fichier .a, comme j'ai pu voir dans ExtGraph? Ca doit être la compilation du source de la lib je pense

Oui, sauf pour un petit détail: "la compilation des sources". Cf. le premier point. Il y a un fichier .o pour chacun fichier source, et le fichier .a n'est qu'un arball (le prédécesseur des tarballs, qui n'est utilisé plus que pour ça et pour les paquets deb) de tous ces fichiers objet.

Ligne de commande: tigcc -ar fichier1.asm fichier2.asm fichier3.asm ...
IDE: Project / Options / Target: Function archive (.a)

k merci

Dans GTC, oui. Dans TIGCC, non (tu dois tout redéfinir, et avec des "equ").