Bah, je ne me suis pas encore mis à reproduire et trouver la cause du problème sur émulateur, même si j'ai vérifié la marche à suivre tout à l'heure, purement on-calc, sur ma 89 HW2 AMS 2.05...
J'aurai peut-être le temps de regarder ce que TIEmu fait ce soir ou demain matin - mais de toute façon, il faudra bien que je décrive tôt ou tard ce que j'ai fait, donc allons-y
L'auto power down utilise l'AUTO_INT_5, comme tous les timers. Le but est de comparer sa fréquence à une fréquence qu'on sait précise (sur HW2), celle de l'AUTO_INT_3.
L'idée est d'utiliser une version d'AMS trop vieille pour réactiver l'AUTO_INT_3 après une extinction (et suffisamment récente pour que l'AUTO_INT_3 ait un handler qui incrémente un compteur, sinon il faut faire un tel handler nous-mêmes). AMS 2.05, et il me semble tous les AMS 2.00-2.05, remplissent ces deux conditions.
Sur 89 AMS 2.05, le handler d'AUTO_INT_3 est à 222026, et il ne fait que
addq.l #1, 0x5BFC.w
rte
Il faut donc
1) activer l'AUTO_INT_3 en armant le bit qui va bien. Exec "08f90002006000154e750000", c'est à dire
bset.b #2, 0x600015;
rts;
fait l'affaire.
2) se débrouiller à avoir la valeur du compteur d'exécutions du handler d'AUTO_INT_3, à l'adresse 0x5BFC sur 89 AMS 2.05. Pour ça, j'utilise tthdex-internal-frozen-in-time, [APPS] 5 B F C (dump de 60 octets commençant à l'adresse 5BFC), mais on peut faire ça avec sprintf+DrawStr, et utiliser GKeyIn pour attendre;
3) laisser la calculette s'éteindre par APD, ce qui a pour effet de désactiver l'AUTO_INT_3;
4) rallumer la calculette, l'AUTO_INT_3 n'est pas réactivée par AMS 2.05 lors du power on;
5) consulter la valeur du compteur d'exécutions du handler d'AUTO_INT_3;
6) faire la différence des valeurs du compteur, pour savoir quelle a été la durée.
Cette méthode indique qu'avec le réglage par défaut du taux d'AUTO_INT_5 effectué par AMS sur HW2+, l'auto power down nécessite environ 311 secondes au lieu de 300. 311/300 est proche du ratio 20 (fréquence attendue) / 19.32 (fréquence réelle).