150

Martial Demolins (./149) :
Par contre, il y a un "osd" ou truc du genre qui passe sont temps à dire "use mouse or press a key" quand on survole l'ému, j'avais pas remarqué que c'était aussi gros avant.

C'est l'implémentation des tooltips qui a changé entre Fedora 7 et 8.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

151

Martial Demolins (./149) :
Par contre, il y a un "osd" ou truc du genre qui passe sont temps à dire "use mouse or press a key" quand on survole l'ému, j'avais pas remarqué que c'était aussi gros avant.


Je l'ai remarqué hier aussi alors que je ne l'avais jamais vu. Je peux l'enlever si personne n'est contre.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

152

153

Dans la fenêtre Memory, le dump ASCII est écrit avec une police non monospaced. Un défilement, suivant ce qui est écrit, a pour effet de souvent redimensionner la fenêtre vers la droite, presque pixel par pixel.
(J'utilise toujours une version sans dock, peut-être que ça a été corrigé depuis).

(Au passage: le nouveau thème SimplyMEPIS, où ils ont mis un look KDE aux applications GTK, est marrant grin)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

154

Lionel Debroux (./153) :
Dans la fenêtre Memory, le dump ASCII est écrit avec une police non monospaced. Un défilement, suivant ce qui est écrit, a pour effet de souvent redimensionner la fenêtre vers la droite, presque pixel par pixel.
(J'utilise toujours une version sans dock, peut-être que ça a été corrigé depuis).

On peut considérer que c'est corrigé si tu utilise une police courier dans le 'nouveau' menu police.

Martial => tooltip supprimé.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

155

156

Martial Demolins (./155) :
- La police est à "default", et la police utilisée pour l'affichage de la RAM est à chasse infixée, ce qui est gênant pour se repérer (à quoi correspond tel octet?).

J'ai restauré le comportement d'origine, ç-à-d police courier dans cette fenêtre. Dois-je faire de même pour la fenêtre Registers ?

- L'aperçu (la phrase) dans la fenêtre de la police est illisible (que des carré) dans la majorité des fontes, et affichée avec des caractères grecs ou autre dans quelques

Jamais eu ce problème.

- Le changements de la fonte n'a aucun effet (taille + type de fonte). Peut-être normal depuis le changement de fenêtrage?

Il faut relancer le debugger. C'est corrigé par un refresh global.

Tout se passe en effet comme si on était dans plusieurs fenêtres séparée

C'est effectivement le cas ce qui oblige à changer le focus à l'aide de la souris comme tu le soulignes. Je peux pas faire autrement (dans l'immédiat) à moins de remettre à plat tout les acc. keys. En effet, certaines touches se recoupent (F1 dans mem et F1 dans code par exemple mais il y en a plein d'autres...)

La touche F1 fait déconner quand on est dans la partie source,

Cette touche positionne normalement le PC sur la ligne d'après et la sélection aussi. C'était une feature request de pphd ou lionel, me rappelle plus. En tout cas, j'ai vérifié, elle a le comportement attendu.

Pourrai-t-on avoir les raccourcis Alt (ou Ctrl) + lettre du flag == toggle du flag?

Fait avec Alt + T/S/X/N/Z/V/C.

Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

157

158


Le changement de fonte marche en effet après relance, sauf pour les registres et les breakpoints. Normal?
En tout cas, la chasse infixée pour les registres n'est pas terrible en effet...

Les deux sont fixés.

Par contre, ça ne réduit pas la taille de la fenêtre, malheureusement grin (mais c'est déjà 100 fois mieux!)

La police de la fenêtre register est presque déjà au minimum.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

159

roms (./156) :
Cette touche positionne normalement le PC sur la ligne d'après et la sélection aussi. C'était une feature request de pphd ou lionel, me rappelle plus. En tout cas, j'ai vérifié, elle a le comportement attendu.


Pas de moi. Il me convenait tout à fait ton emu smile

160

161

Je ne me souviens pas non plus d'avoir demandé ça, mais je peux me tromper smile

[EDIT:
@Martial: ?
]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

162

Martial Demolins (./160) :

Dis que nos feature request sont de la merde aussi hein mod.gif


Si tu le souhaites, pas de problème.

163

164

Vos feature request, c'est de la MEERRDDEEE !!!

165

On sent une excitation presque palpable chez certains... Noël approcherait-il ?

Sinon, y a-t-il d'autres remarques ? J'aimerais bien releaser tilp et tiemu avant la fin de l'année...
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

166

avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

167

168

Pour le ./166, je m'en occuppe actuellement sur le forum de TIGCC.
Pour le ./157, as-tu une idée du problème ? Kevin, qu'en penses-tu ?

Résoudre le ./166 semble être dans mes compétences, pour le ./157, je suis moins sûr...
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

169

Je ne sais pas ce que cause le problème du ./157.

Sinon, autre petit ennui: quand on remonte dans la fenêtre désassembleur, on se tape un bip à chaque ligne qu'on remonte. sad (tiemu3-3.02-0.3.20071215test3)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

170

Est-ce qu'AMS touche à la valeur de 0x600017 dans la séquence d'auto power down (ça m'étonnerait) ?
Est-ce que le saved state contient la valeur de 0x600017 ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

171

Lionel Debroux (./170) :
Est-ce qu'AMS touche à la valeur de 0x600017 dans la séquence d'auto power down (ça m'étonnerait) ?
Est-ce que le saved state contient la valeur de 0x600017 ?

AMS ne touche pas en 0x600017. Le saved state contient la valeur de tous les ports HW. Seul les ports de la RTC sont recalculés.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

172

173

J'essaierai de le reproduire sur 89 HW2 tournant AMS 2.05. Je pense faire comme sur ma 89 HW2 AMS 2.05 réelle: activer la RTC et utiliser tthdex (qui ne fonctionne pas sous AMS 2.08+...) pour regarder la différence des valeurs de la variable incrémentée à 1 Hz par le handler de l'AUTO_INT_3.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

174

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 smile

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).
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

175

Je n'utilise pas la dernière version de TIEmu, mais je n'arrive pas à reproduire ce que Martial décrit en ./157:
Il y a encore le problème de la fréquence de l'Int5 qui est mal restaurée (trop rapide) quand on rallume la calc après une extinction par APD (AMS et PedroM, même vierges).


J'ai fait la manip deux fois, et que ce soit avant ou après la première extinction par APD, le temps d'APD, mesuré en ticks d'AUTO_INT_3, est de 310 ou 311 secondes.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

176

Lionel: merci pour ton aide.
Martial: étant donné que tu es le seul à avoir ce bug, tu veux pas essayer de voir ce qui coince ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

177

Si Martial arrive à le reproduire de manière systématique, et pas moi, c'est peut-être ma méthode, ou son exécution (voir le troisième point), qui est fausse...

* 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 ( grin ) 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... mourn
C'est TRES vilain d'occuper 100% d'un coeur de processeur quand on ne fait rien embarrassed
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

178

179

> Je vois pas ce que viens faire l'apd là-dedans, je parle de la vitesse de clignotement du curseur. confus
Vu que l'APD et le clignotement du curseur sont tous deux basés sur l'AI5 (il me semble), c'est pareil wink

Je peux essayer ce que tu proposes, c'est effectivement plus simple que ce que j'ai fait ^^

[EDIT: non, que ce soit avec 89T PedroM, avec un ROM dump 89 AMS 2.05 enrichi par la Certificate de ma calculette, ou avec 89T AMS 3.10, je ne vois pas de différence entre avant et après APD. Et j'ai redémarré l'émulateur entre chaque test sur un coupe HW+OS différent. Deux tests avec "Vitesse nominale" activé, un test sans.
Je tourne SimplyMEPIS 7.0 avec kernel 2.6.22.14, libc6 2.3, sur un Core 2 Duo 2 GHz.
]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

180

Lionel Debroux (./177) :
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...

Pour ceux qui veulent voir comment est géré les auto-ints harware sur TiEmu, ils peuvent regarder la fonction hw_update() sur http://svn.tilp.info/cgi-bin/viewcvs.cgi/tiemu/trunk/src/core/ti_hw/hw.c?rev=2744&root=tiemu&view=auto.
C'est commenté à gogo donc n'importe qui peut comprendre.

C'est TRES vilain d'occuper 100% d'un coeur de processeur quand on ne fait rien embarrassed


A priori, je suis d'accord mais une TI peut être réveillée sur n'importe quelle interruption; TiEmu n'a pas cette capacité: je suis bien obligé de scruter des évènements (ie hw_update()) pour le réveil. Je vais quand même voir ce que je peux faire à ce niveau...
Pour faciliter le debug, quelqu'un peut me dire où je peux réduire la valeur de l'APD ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"