utiliser plus qu'un timer personnalisé - Page 1

Salut à tous,
j'ai juste une petite question, j'ai vu dans la doc qu'il y a un timer personnalisable(USER_TIMER).. Le problème c'est que j'aurais besoin de quelques timers de plus (3 ou 4) .. est-ce que c'est possible sans toucher aux times systèmes (APD etc ..)
@+ et merci

Pourquoi as-tu besoin de 4 timers ? Tu ne peux pas compter différentes fréquences mais à partir d'un seul timer (le 6, USER_TIMER par exemple) ?

Ou tu te bases simplement sur le 1

Ah bon, comment peut-on compter 4 fréquences différentes à partir d'un seul timer ?

Bah il suffit que tu déclare 4 variables, que tu incrémente tous les X tics du compteur. Par exemple un timer1 qui s'incrémente tous les 2 tics, un timer2 qui s'incrémente tous les 3 tics, un timer3 qui s'incrémente tous les 5 tics et un timer4 tous les 7.

Ce n'est qu'un exemple, et en plus c'est loin d'être la solution la plus optimisée. Mais ça devrait résoudre ton problème ?
(je ne vois pas ce qu'apportent de plus 4 "vrais" timers différents)

> et en plus c'est loin d'être la solution la plus optimisée.
En effet. La très lente divu est utilisée pour faire les modulos, à moins que la variable soit incrémentée tous les 2^n-1 ticks (and est alors utilisable)..

4 "vrais" timers différents n'apportent en effet pas grand chose; et il n'est pas sûr qu'il soit possible d'utiliser 4 timers à la fois sur toutes les versions d'AMS.
Utiliser 3 timers est possible pour AMS < 2.04, et c'est en principe un maximum pour être sûr de ne pas interférer avec le système, sur toutes les versions de système.
En utiliser 4 ne me paraît propre que sur AMS 2.07 et plus (en utilisant de manière détournée le timer 8, BP_TIMER, si c'est autorisé). Détourner le timer 7 qui n'existe que sur AMS >= 2.04, et qui sert au test des batteries par l'AUTO_INT_5, n'est pas propre.

En effet. La très lente divu est utilisée pour faire les modulos, à moins que la variable soit incrémentée tous les 2^n-1 ticks (and est alors utilisable)..

Qui te parles de ça ? je pensais tout simplement à faire :

if (!(timer & 0b11)) incremente(timer1);
if (!(timer & 0b111)) incremente (timer2);

etc... avec différentes valeurs on a différentes fréquences.

Ben oui, mais on n'a pas un choix très important de fréquences différentes, comme l'a précisé XDanger.

Ah oui il l'avait dit effectivement... Bah c'est mieux que rien.

heurf, mais si, sur 395Hz, on peut faire du 1Hz

L'AUTO_INT_5 ne fait pas 395 Hz par défaut (il est possible qu'elle les fasse, mais il faut bidouiller les deux ports). c'est l'AUTO_INT_1, et seulement sur HW1; sur HW2, c'est 256 Hz.

Et je n'ai pas répondu à la question, d'ailleurs:
"besoin de quelques timers de plus (3 ou 4) .. est-ce que c'est possible sans toucher aux times systèmes (APD etc ..) "
Si tu ne veux toucher à aucun timer qui soit utilisé par une quelconque fonction du système, tu ne peux, à ma connaissance, utiliser que les timer 1 et 6. Mais tu peux détourner le 2 si tu te moques de l'APD, le 3 si tu te moques du link, le 5 si tu n'appelles pas les fonctions BASIC qui l'utilisent. Détourner le 4 risque peut-être de mettre le bazar, en revanche.

En tout les cas :
- Si tu peux te passer de les détourner, c'est préferable
- Si tu les détourne quand même, indique le dans la notice de ton programme

-

Vertyos> Pourquoi est-ce important à tes yeux de prévenir que le programme modifie les interruptions?

Si un programme détourne un timer qu'il ne devrait pas selon moi (autre que le 1 et le 6), je peux te dire qu'il ne sera pas sur ma calc, sauf si il vaut vraiment le coup.
J'en ai assez de ces jeux qui déreglent l'heure ou produisent des effets indésirables dans le même genre, et je pense que je ne suis pas le seul.

-

> GraphX permet d'affecter jusqu'a 5 fonctions a 5 timers indépendant
Mais bouffe de la place pour rien, n'est pas une fonction standard du système...

> J'en ai assez de ces jeux qui déreglent l'heure ou produisent des effets indésirables dans le même genre, et je pense que je ne suis pas le seul.
Si le programmeur programme comme il faut, ce genre de trucs n'est pas du tout censé arriver....

N'est pas censé arriver en effet, mais l'experience a prouvé que ça arrivait. Je demande simplement de le préciser dans la notice, ce n'est pas la mer à boire ?

D'ailleurs, je suis dégoûté, un des meilleurs jeu TI, Phoenix Platinium met l'horloge en OFF quand on le lance...
J'ai demandé à Patrick s'il voulait bien le corriger, mais il m'a dit qu'il avait autre chose à faire, que c'était seulement un bug mineur pour lui. Donc il ne le corrigera peut-être pas...
Et surtout un truc qui m'embête pas mal : il n'y a aucune new son site depuis le 8 novembre, ça fait presque 3 mois d'inactivité... ou bien il reste actif mais ne l'indique pas sur son site.
Dommage, son dernier shoot'm up avait l'air sympa.

jackiechan a écrit :
D'ailleurs, je suis dégoûté, un des meilleurs jeu TI, Phoenix Platinium met l'horloge en OFF quand on le lance...
J'ai demandé à Patrick s'il voulait bien le corriger, mais il m'a dit qu'il avait autre chose à faire, que c'était seulement un bug mineur pour lui. Donc il ne le corrigera peut-être pas...

Les sources sont données et le programme est dans le domaine public, donc tu es libre de corriger le problème toi-même et de publier ta correction.

Ah oui, j'avais oublié ça, tiens...
Par contre, je ne sais pas du tout ce qui provoque l'arrêt de l'horloge et pour le retrouver dans des sources en ASM, ça va être galère...
M'enfin, je vais essayer quand même.

C'est l'appel à OSSetSR ou trap #1. Il faut rediriger les interruptions à la place.

il m'a dit qu'il allé corriger ça la dernière fosi que je lui ai parlé.

Une grande partie des programmes existants supprime beaucoup d'interruptions, particulièrement l'AUTO_INT_3, justement. OSSetSR(0x0400) ou son équivalent trap #1 sont courants. Si on ne veut pas l'AUTO_INT_5, ce qui est relativement fréquent aussi, on met 0x0500.

Patrick Davidson est un bon programmeur, et quelqu'un de bien parce qu'il fait des programmes open-source...

> GraphX permet d'affecter jusqu'a 5 fonctions a 5 timers indépendant
4, pas 5
Mais une version SE de GraphX va sortir, elle permettra 8 timers et ne bouffera plus de RAM puisque seul ces timers seront gérés, toute la partie graphique sera virée.
Je fais ça à la demande d'un très bon programmeur qui est en train de développer un OS multitâche et qui a remarqué que le noyau événementiel de GX était très bon. On s'est associés (mon site lui servira de portail de diffusion).
Il y aura une description complète du truc quand j'aurais le temps.

> Mais bouffe de la place pour rien
cf ci-dessus.

> n'est pas une fonction standard du système...
Et ? ...
Il me semble qu'on avait dit qu'on arretait nos provocations débiles, alors tu m'expliques ta remarque stp. Ne viens pas me dire après que je passe mon temps à casser ExtGraph.

D'ailleurs, OSVRegisterTimer et OSVFreeTimer ne sont plus des "fonctions standard du système" depuis AMS 2.04 (et oui, pour une fois, Thibaut a raison ).

Je ne vois pas où est le problème de toute façon. XDanger le voulait comme un argument en défaveur de GX, alors que je ne vois pas où est le problème. C'est intolérable étant donné notre pacte.