* ma méthode ne permet pas de détecter un événement qui fausse dans les mêmes proportions les taux d'AUTO_INT_3 et AUTO_INT_5 (par exemple, un déréglement d'OSC2). J'imaginais que l'AUTO_INT_3 est implémentée avec n'importe quel timer fourni par l'OS / la librairie (avec lequel il y a probablement moyen de faire un timer précis 1 Hz - du moins sous *nix), et que l'AUTO_INT_5 est implémentée autrement, je ne sais pas comment. Mais après tout, peut-être n'est-ce pas fait comme ça, je n'en sais rien...
* ma méthode ne permet évidemment pas non plus de déclencher un problème qui ne se manifeste pas quand l'AUTO_INT_3 est activée,
* je n'avais pas le temps d'attendre 4 * 5 minutes ce matin, parce qu'il fallait que je parte. J'ai donc désactivé le "Vitesse nominale", ce qui rend nettement plus rapide l'APD. Mais par conséquent, c'était plus difficile de se rendre compte s'il y avait une différence visible de temps d'APD...
Ah, un autre problème (
) que j'ai vu ce matin, en désactivant "Vitesse nominale": la consommation de ressources processeur de TIEmu est élevée (100% d'un deux coeurs de mon Core 2 Duo à 2 GHz...). Mais après tout, c'est courant pour les émulateurs, et VTI n'est pas un bon point de comparaison, puisque l'émulation de processeur par TIEmu est nettement meilleure que celle de VTI: par exemple, émulation du petit pipeline du 68000, ce qui permet à TIEmu d'exécuter correctement un des chausse-trappe anti-VTI de HW3Patch.
Donc je ne râle pas pour la consommation de ressources processeur quand la calculette est allumée. Par contre, cette consommation se maintient quand la calculette est éteinte...
C'est TRES vilain d'occuper 100% d'un coeur de processeur quand on ne fait rien
