encore une chtite question - Page 13

[un peu HS mais pas trop quand même]Pourquoi tu mets des lea x(%an),%an alors que x ne dépasse jamais 8 ? c un gachis de place, tu devrais les remplacer par des addq
Et puis move.w #50,-(A7); move.w #20,-(A7), ça peut s'optimiser en un pea...
Et tant qu'on y est, ne sauvegarde pas les registres d0,d1,d2 et a0,a1, ça ne sert à rien (enfin, sauf dans certains cas particuliers, notemment dans les interruptions)[/un peu HS mais pas trop quand même]
Par contre, pour le problème de getsn, je n'ai pas vu d'où ça venait

Je soupçonne que les paramètres ne doivent pas être passés par la pile dans le cas de getsn...

Si getsn est une fonction de tigcclib, alors c'est ça.

Le prototype est extern char *getsn(char* asm("a2"),long asm("d3"))__ATTR_LIB_ASM__; (cf. stdio.h), donc il faut passer le buffer en %a2 et la longueur en %d3.

dans l'aide, non ?

L'aide ne montre que des prototypes simplifiés. Les prototypes complets se trouvent dans les headers eux-mêmes (répertoire Include/C).

GrayGetPlane.
Mais effectivement, c'est une macro.
La lib exporte 2 labels : __D_plane et __L_plane, ils correspondent chacun un plan.

Ba tu fais en ASM ce que font les macros en C...
Mais sinon, pourquoi est-ce que tu t'attaches à absolument tout développer en assembleur ? ça ralentit considérablement la programmation par rapport au C.
EDIT: Post croisé

:/
Ben tu dois pouvoir définir des macros en asm aussi, non ?

Ce n'est pas très beau en effet, mais tu ne peux pas faire mieux. Tu remarqueras que j'ai mis la même chose dans l'exemple dans mon tutorial.

Ben ce n'est pas vraiment un hack... C'est exactement ce que fait la macro C aussi.

Normalement oui.

Les niveaux de gris ignorent complètement le PortSet (au contraire, on peut l'utiliser pour afficher dans un des plans de gris avec les fonctions de AMS), donc pas besoin de toucher aux interruptions.

Bah tigcclib et les autres libs s'adapteront, c'est pour ça qu'il ne faut pas coder l'adresse de l'écran en dur mais utiliser la variable qui va bien (LCD_MEM de mémoire)

(pour info l'adresse a déjà changé de la 92 à la 92II, puis encore pour la 92+ )

Sur 92 si je ne m'abuse, puis $4720 sur 92II.

C'est pour ça que les routines de gris de Backgammon pour Fargo sont patchées:

@@ -301,26 +231,26 @@
 | HW2: __gray3P_used_mem + 0xf00
 |------------------------------------------------------------------------------
 __gray3P_L_plane:
-       .long    0x00004c00
+       .long    tios__001c
 |------------------------------------------------------------------------------
 | pointer to medium plane
 | HW1: __gray3P_used_mem + 0xf00
 | HW2: __gray3P_used_mem + 0x1e00
 |------------------------------------------------------------------------------
 __gray3P_M_plane:
-       .long    0x00004c00
+       .long    tios__001c
 |------------------------------------------------------------------------------
 | pointer to dark plane (set by __gray3P_init_handler)
-| HW1: 0x4c00
+| HW1: tios__001c
 | HW2: same as __gray3P_used_mem
 |------------------------------------------------------------------------------
 __gray3P_D_plane:
-       .long    0x00004c00
+       .long    tios__001c
 |------------------------------------------------------------------------------
 | pointer to allocated memory ALIGNED to 8-byte boundary
 |------------------------------------------------------------------------------
 __gray3P_used_mem:
-       .long    0x00004c00
+       .long    tios__001c
 |------------------------------------------------------------------------------
 | This variable is very hard to describe. Indeed this isn't one variable,
 | but two variables combined in one.

 __gray3P_continue_cleanup:
-       lea      (__gray3P_L_plane,%pc),%a0  | restore plane pointers to 0x4c00 for sure
-       move.l   #0x04c00,(%a0)+
-       move.l   #0x04c00,(%a0)+
-       move.l   #0x04c00,(%a0)+
-       move.l   #0x04c00,(%a0)
+       lea      (__gray3P_L_plane,%pc),%a0  | restore plane pointers to tios__001c for sure
+       move.l   #tios__001c,(%a0)+
+       move.l   #tios__001c,(%a0)+
+       move.l   #tios__001c,(%a0)+
+       move.l   #tios__001c,(%a0)

parmi les patches effectués (j'ai aussi viré tout le code HW2 qui ne ferait que gaspiller de la place sur les TI-92).

Y'a le meme romcall que tios__001c en kernel. Donc si on programme en kernel, avec quelque chose qui le supporte, il suffira d'attendre la mise a jour du kernel. Troll powa!

TIGCC n'utilise pas et, à moins que l'adresse ne change vraiment, n'utilisera jamais ce RAM_CALL.