La HW3 qu'on craignait tellement va arriver! - Page 5

Bref c'est un coflit de personnalite. Pas si grave

HerveRV> tant que tu n'es pas bigleux, side déchire tout !

>je trouve ça trop con que je puisse pas y acceder sur ma calc, car je voudrais bien voir à quoi ça ressemble

Si effectivement tu as une ancienne version d'AMS, je te fais savoir que ta version d'AMS n'est pas compatible avec mon programme (et non l'inverse), sachant celà, TI s'est empressé de sortir une nouvelle version qui corrige le probleme, à savoir AMS 2.05, et il te suffit d'etre à jour pour pouvoir pleinement en profiter, comme le reste du monde

héhé
et puis, ROM2.05, c'est la plus compléte, il me semble...

Question de gout aussi.

Nitro, je t'ai déjà donné une fonction qui marche avec tous AMS et qui fait exactement la même chose que la fonction de AMS 2.05 que tu utilises. Donc, tu vires ton #define, tu mets ma fonction à la place et puis tu appuies sur [Ctrl]+[F9] (dans TIGCC IDE) et c'est bon.

arf...

>et puis tu appuies sur [Ctrl]+[F9] (dans TIGCC IDE) et c'est bon

Bah je n'ai pas TIGCC IDE donc je suis dans l'impossibilité de faire ce que tu me demandes... desolé
[edit]Edité par Nitro le 23-01-2002 à 20:31:58[/edit]

fainéant!

Nitro, ne fais pas semblant d'être con, tout le monde sait que tu ne l'es pas.

c vrai que dwnlder ide c long

Pas seulement ça. C'est que peu importe quel IDE (ou quel programme en ligne de commande) il utilise, il suffit qu'il choisisse la commande qui recompile la source. (Et il a très bien compris.)
[edit]Edité par Kevin Kofler le 23-01-2002 à 23:41:39[/edit]

d'un autre coté je le comprend, ya des bugs ds mon jeu qui prennent 5 min a corriger mais g la flemme de le faire

liquid> dans ce cas, on se comprend

La flemme est l'une des constantes de la communaute Ti

Mais non elle est pas constante puisqu'elle augmente chaque jour

mais un jour je les corrigerai

Moi par contre je sais pas

Je crois que j'ai réussi à localiser le port I/O de la Real Time Clock sur les calcs HW2. Il est protégé par la Protection de la flash, comme je le pensais. Toute les versions d'AMS et de boot l'ont jusqu'à maintenant ignoré, c'est pourquoi on a aucune information dessus.

Apparement il faut réussir à le réglé, car avec les tests que j'ai fait, le timer s'incrémente très très très lentement. Par ex. je l'ai initialisé hier soir à 23h, et aujourd'hui, à 16h, après que la calc est dormie pendant tout ce temps, le timer s'est incrémenté de 8 unités. Et après avoir fait un autre réglage tout à l'heure, il s'est incrémenté d'une unité en 3 heures.
Donc le truc, maintenant, c'est de réussir à régler son incrémentation.

Peut-être que je délire, aussi. En tout cas je connais pas beaucoup de ports qui ne peuvent être modifiés qu'en enlevevant la Protection flash, et qui s'incrémente tout seuls sans que l'AMS n'y accède, alors que la calc est éteinte.
Le truc pas pratique c'est qu'il faut que j'attende 6h entre chaque test pour avoir des résultats...

Leur système d'horloge est peut-être un système hybride... Peut-être qu'à chaque fois que le port timer flippe, ils remettent le compteur de l'AI3 à 0, puis comptent les AI3s jusqu'à la nouvelle incrémentation. Et l'heure affichée est la somme de la valeur du port timer et du compte de AI3s.

Il y a des ROM CALLS dans AMS 2.06 pour acceder à l'horloge tres facilement...

Aussi pour la règler?
Ça ferait encore une fonction du trap $B dont on pourrait abuser pour écrire en ROM.

Kevin c'est pas possible ton truc, puisque l'AI3 est désactivée quand la calto est éteinte. Donc comment tu veux compter le temps écoulé entre le dernier basculement de la RTC et l'allumage de la calto...

Oui, c'est vrai...
J'ai fait encore d'autre tests. Apparement le port est un word, qui est protégé en écriture par la protection flash, et dont l'octet de poids fort est protégé en lecture par la protection flash. L'octet de poids faible peut être lu sans problème. Une écriture à ce port permet de régler la valeur initiliale du timer, et de forcer le redémarrage du chrono. Le timer s'incrémente une fois toute les 2h15 je crois (j'aurais les résulats d'un test plus préçis tout à l'heure). Tout le word est incrémenté, c'est à dire que $01FF par ex. passera à $0200. Mais seul le deuxième octet peut être lu sans déprotéger la flash.

hum ...
Tu as réussi à lire le premier octet pour voir à quoi il correspondrait ?

Comment as-tu fait pour découvrir ce port ?
Et pour le déprotéger ?

Tu as réussi à lire le premier octet pour voir à quoi il correspondrait ?
Je disais que le premier octet joué exactement le même rôle que le deuxième, sauf que c'est l'octet de poids fort du timer. Donc quand le 2ème octet passe à 0, le premier s'incrémente de 1.

Comment as-tu fait pour découvrir ce port ?
Et pour le déprotéger ?
J'utilise mes routines de déprotection de la flash. J'ai bidouillé, comme d'habitude.

Le timer s'incrément finalement toutes les 2h 16min 30s environ.

S'il y en avait un deuxième planqué à côté, avec une fréquence différente, ça te permettrait une plus grande précision.

>Thibaut: Kevin c'est pas possible ton truc, puisque l'AI3 est désactivée quand la calto est éteinte. Donc comment tu veux compter le temps écoulé entre le dernier basculement de la RTC et l'allumage de la calto...

En mettant le port à $600005 à 4 plutôt qu'à 0, ce qui fait que la calculatrice se réveille quand l'AI3 se produit.

C'est probablement plutôt 2h 16min 32s = 8192 s.
L'adresse du port, c'est quoi? $700014? Si oui, $700016 et les 6 bits de poids fort de $700017 ne sont ps documentés non plus. Il y aurait la place pour 16384 possibilités, donc une précision à la 1/2s...