jsr ds une Auto_int = bug - Page 1

salut !
bon mon problème est que j'ai un programme qui dévit l'Autoint1 pour y executer sa routine, puis la redirige vers l'adresse de la routine de uniOS.
( c un peu cô un tsr )
la calc se fige sistématiquement qd j'y fait appelle à une fonction du tios : DrawStr.
J'ai passé déjà beaucoup de tps dessu, à serner le problème, et c assûrément l'appel de la fonction : cô c en nostub, j'utilise jsr pour jumper vers le tios, et la calc n'en retourne pas.....
ce srais vachement sympa de maider sur ce cou là ....
merci

Tu sauvegarde/restaures bien tous les registres détruits (sachant que les fonctions du TIOS détruisent d0-d2/a0-a1) ?

Bien vu!

ouasi : voici le l'ISR pour l'auto int 1 (routine que j'ai pris le soit de copier en mem statique avec HeapAllocHigh :

movem.l d0-d7/a0-a6,-(a7)
move.l $c8,a5
move.w #4,-(a7)
pea hello(pc)
clr.l -(a7)
move.l $6A4(a5),a0
jsr (a0)
lea 10(a7),a7
movem.l (a7)+,d0-d7/a0-a6

jmp $03E106

voila : j'imagine que g fait LA faute de newbiz mais bon.... chuis en train d'apprendre !

pourquoi lea 10(a7),a7 ?
moi j'aurais mis 8 (4 pour le .w + 4 pour le .l !)
mais bon ...

oups j'avais pas vus le pea

pas grave... et sinon, sa dit qqchose à qq'un ?????

ce que tu peu faire pour trouver le bug c le debugger avec le VTI !et tu regarde l'tat de la pile,des variables ,...

yepp, si vti n'avait pas un bug qui fait que souvent le debugeur ne marche pas correctement

C'est sûrement parce qu'un appel de rom call ne se fait jamais a partir de l'int1 : elle est à 200Hz sur HW2, et les rom calls ne sont pas toujours très rapides (surtout DrawStr). Ca fait qu'à chaque fois que l'int1 détournée et la vraie int1 se sont executées, elles se rééxécutent tout de suite à près car le 1/200ème de seconde de délai s'est écoulé. Donc seules les interruptions sont executées, et l'OS ne tourne plus...
Utilise plutôt l'int5 qui est par défaut à 20Hz environ.
Mais peut-être que c autre chose qui bug...

Le jmp [cste] pour executer l'ancien int ca se fait pas trop parce que c incompatible avec les différentes versions d'AMS, et ca ne permet pas d'installer plusieurs tsr en même temps.
Sauve avant d'installer ton prog ce qui à $64 (dans old_int par ex), et fait:
move.l old_int(pc),-(a7)
rts
(on ne peux pas utiliser de jmp parce qu'il faudrait sqatter un registre qu'on ne pourrait pas remettre a sa valeur initiale apres le saut.

freka: le rte sera executé par l'ancien int seulement, l'int détourné de doit faire qu'un rts parce qu'on a besoin de rester en mode superviseur pour executer l'ancien int.

yyeeppp !!
merci beaucoup, avec l'auto in 5 ca marche ss problème, c vachement sympa !
jvais voir à améliorer le reste (avec jmp & Co )

frekazoid>desole je n'ai pas l'habitude d'n piler sur la pile autre que avec movem

Si tu utilises des ROM_CALLs et/ou des librairies statiques écrites en C (ce que je te conseille fortement), tu devras forcément passer par là à un moment.
[edit]Edité par Kevin Kofler le 18-10-2001 à 21:16:35[/edit]

a mon avis je n'ai pas encore le niveau pour bien utiliser tous ca !
donc je vais continuer un peu comme ca puis plustard ...
ca sert a koi d'utiliser des librairie static ecrite en C (puisque que tu me le conseille )?

Qu'il y a des routines de sprites rapides dans ExtGraph (et TIGCCLIB) qu'il n'y a pas dans la ROM, et qu'on peut donc se passer des librairies dynamiques en utilisant ces librairies statiques. Or, certaines fonctions de ExtGraph et TIGCCLIB sont écrites en C, et d'autres en assembleur, mais en utilisant la convention d'appel C pour qu'on puisse les utiliser en C.

cool j'avais le même bug,mais je m'étais jamais trop cassé la tête dessus.

remerci ExtendeD

et sinon, y faut faire quoi sur HW2 pour afficher des sprites en mouvement (assez rapide : l'abscisse est incrémentée de par ex 2 pxl/sec ) sans faire baver l'écran qui fait alors un grosse trainée sur au moin la longueur de sprite, qui devient très flou ?

au fait, pour la vitesse d'execution ds la ROM : comment y fait le ti-os ? il copie les routines en RAM ?

Non, je voulais dire, en disant que les rom calls sont lentes, qu'elles étaient programmées en C et que parfois elles étaient très mal optimisées en vitesses, donc elle mettaient du temps a s'executer. Les rom calls s'executent en rom.

ah oK merci
et pour l'écran ? y a un truc pour remedier à la bavure ?

essaye de les affichés puis de les effacés (avec son mask c'est mieux) je pense que cela fera disparaître la bavure laissé par le sprite