interrupt, gray, keyboard, et tout le bordel - Page 2

en gros, je suis obligé d'ecrire dans 2tableaux virtuelles et de recopier tout dans chacun des buffers , ca pu.

we, j'vais peut etre pas utiliser genlib pour une fonction dans un pov tetris...

j'ai un nouveau probleme, j'ai un comeur sur ai5, et parfois il semble que l'inerrupt installée se desinstalle toue seule¿¿¿¿
vous savez d'ou ca peut venir????

Puisque ce n'est pas normal, je pencherais pour une erreur dans ton code. Peut-être que tu remets le vieux handler par erreur ?

ouais effectivement ct une erreur dans mon code (le compteur pouvait passer dans les negatifs parfois, et la ca chiait).

Sinon, g toujours mon probleme pour utiliser des fonctions de tigcc.a
C'est a la compilation que ca foire, car l'assembleur ne reconnait pas les fonctoin appelee. (ex bsr GrayOn).

Y'aurait pas une fonction que j'aurais par meghard decochée?

Si tu utilises la ligne de commande et que tu ne lui dis pas qu'il faut utiliser tigcc.a, ça n'ira pas. Ca peut aussi foirer car l'option bizarre qui fait qu'on ne veut pas utiliser tigcc.a est cochée dans les options du projet...
Voir les batches de build d'ExtGraph dans /src/demos pour des exemples utilisant extgraph.a et tilemap.a.

bon, ca y es g trouve, ct que j'av viré des opions de l'assembleur (-g,-t ou qqchose comme ca)

voila, merci quand meme, du coup les grays marchent nickel, et j'ai gagné 2ko dans mon prog. wahoo.

sinon, je viens de faire une routine pour transformer un chiffre en base 10 afin de l'afficher (sur 7digit max).
vous pouvez me dire ce que vous en pensez (hisoire de progresser un peu, car j'arrive a faire des rucws qui marchen, mais je sens que ca pourrait etre largemen optimise) a mon avis c tres pourri et je sais meme pas si ca marche, mais bon
sinmon, ca m'interresserai de voir ce genre de rouine avec un belle opimisation 8si vous l'avez fai)

edit, bon en le voyan affiché g vu que ct nimp... mais bon c pas grave
Afficher_Chiffre

 lea	buffer(pc),a0
 moveq	#7,d2	
 \loop
 moveq	d2,d3
 moveq	#1,d4
 \mult:
 move.l	d4,d1
 lsl	d2,d4
 add.l	d1,d4	
 add.l	d1,d4	
 dbra	d3,\mult
 move.l	d0,d1
 divu.l	d4,d1
 move.b	d0,(a0)+
 mulu.l	d4,d1
 sub.l	d1,d0
 dbra	d2,\loop
 lea	buffer(pc),a0
 moveq	#6,d1	
 \loop1
 move	#$ff,(a0)+
 tst.l	(a0)
 dbeq	d1,\loop1
 rts

 buffer:	ds.b	8

Que veux-tu, c'est le vieux A68k pourri qui accepte des instructions invalides et qui code n'importe quoi...

> sinon, je viens de faire une routine pour transformer un chiffre en base 10 afin de l'afficher (sur 7digit max).
Parcours la page http://tict.ticalc.org à la recherche de "fastitoa", qui aurait dû être intégrée à TIGCCLIB, mais maintenant que Kevin décide de tout, elles ne le seront jamais: c'est une réinvention de la roue qui va plus vite mais qui bouffe de la place (encore que... la convention d'appel est plus efficace, donc si elle est utilisée des dizaines de fois, ça doit être plus petit).

g pas trouvé fastioa sur le site de la tict, sinon, comme je vous l'ai dit j'av pas test'e (car pas de tigcc sur le pc) donc c normal si ca compile pas , ct plutot au niveaqu de l'algo, que je me demandais...

