Si ton programme est tel que tu l'as écrit, c'est normal que ça foire, parce qu'après la romcall bcall(_vputs), il exécute la chaîne de caractère :lol
(met un bcall(_getkey) puis un ret )
sinon un conseil pour optimiser, charge les coordonnée comme ceci:
ld de,$0505
ld (pencol),de
si tu avais de=$1020 le texte a pour coordonnées y=$10 et x=$20
joe14 Le 02/07/2003 à 15:44 Mieux vaut :
ld hl,$0505
ld (pencol),hl
Tu gagnes un octet en taille et quatre cycles.
Par contre, je vois pas le problème : t'as bien mis un espace entre la marge et .db ? Quest-ce qui suit le 0 ?
Ce serait pas un truc du genre :
inc h
dec h
en fait moi j'utilise les coordonnées dans 'de' pour faire une routine où hl est la chaîne à afficher et de les coordonnées où l'afficher.
je crois pas qu'un espace avant le .db soit nécessaire, ça doit être autre chose.
Est-ce que la calculatrice est plantée après l'éxecution du programme ?
joe14 Le 04/07/2003 à 12:56 Donc, à priori, le bug se trouve dans la traduction du texte par tasm. C'est bizarre, parce que normalement, pour les lettres, TI utilise la table ASCII.
joe14 Le 06/07/2003 à 22:40 En ce cas, il na faudrait évidemment pas mettre les guillemets.
moi aussi j'ai un problème assez bizarre avec mon compilateur.
par exemple j'écris:
.db $B7
et en compilant il m'écrit une autre valeur ???????
j'ai mis des heures à trouver où était l'erreur, mais j'ai fini par trouver avec un éditeur héxadécimal. Le problème survient avec les nombre héxadécimal qui commence par 'B', incompréhensible :roll:
