Forum Graph100

Je confirme, ca marche impec: on vire les int 9 et 4A, et tout baigne

hmm si ct le cas ca ruinerait tous les marchands de pile 

En tout cas dans les essais elle a pas l'air de s'éteindre apres un certain temps 

ca le ferait bien en classe, les profs vont se demander pkoi tu zones toujours pres de la prise 

et en cas de bogue de l'appli on peu plus éteindre la calcos...

ouaah cool!

euh on peut l' éteindre toujours quand on veut ( avec en gros la fonction shutdown)?

Moi j'ai préféré faire comme ca:

typedef void interrupt (*ptr_inter) (...);
...
void interrupt intnulle(...) {}
void inter(bool active)
{
    static ptr_inter ptr_int9 = _dos_getvect(0x9), ptr_int4A = _dos_getvect(0x4A);

    _dos_setvect(0x9,active ? ptr_int9 : intnulle);
    _dos_setvect(0x4A,active ? ptr_int4A : intnulle);
}

Comme ca y'a une seule fonction pour activer et desativer les int 9 et 4A, et pas de variables globales exterieures (faudrait pas melanger les 2 variables pour chaque interruption en plus  :!: )

Evidemment pour ceux qui n'aiment pas trop dos.h on peut toujours traduir en asm, mais ce que je trouve important c de tout rassembler en une fonx sinon on s'y retrouve plus...  :?

non toi t'as une fonx pour tout desactiver, une fonx pour tout reactiver, et 3 variables globales

Je suppose que oui, vu que j'ai réglé l'heure avec Gcomm il y a qq jours, puis que j'ai lancé sonic pendant qq temps avec l'int 4A désactivée, et que l'heure est toujours correcte maintenant... Donc le fait de désactiver la 4A n'empeche pas les ports de s'incrémenter correctement (mais ce n'est qu'une supposition )

"c bien d'utiliser des var static pour la lisibilité du code, et d'erreurs éventuelles mais utiliser dos.h n'est pas très judicieux car ca pompe plus de place dans l'exe. "

dos.h qui pompe des ressources... hmmm c'est vrai dans la mesure ou tu utilise une ou plusieurs fonctions, dès lors la taille dépend des fonctions utilisées(sachant que certaines s' appellent certainement)

dos.h c'est une header relié a une lib ( dos.lib, je suppose) et il ne contient que des structures/var globales/prototype neccessaires pour la librairie.

Si vous me croyez pas, essayer d' inclure une liste longue de librairies, normalement l' exe doit pas grossir autant que ça... meme pas, mais je préfère ne pas m' avancer, sait on jamais si une lib .h contiendrait pas une définition de fonction  

Je vois que tout avance vite, lol
Ca donne envie de me remettre à la prog G100 rien que pour lancer TCX3  :twisted: (car ça serait plus que mon unique projet, BattleTour étant dès à présent dans l' impossibilité d'ètre porté sur G100 ( trop lent certainement, trop lourd, trop de trucs à gerer etc), dommage je peut po  du moins encore

et bien swifter tu l'as récrit plus haut en reprenant le code de superna pour désactivé int 4A
       xor ax,ax
       mov es,ax
       mov ax,es:0x12A     
       mov OldIntSeg,ax 
       mov ax,es:0x128     
       mov OldIntOff,ax 

il faut mémoriser l'offset + le segment qui en dans la table des interruptions (regarde la doc de Whyp pour savoir ou est l'interruption en question dans le tableau)
 
Sinon X-Thunder28, je n'ai pas voulu dire que le fait d'inclure dos.h faisait grossir l'exe, mais le fait d'utiliser les méthodes de dos.h. Dans mon cas ct _dos_getvect et _dos_setvect. Tu verras qu'il faut mieux que tu reécrives tes propres fonctions en asm.

en fait dans la doc de TC il est clairement dit que si on inclu dos.h, toutes les fonctions'qui y sont définies seront écrites en inline à chaque appel... donc pour que ça prenne moins de place, il ne faut pas inclure dos.h.