Afficher_Chiffre 
 
 lea	buffer(pc),a0 
 moveq	#7,d2	 ;lit 8 chiffre
 \loop 
 moveq	d2,d3 
 moveq	#1,d4 
 \mult: 
 move.l	d4,d1 
 lsl	d2,d4 
 add.l	d1,d4	 
 add.l	d1,d4	 ;10*
 dbra	d3,\mult      ;d4=10exp(d2)
 move.l	d0,d1 
 divu.l	d4,d1          ;divise d0 par d4- d1 contient le bon digit
 move.b	d0,(a0)+     ;stocke dans le buffer
 mulu.l	d4,d1          
 sub.l	d1,d0          ;enleve les dizaine centaine millier... 
 dbra	d2,\loop       ;passe au digit suivant
 lea	buffer(pc),a0 
 moveq	#6,d1	 
 \loop1        ;Bon la je met juste $FF c pour l'affichage, pour tous les premier 0 
 move.b	#$ff,(a0)+ 
 tst.l	(a0) 
 dbeq	d1,\loop1 
 rts 
 
 buffer:	ds.b	8 

> g pas trouvé fastioa sur le site de la tict,
"fastitoa". Il suffit de faire une recherche en texte brut pour le trouver, sur la page de news http://tict.ticalc.org

c'est quoi la limite divu/divs du chiffre le plus grand qu'on peut diviser.

Je penais que ct %FFFF mais apparement c'est plus petit.
comment on peut fair sinon?


Ah je viens de voir que y'a le romcall suivant qui fait ca:
ROM Call 0x53

Je l'appele comme ca
move.l d0,-(a7)
lea format(pc),a0
move.l a0,-(a7)
lea buffer(pc),a0
move.l a0,-(a7)
move.l $53*4(a5),a0 ;calcule l'adresse de la fonction et la place en a4
jsr (a0)


buffer: ds.b 24
format: dc.b '%','d','/0'

ROM_CALL_53 = sprintf. Moins efficace, en taille et en vitesse, que fastitoa: c'est bien pour ça que fastitoa existe...

>c'est quoi la limite divu/divs du chiffre le plus grand qu'on peut diviser.

diviu/divs divise un 32 bits par un 16 bits A LA CONDITION que le quotient soit sur 16 bits.

ok, bon bah c'est parfais merci, ct le diviseur qui etait trop grand en fait vu que je divisais par 100000.
je vais diviser par 100puis par 1000 ca sera mieux ou utiliser fastitoa (mais le probleme c'est que y'a une limite de 99999 d'apres ce que j'ai vu en parcourant le code, non ? Sinon, je vois pas en quoi une romcall peut etre plus longue qu'une fonction qu'on rajoute????

[cross]

multiplie par une constante, plutot que de diviser ^^ (ca te permettra de faire des divisions 32bit->32bit bien plus rapidement)
sinon oui si la vitesse ne t'intéresse pas sprintf doit etre plus petit je pense...

Ou si ti veux quelque chose de precis.

tout de maniere, je suis partie pour faire ma routine, sinon pollux, je n'ai pas bien compris ce que tu m'a dit. Comment compte tu diviser 32 bit/32bits

dans une certaine plage de valeurs, x/10 = (ceil(65536.0/10) * x) >> 16 (on peut aussi se débrouiller pour avoir un truc qui marche sur toute la plage de valeurs de départ, je crois que pour les divisions par 5 ca marche)
mais bon si tu sais que tes nombres sont assez petits ou que tu veux pas une vitesse extraordinaire, pas la peine de se prendre la tete ^^

clair ca a l'air complexe ton truc , j'ai pas besoin d'une vitesse extremiste... mon probleme c'est que je divisais par 100000 et que donc ca couillait, donc je vais faire en 2 etapes: Divise/100 /1000... Ca devrait marcher nickel et je test ce soir

ca ne marche nickel QUE si le résultat tient dans un word (ce qui ne sera pas le cas si tu veux diviser un nombre 32 bits quelconque par 100)
mais si t'as pas du tout besoin de vitesse, tu peux utiliser _du32u32 (ou un truc comme ca)