trap #4 - Page 2

moi j'avais eu le même prob, mais mon prog n'était pas en niveau de gris.
Donc cela ne vient pas de là. Pour info, ca me faisait ce bug sur ti89 HW1 Rom1

ma source est tres (trop ??) longue pour etre postee.
De lpus je ne pense vraiment po faire qqchose de special
enfin si qqn la veut, qu'il me la demande , je lui enverrai ce week-end

Pas le temps.

c po super urgent

Pas besoin de la source finalement, j'ai trouvé d'où vient le problème. Le trap #4 réinitialise les bus waitstates bizarrement, et ça ralentit un peu la calc. Quand on utilise l'AMS normalement, ça ne se voit pas car la routine de détection de l'état des piles de l'AI5, qui se lance toutes les secondes environ, remettra les valeurs du port en place. Mais dans un prog en asm, l'int 5 est détournée, et on garde les mauvais waitestates.

Donc pour éteindre la calc dans un prog en asm qui détourne l'int5, il faut tout simplement faire :

	trap 	#4
	move.b	#-1,$600003

Je n'ai toujours pas réussi à faire un programme moi-même qui fait apparaître le problème. Donc je suis toujours prenneur d'un petit programme qui isole le bug.

, ca marche nickel now
c bizarre que t'arrive po à le reproduire
je t'envoie la source

Merci, je regarderais ça dès que je peux.

Une optimisation que tu peux faire : pour tout appel de rom call ou de fonction de librairie de plus de 2 fois, utilise ça plutôt:
Définit une sous routine appelant la rom call avec un jmp :
HeapAlloc : jmp doorsos::HeapAlloc
Et à chaque appel de la rom call, bsr HeapAlloc. Comme ça on évite plein de relogement inutile. Ca marche aussi avec les libs.

Et les variables en BSS ça mange quand même beaucoup de mémoire quand on y accède...

ExtendeD
a écrit : Et les variables en BSS ça mange quand même beaucoup de mémoire quand on y accède...

Et on se demande pourquoi les auteurs des kernels ont mis ce feature stupide vu comment c'est inefficace. C'est tellement plus propre et plus efficace d'utiliser directement les ROM_CALLs appropriés pour allouer de la mémoire.

ExtendeD
a écrit : Le trap #4 réinitialise les bus waitstates bizarrement, et ça ralentit un peu la calc. Quand on utilise l'AMS normalement, ça ne se voit pas car la routine de détection de l'état des piles de l'AI5, qui se lance toutes les secondes environ, remettra les valeurs du port en place.

C'est peut-etre fait expres pour éviter d'aller trop vite quand la calc se rallume pour laisser le temps au hardware et à l'écran de stabiliser ?
(enfin moi j'y connais rien, c'est juste une idée)

Peut-être, aucune idée. Il vaudrait mieux le modifier après un petit délai?
La doc des ports de Johan Eilert dit The TI89 hardware needs no waitstates. AMS messes with this port on startup for compatibility with the TI92.

Kevin Kofler a écrit :
Et on se demande pourquoi les auteurs des kernels ont mis ce feature stupide vu comment c'est inefficace. C'est tellement plus propre et plus efficace d'utiliser directement les ROM_CALLs appropriés pour allouer de la mémoire.

Pas plus qu'acceder a une variable globale dans un fichier de 60K.