La Place des Développeurs Questions divers sur le VDP
Reprise du message précédent
Bon, c'est pas une question puisse que j'ai trouvé la réponse, mais j'ai bien galéré à trouver comment utiliser les interruptions du HBlank !Du coup, je mets les infos ici au cas ou ça puisse servir à quelqu'un.
Donc, pour que ça fonctionne :
- Il faut set le bit IE1 (10h) dans le registre R#0 du VDP
- Si on fait rien de plus, le système va entrer dans une boucle infinie !
- Une fois IE1 set, il faut absolument lire le registre de status S#1 pour que le flag soit reset (sinon ça bloque les autres interruptions du VDP)
- Pour se faire, il faut se brancher sur le hook H.KEYI et lire la valeur de S#1
- Attention dans ce hook, on ne peut pas utiliser les instructions di/ei sinon ça casse le système d'interruption
- Ne pas oublier de remettre S#0 dans le registre R#15 si on utilise le Bios car la routine principale d'interruption détecte le VBlank en checkant la valeur de S#0 sans initialiser R#15
- Et voilà, une fois tous ces pièges évités, on peut maintenant utiliser le registre R#19 pour choisir une ligne qui déclenchera l'interruption (horizontal scan interrupt)
On est toujours ignorant avant de savoir.
Il faut aussi s'assurer qu'au moment où le vdp declenche son interruption sur la ligne x, les interruptions ne soient pas masquées. Autrement dit, ne jamais utiliser DI.
Toute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
Sector28 :
Il faut aussi s'assurer qu'au moment où le vdp declenche son interruption sur la ligne x, les interruptions ne soient pas masquées. Autrement dit, ne jamais utiliser DI.
Et oui... parce que là, j'ai un décalage en 2,33 lignes entre ma ligne marqué en HBlank et la ligne ou le changement de page est effectif.
En dehors de ça, ça marche bien.
J'ai pas encore remplacé le gestionnaire d'interruption du Bios (j'ai encore qq cordons ombilicales avec le Bios à couper avant de pouvoir passer la page 0 du Z80 en RAM et placer mon propre gestionnaire).
En attendant, je maitrise pas du tout quand le Bios peut modifie les registres du VDP donc c'est compliqué de retirer les di entre mes out vers les registres du VDP.
On est toujours ignorant avant de savoir.
J'ai recheck toute ma lib et j'ai quasiment pas de "di" en fait (j'avais lu qu'il fallait les éviter le plus possible).
Seuls les quelques fonctions qui ont besoin d'écrire dans plusieurs registres VDP d'affilé les utilises (et ça semble indispensable, même avec mon propre système d'interrupt vu que pour check le VBlank, je vais avoir besoin de modifier les registres du VDP).
Du coup, j'ai cherché ailleurs d'où pouvait venir le délais entre le HBlank théorique et effectif.
J'ai trouvé 2 choses :
1) Les grosses commandes VDP de test que je faisais semblent être à l'origine du décalage de 0,33 ligne (en fait, c'est un décalage légèrement fluctuant d'une frame à l'autre).
Pourtant, même si les commandes font de gros déplacement de bloc (pour le test), le "di" lui ne dure jamais plus que le temps de 15 "outi".
En tout cas, en retirant toutes mes commandes, ça supprime le décalage de longueur variable...
2) ... par contre, y a 2 lignes complètes de décalage que je n'explique pas et qui sont présente même si mon programme est vide et ne fait rien d'autre que scroll et changer de page quand on dépasse 255 en Y.
Pour tester, j'ai décaler le numéro de ligne du HBlank 2 lignes plus tôt et là, ô miracle, j'ai une transition parfaite entre mes pages de VRAM !
Une idée d'où peut venir ces 2 "problèmes" ?
Seuls les quelques fonctions qui ont besoin d'écrire dans plusieurs registres VDP d'affilé les utilises (et ça semble indispensable, même avec mon propre système d'interrupt vu que pour check le VBlank, je vais avoir besoin de modifier les registres du VDP).
Du coup, j'ai cherché ailleurs d'où pouvait venir le délais entre le HBlank théorique et effectif.
J'ai trouvé 2 choses :
1) Les grosses commandes VDP de test que je faisais semblent être à l'origine du décalage de 0,33 ligne (en fait, c'est un décalage légèrement fluctuant d'une frame à l'autre).
Pourtant, même si les commandes font de gros déplacement de bloc (pour le test), le "di" lui ne dure jamais plus que le temps de 15 "outi".
En tout cas, en retirant toutes mes commandes, ça supprime le décalage de longueur variable...
2) ... par contre, y a 2 lignes complètes de décalage que je n'explique pas et qui sont présente même si mon programme est vide et ne fait rien d'autre que scroll et changer de page quand on dépasse 255 en Y.
Pour tester, j'ai décaler le numéro de ligne du HBlank 2 lignes plus tôt et là, ô miracle, j'ai une transition parfaite entre mes pages de VRAM !
Une idée d'où peut venir ces 2 "problèmes" ?
On est toujours ignorant avant de savoir.
De ce que je comprends, le "di" n'est indispensable que quand tu fais des "in/out" en série sur des registres et que le résultat dépend de la valeur précédente d'un des ports.
Du coup, pour lire un status il faut écrire deux fois sur le port 99h avant de le lire donc oui, le "di" est indispensable normalement.
Le cas d'un hook de H.KEYI est un cas particulier car tu es déjà dans une interruption et que des flags au niveau du CPU sont set de façon à déjà empêcher la récursivité. Faire un "di" (ou surtout un "ei" ?) doit casser cette sécurité.
Si un spécialiste du MSX peut infirmer ou confirmer, ça serait bien.
Du coup, pour lire un status il faut écrire deux fois sur le port 99h avant de le lire donc oui, le "di" est indispensable normalement.
Le cas d'un hook de H.KEYI est un cas particulier car tu es déjà dans une interruption et que des flags au niveau du CPU sont set de façon à déjà empêcher la récursivité. Faire un "di" (ou surtout un "ei" ?) doit casser cette sécurité.
Si un spécialiste du MSX peut infirmer ou confirmer, ça serait bien.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie