La Place des Développeurs Interruptions sur MSX
Je créée ici un sujet séparé, pour ne pas polluer le fil d'aoineko ...
Déjà il faut bien être clair sur un point : l'exécution du code par le Z80 est linéaire, c'est à dire qu'il ne poursuit qu'un seul fil d'instructions à la fois. Il n'est pas capable, comme les processeurs modernes, d'exécuter plusieurs fils en même temps. Par contre, il peut réagir à des interruptions, et aiguiller son code en fonction de celles-ci. Mais qu'est ce qu'une interruption ?
C'est quand un périphérique vient "frapper à la porte" du Z80 et lui dire : je voudrais que tu traites ma demande tout de suite ! ... Le Z80 arrête alors d'exécuter le code courant, et se branche à une adresse. Il y existe plusieurs modes de gestion des interruptions sur un Z80, mais celui qui a été choisi et paramétré sur MSX, c'est d'appeler l'adresse $0038, quel que soit le périphérique qui provoque l'interruption.
La routine en $0038 (appelée KEYINT dans le BIOS) a donc la lourde charge de gérer toutes les interruptions que le Z80 reçoit. Et elles peuvent être nombreuses (VDP, lecteur de disquettes, RS232, ...). Elle exécute un code ou appelle un hook en fonction du périphérique qui appelle.
L'interruption principale est celle qui est générée en hardware par le VDP lors du VBLANK ("Vertical BLANK" - fin de balayage de l'écran). Elle a lieu 50 fois ou 60 fois par seconde en fonction du standard vidéo du VDP (PAL: 50 fois, NTSC: 60 fois). En elle-même, elle ne sert pas à grand chose (le VDP n'a pas vraiment besoin d'informer le Z80 de la fin du balayage), mais elle a le grand avantage de donner un "coup de métronome" au système. Et le BIOS l'utilise effectivement, car le code de "base" de KEYINT permet de gérer des choses qui semblent être faites en arrière plan (c'est évidemment une illusion) : scan du clavier, incrémentation horloge, ... Sans l'interruption VBLANK du VDP, il serait impossible pour le clavier du MSX de fonctionner !
Dans le cas d'un jeu, profiter de cette interruption VBLANK est évidemment essentiel, car cela permet de profiter du "coup de métronome" pour réaliser pas mal de choses : déplacer les ennemis, faire une animation en arrière plan, jouer la musique de fond, ... Et pour profiter de cette interruption, il suffit d'utiliser le hook H.TIMI, qui est justement appelé par KEYINT à chaque interruption VBLANK, pour que KEYINT donne le contrôle à la routine que tu auras écrite.
Sur MSX2, le VDP peut générer une autre interruption, à la demande de l'utilisateur cette fois-ci. C'est une interruption qui peut avoir lieu lors du balayage à l'écran d'une ligne déterminée par le programmeur. C'est ce qu'on appelle l'interruption HBLANK ("Horizontal BLANK"). C'est comme cela que l'on réalise des "splits". Par exemple, on est en SCREEN5 des lignes 0 à 128, et en SCREEN6 des lignes 128 à 192. Pour faire ça, le programmeur a paramétré une interruption HBLANK à la ligne 128, et lors du traitement de celle-ci, il change de mode d'écran, pour le restaurer ensuite lors du VBLANK.
Voilà, ça c'est pour le B-A-BA.
ericb59 :
Comprendre, dans le cas de la realisation d'un jeu, comment correctement utiliser les interruptions, et aménager son code en conséquence.
Le béaba de la gestion d'interruption sur MSX ca serait déjà pas mal
Le béaba de la gestion d'interruption sur MSX ca serait déjà pas mal
Déjà il faut bien être clair sur un point : l'exécution du code par le Z80 est linéaire, c'est à dire qu'il ne poursuit qu'un seul fil d'instructions à la fois. Il n'est pas capable, comme les processeurs modernes, d'exécuter plusieurs fils en même temps. Par contre, il peut réagir à des interruptions, et aiguiller son code en fonction de celles-ci. Mais qu'est ce qu'une interruption ?
C'est quand un périphérique vient "frapper à la porte" du Z80 et lui dire : je voudrais que tu traites ma demande tout de suite ! ... Le Z80 arrête alors d'exécuter le code courant, et se branche à une adresse. Il y existe plusieurs modes de gestion des interruptions sur un Z80, mais celui qui a été choisi et paramétré sur MSX, c'est d'appeler l'adresse $0038, quel que soit le périphérique qui provoque l'interruption.
La routine en $0038 (appelée KEYINT dans le BIOS) a donc la lourde charge de gérer toutes les interruptions que le Z80 reçoit. Et elles peuvent être nombreuses (VDP, lecteur de disquettes, RS232, ...). Elle exécute un code ou appelle un hook en fonction du périphérique qui appelle.
L'interruption principale est celle qui est générée en hardware par le VDP lors du VBLANK ("Vertical BLANK" - fin de balayage de l'écran). Elle a lieu 50 fois ou 60 fois par seconde en fonction du standard vidéo du VDP (PAL: 50 fois, NTSC: 60 fois). En elle-même, elle ne sert pas à grand chose (le VDP n'a pas vraiment besoin d'informer le Z80 de la fin du balayage), mais elle a le grand avantage de donner un "coup de métronome" au système. Et le BIOS l'utilise effectivement, car le code de "base" de KEYINT permet de gérer des choses qui semblent être faites en arrière plan (c'est évidemment une illusion) : scan du clavier, incrémentation horloge, ... Sans l'interruption VBLANK du VDP, il serait impossible pour le clavier du MSX de fonctionner !
Dans le cas d'un jeu, profiter de cette interruption VBLANK est évidemment essentiel, car cela permet de profiter du "coup de métronome" pour réaliser pas mal de choses : déplacer les ennemis, faire une animation en arrière plan, jouer la musique de fond, ... Et pour profiter de cette interruption, il suffit d'utiliser le hook H.TIMI, qui est justement appelé par KEYINT à chaque interruption VBLANK, pour que KEYINT donne le contrôle à la routine que tu auras écrite.
Sur MSX2, le VDP peut générer une autre interruption, à la demande de l'utilisateur cette fois-ci. C'est une interruption qui peut avoir lieu lors du balayage à l'écran d'une ligne déterminée par le programmeur. C'est ce qu'on appelle l'interruption HBLANK ("Horizontal BLANK"). C'est comme cela que l'on réalise des "splits". Par exemple, on est en SCREEN5 des lignes 0 à 128, et en SCREEN6 des lignes 128 à 192. Pour faire ça, le programmeur a paramétré une interruption HBLANK à la ligne 128, et lors du traitement de celle-ci, il change de mode d'écran, pour le restaurer ensuite lors du VBLANK.
Voilà, ça c'est pour le B-A-BA.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Je comprend bien le principe, mais c'est dans la pratique que je n'arrive pas à bien faire.
Je ne sais utiliser le VDP interrupt que pour synchroniser la musique.
Comment faire d'autres choses après la musique ? Et combien de temps j'ai pour faire autre chose ?
là, j ne pige plus ...
Ha le HBLANK c'est pour MSX2. OK...
PS : J'aime bien la façon dont tu explique l'interruption.
Tu permets que je reprenne tes mots dans ma documentation pour Fusion-C ?
Edité par
ericb59
Le 14/01/2021 à 11h38
Je ne sais utiliser le VDP interrupt que pour synchroniser la musique.
Comment faire d'autres choses après la musique ? Et combien de temps j'ai pour faire autre chose ?
là, j ne pige plus ...
Citation :
HBLANK ("Horizontal BLANK").
HBLANK ("Horizontal BLANK").
Ha le HBLANK c'est pour MSX2. OK...
PS : J'aime bien la façon dont tu explique l'interruption.
Tu permets que je reprenne tes mots dans ma documentation pour Fusion-C ?
Edité par
ericb59
Le 14/01/2021 à 11h38
ericb59 :
Je comprend bien le principe, mais c'est dans la pratique que je n'arrive pas à bien faire.
Je ne sais utiliser le VDP interrupt que pour synchroniser la musique.
Comment faire d'autres choses après la musique ? Et combien de temps j'ai pour faire autre chose ?
là, j ne pige plus ...
Je ne sais utiliser le VDP interrupt que pour synchroniser la musique.
Comment faire d'autres choses après la musique ? Et combien de temps j'ai pour faire autre chose ?
là, j ne pige plus ...
Tu fais ce que tu veux dans la routine qui est appelée par le hook.
C'est ton code qui détermine ce que tu veux faire ...
En ce qui concerne le temps, la seule contrainte est de tout boucler avant la prochaine interruption !
Et donc, dans le cas de l'interruption VBLANK, sachant que:
- 1 frame prends 70.000 cycles environ (temps entre 2 VBLANK sur un MSX PAL)
- la gestion de l'interruption par KEYINT peut prendre entre 3000 et 7000 cycles selon les modèles
tu disposes en gros de 60.000 cycles maximum.
Bien évidemment, il faut aussi que tu laisse du temps pour ton code principal ... En résumé tu disposes, pour ton code principal et pour tes interruptions, de 60.000 cycles (soit environ 7500 instructions) par frame pour faire tout ce que tu dois faire sur la frame courante.
ericb59 :
PS : J'aime bien la façon dont tu explique l'interruption.
Tu permets que je reprenne tes mots dans ma documentation pour Fusion-C ?
Tu permets que je reprenne tes mots dans ma documentation pour Fusion-C ?
Oui, bien sûr, pas de soucis
Edité par
Metalion
Le 14/01/2021 à 11h50
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Tu peux aussi avoir une boucle de gameplay qui dure 2 frames du VDP par ex. et dans ce cas tu as beaucoup plus de temps pour ton jeu ; mais faut accepter que ton visuel ne soit mise-à-jour qu'à 25 ou 30 Hz (PAL/NTSC).
Pour tout dire, si mon jeu de foot, je suis à 1 frame gameplay pour 4 frames VDP actuellement et je vise de descendre à 3 (16/20 images-par-seconde).
EDIT : ET oui, c'est une très belle explication des interruptions que tu nous as fait là Metalion
Pour tout dire, si mon jeu de foot, je suis à 1 frame gameplay pour 4 frames VDP actuellement et je vise de descendre à 3 (16/20 images-par-seconde).
EDIT : ET oui, c'est une très belle explication des interruptions que tu nous as fait là Metalion
On est toujours ignorant avant de savoir.
aoineko :
Tu peux aussi avoir une boucle de gameplay qui dure 2 frames du VDP par ex. et dans ce cas tu as beaucoup plus de temps pour ton jeu ; mais faut accepter que ton visuel ne soit mise-à-jour qu'à 25 ou 30 Hz (PAL/NTSC).
Tout à fait.
aoineko :
Pour tout dire, si mon jeu de foot, je suis à 1 frame gameplay pour 4 frames VDP actuellement et je vise de descendre à 3 (16/20 images-par-seconde).
Exactement pareil pour moi : après l'input du joueur, je génère mon écran de jeu en à peu près 3 frames VDP (donc environ 16 fps en génération continue).
Ce qui me pose un problème d'ailleurs pour la mise à jour des sprites ennemis ... Car j'ai besoin de mettre à jour leur position de façon absolument régulière (1 fois toutes les x frames, peu importe la valeur de x), sauf que pour faire cela j'ai besoin d'écrire dans la VRAM du VDP. Or mon code de génération de l'écran utilise en masse des écritures séquentielles en VRAM. Et si je protège par di/ei ces écritures séquentielles, il y a un risque réel de louper le VBLANK (ou de le décaler dans le temps), ce qui serait nuisible à la routine de lecture de musique, par exemple. Je n'ai pas encore trouvé de solution pour le moment ...
aoineko :
ET oui, c'est une très belle explication des interruptions que tu nous as fait là Metalion
Merci !
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
concrètement, est-ce qu'il faut séparer les routines de "compute" et d'affichage ? (sprites, tiles...)
si oui, on fait le "compute" pendant l'interruption ou on fait l'affichage ?
si oui, on fait le "compute" pendant l'interruption ou on fait l'affichage ?
ericb59 :
concrètement, est-ce qu'il faut séparer les routines de "compute" et d'affichage ? (sprites, tiles...)
si oui, on fait le "compute" pendant l'interruption ou on fait l'affichage ?
si oui, on fait le "compute" pendant l'interruption ou on fait l'affichage ?
Il n'y a pas de règle, c'est toi qui décide en fonction de tes besoins.
Cela dépend généralement quelle est la routine qui nécessite une mise à jour régulière ...
Une autre technique, que j'ai déjà utilisée, c'est de tout faire en dehors des interruptions, mais d'utiliser les interruptions comme "timer" (attention, cela n'est possible que si tout peut être exécuté en moins d'une frame). Concrètement, l'interruption incrémente un compteur et tu utilises ce compteur comme déclencheur.
Code :
; Boucle d'attente joueur
WAIT_PLAYER:
;-----------------------------------------------------------
; Synchro VBLANK
;-----------------------------------------------------------
call VBLANK_WAIT ; attente incrémentation compteur frame [timer]
;-----------------------------------------------------------
; Cycle d'animation (64 frames)
;-----------------------------------------------------------
; Evènements déclenchés une seule fois par cycle
; frame #0 : Ascenseurs
ld a,[timer] ; 13 T
and a ; 4 T
call z,ASCENSEURS ; 17 T (true) / 10 T (false)
; frame #16 : Laser ON
ld a,[timer]
cp 16
call z,LASER
; frame #24 : Laser OFF
ld a,[timer]
cp 24
call z,LASER
; Evènements déclenchés plusieurs fois par cycle
; appel variable : gravité
ld a,[timer]
ld hl,gravity
and [hl]
call z,GRAVITY
; toutes les 4 frames : Animation hélices hélicoptères
ld a,[timer]
and 3
call z,PROPELLER
; toutes les 8 frames
(...)
Edité par Metalion Le 14/01/2021 à 13h15
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
ericb59 :
concrètement, est-ce qu'il faut séparer les routines de "compute" et d'affichage ? (sprites, tiles...)
si oui, on fait le "compute" pendant l'interruption ou on fait l'affichage ?
si oui, on fait le "compute" pendant l'interruption ou on fait l'affichage ?
Personnellement, je recommanderai de faire le moins de chose possible dans le hook (appelé par les interruptions).
Pour le V-Blank, je fais juste des set de variables qui seront traiter dans la boucle principale (comme ça l'interruption est très rapide).
Pour le H-Blank, c'est plus compliqué vu qu'il faut que le code s'exécute tout de suite.
Donc là, pas le choix, faut mettre son code dans le hook.
Pour prendre l'exemple de mon projet GOS, voici ce que font chacune des interruptions :
V-Blank :
- Dans la fonction appelé par l'interruption H.TIMI, je set une variable g_VBlank à 1 et j'incrémente un compte g_Frame (que j'utilise comme index pour mes animations par ex.).
- A la fin de mon code gameplay, je boucle tant que g_VBlank n'est pas égale à 1 et une fois que c'est le cas (donc que l'interruption du V-Blank à eu lieu) je remets cette variable à 0 et je commence une nouvelle boucle de gameplay.
En vrai, ça c'est dans le cas ou tu as 1 frame gameplay = 1 frame VDP. Dans mon cas c'est un peu plus compliqué, mais je suis pas sûr que ça vaille la peine de rentrer dans le détail.
H-Blank :
- En fait, j'utilise un scrolling hardware au delà de la limite de 256 lignes normalement autorisé. Par défaut, ça boucle avec le début de la VRAM, mais j'utilise le H-Blank pour qu'à la ligne ou c'est censé bouclé, le VDP se mette à pointer vers la suite de la VRAM. En gros, je change la page affiché au cours de l'affichage. Ca me permet d'avoir un scrolling quasiment gratos sur 384 px de haut (la taille de mon terrain de foot).
- Du coup, lors du V-Blank (au début de ma boucle de gameplay), je set la page affichée sur 0 par ex., et je set le VDP pour déclencher une interruption H-Blank à la ligne souhaité (en gros, 384 - la valeur du registre de scrolling).
- Dans le H.KEYI (point d'entrée de toutes les interruptions coté programme), je check si une interruption H-Blank a eu lieu (via le registre S#1) et si c'est le cas, je lance ma fonction de gestion du H-Blank
- Dans cette fonction, je set juste la page affiché à 1 et voilà, le tour est joué.
Bon, encore une fois, c'est un peu plus compliqué que ça car comme ma frame gameplay dure plusieurs frame VDP, le H-Blank à lieu plusieurs fois. Sans parler du fait que j'utilise du double-buffering (j'affiche une page pendant que j'écris dans l'autre). Mais bon, l'idée y est.
On est toujours ignorant avant de savoir.
ok, merci à tous les 2, j'y vois plus clair.
Dans le cas d'utilisation de fusion-c, toutes mes routines graphique, ainsi que les routines qui font appel au Bios, désactivent les interruptions quand il y a besoin, par exemple pour le VDP, et finissent toutes par un EI.
Du coup, on est d'accord qu'utiliser ces fonctions une fois branché sur la procédure pointée par H.TIMI va finir pas planter ?
Question subsidiaire. Il me semble avoir lu quelque part, que quand on à fait un appel à une fonction BIOS, via un Call interslot depuis MSXDOS, ou via un Call normal depuis une ROM, il fallait rendre la main par :
ei
ret
Est-ce vraiment nécessaire de faire un EI après un Call d'une fonction Bios ?
Dans le cas d'utilisation de fusion-c, toutes mes routines graphique, ainsi que les routines qui font appel au Bios, désactivent les interruptions quand il y a besoin, par exemple pour le VDP, et finissent toutes par un EI.
Du coup, on est d'accord qu'utiliser ces fonctions une fois branché sur la procédure pointée par H.TIMI va finir pas planter ?
Question subsidiaire. Il me semble avoir lu quelque part, que quand on à fait un appel à une fonction BIOS, via un Call interslot depuis MSXDOS, ou via un Call normal depuis une ROM, il fallait rendre la main par :
ei
ret
Est-ce vraiment nécessaire de faire un EI après un Call d'une fonction Bios ?
ericb59 :
Dans le cas d'utilisation de fusion-c, toutes mes routines graphique, ainsi que les routines qui font appel au Bios, désactivent les interruptions quand il y a besoin, par exemple pour le VDP, et finissent toutes par un EI.
Du coup, on est d'accord qu'utiliser ces fonctions une fois branché sur la procédure pointée par H.TIMI va finir pas planter ?
Du coup, on est d'accord qu'utiliser ces fonctions une fois branché sur la procédure pointée par H.TIMI va finir pas planter ?
Non, pas du tout ... DI/EI sont juste là pour protéger un bout de code contre une interruption éventuelle. Lorsqu'une fonction est appelée pendant une interruption, DI/EI n'auront en pratique aucun effet. Sauf peut-être dans le cas extrême où les routines appelées dépasseraient le temps complet d'une frame, et alors elles protègent simplement d'une nouvelle interruption. Pas de plantage.
Pour info, comme bonne pratique, 'ei' peut être placé une instruction avant la fin réelle de la protection. Car le Z80, en pratique, ne ré-autorise les interruptions qu'après l'instruction suivante. Et donc :
Code :
ei
out (c),a
ret
au lieu de :
Code :
out (c),a
ei
ret
ericb59 :
Est-ce vraiment nécessaire de faire un EI après un Call d'une fonction Bios ?
Je ne peut pas te répondre pour un call interslot, mais en ce qui concerne un call 'normal' d'une fonction BIOS, le 'ei' n'est pas nécessaire.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
De ce que j'ai lu, le EI est nécessaire pour certaines fonctions du Bios qui font un DI mais "oublie" de faire le EI.
CALSLT est bien l'une de ces fonctions mais il y en a d'autres il me semble.
Et tant qu'on est dans les bizarreries du Bios, il est demandé de sauver / restaurer le registre A dans la routine appelé par H.TIMI car la suite du Bios s'attends à trouver dans A la valeur du registre S#0 récupéré juste avant le H.TIMI.
Je ne sais pas dans quel cas c'est vraiment nécessaire (ça marche très bien sans), mais c'est demandé en tout cas.
CALSLT est bien l'une de ces fonctions mais il y en a d'autres il me semble.
Et tant qu'on est dans les bizarreries du Bios, il est demandé de sauver / restaurer le registre A dans la routine appelé par H.TIMI car la suite du Bios s'attends à trouver dans A la valeur du registre S#0 récupéré juste avant le H.TIMI.
Je ne sais pas dans quel cas c'est vraiment nécessaire (ça marche très bien sans), mais c'est demandé en tout cas.
On est toujours ignorant avant de savoir.
aoineko :
Et tant qu'on est dans les bizarreries du Bios, il est demandé de sauver / restaurer le registre A dans la routine appelé par H.TIMI car la suite du Bios s'attends à trouver dans A la valeur du registre S#0 récupéré juste avant le H.TIMI.
Je ne sais pas dans quel cas c'est vraiment nécessaire (ça marche très bien sans), mais c'est demandé en tout cas.
Je ne sais pas dans quel cas c'est vraiment nécessaire (ça marche très bien sans), mais c'est demandé en tout cas.
C'est effectivement nécessaire, car la valeur de A est stockée au retour de H.TIMI dans (STATFL), qui est le miroir de la valeur du registre de statut du VDP dans la RAM. C'est vrai qu'un PUSH AF/POP AF n'aurait pas fait de mal ...
Code :
CALL H.KEYI
IN A,(VDP.SR)
AND A
JP P,INTRET
CALL H.TIMI
EI
LD (STATFL),A
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Je protège la routine cible du hook comme ceci, est-ce bien ?
Code C :
void routing(void) __critical __interrupt(0) __preserves_regs(a,b,c,d,e,h,l,iyl,iyh) { vdp_status = VDP_port2; if (GameOn==1) { Timer(); } PT3Rout(); // Route the PT3 music to PSGPT3Rout PT3Play(); // Play/Update the music playing PT3FXRout(); }
Je te conseil de toujours regarder l'assembleur généré ; il est souvent plus parlant que la doc.
Prenons les 4 fonctions suivantes :
Voici le code généré :
Ici, rien de spécial. On notera que pour une fois, SDCC à créé un code assembleur propre.
__critical permet donc de désactiver les interruptions le temps de la fonction. Ca récupère aussi la valeur du registre d'interruption I qui ne sert qu'en mode IM2 (donc pas le mode d'interruption par défaut du MSX). Je sais pas pourquoi il fait ret PO ni pourquoi il push/pop AF, mais tu as besoin de tout ça en tout cas.
__interrupt permet 2 choses : il sauvegarde/restaure presque tous les registres (il manque IX et surtout tous les registres miroirs) et fait un RETI au lieu d'un RET. C'est donc pour gérer une fonction d'interruption comme celle en 38h, mais pas pour un hook qui lui est appelé par l'interruption et qui n'a donc ni besoin de restaurer les registres, ni faire un RETI.
On pourrait croire que __preserves_regs ne fait rien, mais ce n'est pas le cas. On regarde juste au mauvais endroits. Cette directive dit simplement au compilateur quels registres ne sont pas modifiés, ce qui lui permet de faire des optimisations dans le code appelant.
Pour résumé, une fonction de hook H.TIMI en C ne devrait avoir aucune de ces directives. Tu peux juste ajouter un __asm("push AF"); au début et un __asm("pop AF"); à la fin et ta fonction est prête pour être appelé par le code d'interruption.
Prenons les 4 fonctions suivantes :
Code C :
void test(void) { g_ModeIndex++; } void testC(void) __critical { g_ModeIndex++; } void testI(void) __interrupt(0) { g_ModeIndex++; } void testP(void) __preserves_regs(a,b,c,d,e,h,l,iyl,iyh) { g_ModeIndex++; }
Voici le code généré :
Code ASM :
; void test(void) { g_ModeIndex++; } _test:: ld hl, #_g_ModeIndex+0 inc (hl) ret
Ici, rien de spécial. On notera que pour une fois, SDCC à créé un code assembleur propre.
Code ASM :
; void testC(void) __critical { g_ModeIndex++; } _testC:: ld a,i di push af ld hl, #_g_ModeIndex+0 inc (hl) pop af ret PO ei ret
__critical permet donc de désactiver les interruptions le temps de la fonction. Ca récupère aussi la valeur du registre d'interruption I qui ne sert qu'en mode IM2 (donc pas le mode d'interruption par défaut du MSX). Je sais pas pourquoi il fait ret PO ni pourquoi il push/pop AF, mais tu as besoin de tout ça en tout cas.
Code ASM :
; void testI(void) __interrupt(0) { g_ModeIndex++; } _testI:: ei push af push bc push de push hl push iy ld hl, #_g_ModeIndex+0 inc (hl) pop iy pop hl pop de pop bc pop af reti
__interrupt permet 2 choses : il sauvegarde/restaure presque tous les registres (il manque IX et surtout tous les registres miroirs) et fait un RETI au lieu d'un RET. C'est donc pour gérer une fonction d'interruption comme celle en 38h, mais pas pour un hook qui lui est appelé par l'interruption et qui n'a donc ni besoin de restaurer les registres, ni faire un RETI.
Code ASM :
void testP(void) __preserves_regs(a,b,c,d,e,h,l,iyl,iyh) { g_ModeIndex++; } _testP:: ld hl, #_g_ModeIndex+0 inc (hl) ret
On pourrait croire que __preserves_regs ne fait rien, mais ce n'est pas le cas. On regarde juste au mauvais endroits. Cette directive dit simplement au compilateur quels registres ne sont pas modifiés, ce qui lui permet de faire des optimisations dans le code appelant.
Pour résumé, une fonction de hook H.TIMI en C ne devrait avoir aucune de ces directives. Tu peux juste ajouter un __asm("push AF"); au début et un __asm("pop AF"); à la fin et ta fonction est prête pour être appelé par le code d'interruption.
On est toujours ignorant avant de savoir.
J'ai lu quelque part (je peux sans doute retrouver)
que pour un bon fonctionnement la bonne pratique pour la routine appelée par le hook était:
1 - Push tout les registres
2 - Di
3 - notre code
4 - Ei
5 - pop tout les registreS
c'est pour cela que j'avais mis ces directictives
que pour un bon fonctionnement la bonne pratique pour la routine appelée par le hook était:
1 - Push tout les registres
2 - Di
3 - notre code
4 - Ei
5 - pop tout les registreS
c'est pour cela que j'avais mis ces directictives
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie