ESC+ON - Page 1

je crois que la touche ON a sa propre auto int.

ben on doit avoir un handler dessus, et quand il est appelé, on regarde si ESC est appuyé et si oui, on kille le programme, non?

bahvala

$59!

Oui, on peut utiliser sensiblement moins que $58.
Dans certains cas, ça gagne en vitesse, mais dans d'autres, c'est inutile: si tu veux faire des choses précises à une pression de touche près, tu es de toute façon obligé de rajouter des attentes d'une façon ou d'une autre, pour ne pas être embêté par les rebonds. Entre autres, TI-Chess et plusieurs demos d'ExtGraph le font.

Bon, pour information et si je ne dis pas de bêtise, c'est la valeur qui est utilisée par AMS, donc il a fait pareil (ou alors je dis n'importe quoi, mais il me semble me souvenir que PpHd m'avait parlé de ça, une fois...)

12 nops suffisent a priori. (D'ailleurs, c'étaient 10 sur HW1, donc pas mal de programmes ont dus être corrigés à la sortie des HW2 pour attendre 12 nops au lieu de 10. La HW2 est plus rapide d'un facteur 6/5 et ça se reflète ici. 12 nops ont l'air d'être toujours suffisants sur HW4 d'ailleurs, jamais eu un retour différent, et de toute façon je ne suis plus convaincu que les HW4 sont vraiment plus rapides, je pense que c'était une erreur de mesure, comparer une HW3 pleine de handles avec une HW4 vide, avec un bench qui dépend de la vitesse des allocations.)

ou tout simplement muls #42,d0 (disclaimer : non testé)

pour ./6 on peut encore gagner 2 octets en faisant

	moveq	#KEY_ESC_ROW,d0
	move.w	d0,(a2)	; Write mask (int1 & 5 can't be called  ;)  
	divu	d0,d0

(edit : hmmf en fait sur 92 KEY_ESC_ROW tient pas dans un moveq, enfin de toute façon c'est idiot de chercher à gagner 2 octets là-dessus alors que le fait d'avoir a2 constamment à 0x600018 est très sous-optimal ^^)

raison de plus

Pollux (./14) :
ou tout simplement muls #42,d0 (disclaimer : non testé)

Comme quoi ce nombre est vraiment la réponse à tout.