encore une chtite question - Page 27

Non. Tu peux coder un programme qui est à la fois compatible Titanium et HW1 AMS 1.00. C'est ça la grosse différence: la compatibilité.

Ca tombe bien. Preos fonctionne aussi bien sur Titanium que sur AMS 1.00 92+-HW1

Mais l'équivalent, c'est d'être compatible à la fois avec PlusShell 1.00 et PreOs 0.70.

Toujours le meme point de vue, Kevin. Et moi non plus je n'ai pas change de point de vue. Le but d'un programme kernel n'est pas d'etre compatible avec le plus de kernels possibles, mais de fonctionner le plus simplement possible sur le plus d'AMS et de calculatrices.

Désolé, mais pour moi, demander PreOs 0.70 minimum est tout aussi rude que de mettre MIN_AMS à 300 (ou mettons 209, pour ne pas faire carrément Titanium-only).

Tu peux parfaitement distribuer preos+stdlib dans chaque archive du programme sans probleme. Alors qu'une Mise a jour d'AMS non.

Désolé, mais pour moi, demander PreOs 0.70 minimum est tout aussi rude que de mettre MIN_AMS à 300 (ou mettons 209, pour ne pas faire carrément Titanium-only).

Je pense qu'a partir du moment ou on ne fait pas du kernel v2 minimum(c'est vrai qu'il y e a encore trop qui utilisent doorsos) ce n'est pas trop grave de demander le dernier PreOS même salutaire vu qu'il doit être moins buggé.

D'après la doc, oui.

La limite actuelle est 10 (mais c'est pas officiel).

Dans TIGCCLIB, la limite est 16379.

nan, parce que le code de genlib va finir par un rte, et donc vouloir retourner au code d'avant l'interruption 5.
il faut donc faire un jmp old_autoint5 .
si tu as besoin d'exécuter du code après l'autoint d'origine, tu peux faire uncode pas beau (si tu trouves une méthode plus jolie, je suis intéressé) :

_tsr_x_trap4:
 pea     _tsr_x_restore(pc)
 clr.w   -(a7)
_tsr_x_reloc_1:
 jmp.l   $123456
_tsr_x_restore:
 <ton code ici>
 trap    #12
 rte 

à la place de 123456 faut mettre l'ancienne adresse du trap 4

Martial Demolins
: euh, sinon pour ton code, je suis désolé, je ne suis pas très fort alors ...

_tsr_x_trap4: 
 pea     _tsr_x_restore(pc) ; place l'"ancien PC" sur la pile
 clr.w   -(a7) ; place l'"ancien SR" (mode utilisateur) sur la pile
_tsr_x_reloc_1: ; On a donc mis en place la structure attendue par le rte.
 jmp.l   $123456 ; Saute vers l'interruption sans toucher à la pile.
_tsr_x_restore: ; adresse de retour
 <ton code ici> 
 trap    #12 ; repasse en mode superviseur
 rte

J'ai un peu plus simple:

_tsr_x_trap4: 
 pea     _tsr_x_restore(pc) ; place l'"ancien PC" sur la pile
 move.w   #$2000,-(a7) ; place l'"ancien SR" (mode superviseur) sur la pile
_tsr_x_reloc_1: ; On a donc mis en place la structure attendue par le rte.
 jmp.l   $123456 ; Saute vers l'interruption sans toucher à la pile.
_tsr_x_restore: ; adresse de retour
 <ton code ici> 
 rte

(pas besoin du trap #12). Et dans le cas de l'AI5, je te conseille de mettre #$2400 plutôt que #$2000 (pour respecter les priorités).

et d'après les labels, c'est pour un tsr?

C'est juste qu'il a fait ça pour un TSR, mais ça marche pour n'importe quel handler d'interruptions.

Pendant le déroulement de l'interruption elle-même, c'est la pile superviseur.

Utiliser l'int 5 avec genlib : mauvaise idee je pense
C'est pas impossible, mais assez chaud a faire propremeent. Pourquoi en as-gtu besoin ?

La vrai question est: as-tu réellement besoin de passer par une interruption pour gérer un curseur ?
Sinon, l'IT 3 doit rester active (je crois) pour ne pas gêner le fonctionnement de l'horloge. Donc celle-ci au moins n'est pas désactiviée, donc la 4 non plus logiquement.

Je te déconseille vraiment d'utiliser des fonctions d'affichage dans une interruption, ça risque de rendre vraiment n'importe quoi surtout si tu utilises des niveaux de gris.

>si je le fais avec l'int 1 (j'en aurais besoin une 20aine de fois par seconde), que va-t-il se passer?
Ben rien de plus qu'avec l'int 5.

Seules les interruptions 1 et 2 sont desactivees par genlib, mais on peut sans probleme les reactiver.

Arg. Fait gaffe