La Place des Développeurs Projet GOS Et oui, encore trop d'ambitions ^^
Reprise du message précédent
ericb59 :
Ben je n'en doute pas. Mais pourquoi ca ne marche pas avec moi alors ... discrimination !! 
Y a certainement une bonne raison. Est-ce qu'on a envie de passer du temps à la trouver ? Je pense pas vu que c'est pas bloquant et qu'on a tous les deux des trucs plus intéressant à faire.
ericb59 :
Quel intérêt tu as à te passer du BIOS au Boot ? Pour le jeu en lui même je ne dis pas que c'est inutile, mais au Boot, c'est plus du pinaillage non ?
Oui, ce n'est pas absolument nécessaire à cet endroit précis, mais :
1) je préfère le passage par les ports pour les périphériques standards (PPI, VDP et PSG) car c'est plus rapide, plus court et plus "direct" (pas besoin de savoir quelle tambouille fait le Bios)
2) le jour ou je couperai le cordon ombilical avec le Bios, j'aurai pas besoin de recheck toute ma Lib à la recherche des endroits ou j'utiliserais la Bios.
Mon but est de permettre à l'utilisateur d'accéder au Bios, mais que ce ne soit pas le cas dans les fonctions de ma lib.
ericb59 :
Moi je passe en Screen 0 et je fait un Call 5. Si tu as remis les Interruptions tel qu'au départ ça devrait bien se passer.
Quand tu changes de mode écran (avec le Bios), la VRAM est censée se réinitialiser.
Moi je passe en Screen 0 et je fait un Call 5. Si tu as remis les Interruptions tel qu'au départ ça devrait bien se passer.
Quand tu changes de mode écran (avec le Bios), la VRAM est censée se réinitialiser.
J'avais essayé mais ça ne marchait pas. Le mode était bien réinitialisé, mais pas la VRAM.
Grauw m'a conseillé la routine TOTEXT ; je testerai ça ce soir.
On est toujours ignorant avant de savoir.
TOTEXT ne fonctionne pas, mais call INITXT (006Ch) fonctionne bien pour le Basic. 
Il me reste à trouver une solution pour le DOS.
(un call inter-slot à INITXT ne fonctionne pas)
Je continue à creuser...
Il me reste à trouver une solution pour le DOS.
(un call inter-slot à INITXT ne fonctionne pas)
Je continue à creuser...
On est toujours ignorant avant de savoir.
C'est bon, j'ai trouvé une solution grâce à Grauw (que ferions-nous sans lui ).
Pour résumer, Voilà ce que je fais pour quitter proprement mes programmes dans les différents environnements :
- Pour les cartouches ROM : Je fait un soft-reboot avec un RST 0.
- Pour les programmes sous MSX-DOS : Je fais des appels interslot à CHGMOD 5, puis à TOTEXT (qui réinitialise le VDP et la VRAM), puis j'essaye de quitter le programme avec la fonction 62h du DOS-2 et à défaut, si je suis en DOS-1, je quitte avec un appel à la fonction 0h.
- Pour les programmes sous Basic : Je fais jute un appel à INITXT pour réinitialiser l'affichage.
Et évidemment, ne pas oublier de retirer les hook qu'on aurait pu installer dans le programme.
).Pour résumer, Voilà ce que je fais pour quitter proprement mes programmes dans les différents environnements :
- Pour les cartouches ROM : Je fait un soft-reboot avec un RST 0.
- Pour les programmes sous MSX-DOS : Je fais des appels interslot à CHGMOD 5, puis à TOTEXT (qui réinitialise le VDP et la VRAM), puis j'essaye de quitter le programme avec la fonction 62h du DOS-2 et à défaut, si je suis en DOS-1, je quitte avec un appel à la fonction 0h.
- Pour les programmes sous Basic : Je fais jute un appel à INITXT pour réinitialiser l'affichage.
Et évidemment, ne pas oublier de retirer les hook qu'on aurait pu installer dans le programme.
On est toujours ignorant avant de savoir.
En essayant de comprendre les légères différences que j'avais avec un programme sur les différents support (Cartouche ROM, Binaire Basic et DOS), je me suis rendu compte que le temps entre l'arrivé du balayage vertical de l'écran à la ligne indiqué dans le registre du VDP "Interruption line" (R#19) et sa détection dans le hook d'interruption H.KEYI est variable d'un support à l'autre !
Pour visualiser le problème, je change la couleur de fond au début et à la fin du hook de H-Blank (la partie noir est la durée du hook en lui-même).
Le VDP est configuré pour déclencher des interruptions successivement au niveau des deux barres blanches du milieu.
On voit bien que le nombre de lignes est variable entre les lignes blanches et le début de la zone noir qui représente le moment d'execution du hook H-blank.
C'est pas forcement très visible, mais la latence est quasiment la double sous DOS qu'avec une cartouche en ROM !
J'imagine que ça reflète la lourdeur du code d'interruption par défaut sur ces différents support.
Peut-être du à la gestion des disques sous Basic et DOS...
Bon, après, c'est pas très grave pour une utilisation normal.
Et puis au pire, vu que la latence semble assez constante pour un support donnée, on peut toujours ajuster les lignes qui déclenchent les interruptions pour chaque support.
Si je veux une interruption à la ligne 100 et que j'ai 10 lignes de latence sur un support, il suffit de déclencher l'interruption à la ligne 90 sur ce support.
Encore un mystère résolu.
PS : Je précise que le corps de mon programme est exactement identique sur tous les supports ; seul le crt0 (donc l'initialisation) vari.
Pour visualiser le problème, je change la couleur de fond au début et à la fin du hook de H-Blank (la partie noir est la durée du hook en lui-même).
Le VDP est configuré pour déclencher des interruptions successivement au niveau des deux barres blanches du milieu.
On voit bien que le nombre de lignes est variable entre les lignes blanches et le début de la zone noir qui représente le moment d'execution du hook H-blank.
Cartouche
Binaire sous Bsic
Programme DOS
C'est pas forcement très visible, mais la latence est quasiment la double sous DOS qu'avec une cartouche en ROM !
J'imagine que ça reflète la lourdeur du code d'interruption par défaut sur ces différents support.
Peut-être du à la gestion des disques sous Basic et DOS...
Bon, après, c'est pas très grave pour une utilisation normal.
Et puis au pire, vu que la latence semble assez constante pour un support donnée, on peut toujours ajuster les lignes qui déclenchent les interruptions pour chaque support.
Si je veux une interruption à la ligne 100 et que j'ai 10 lignes de latence sur un support, il suffit de déclencher l'interruption à la ligne 90 sur ce support.
Encore un mystère résolu.
PS : Je précise que le corps de mon programme est exactement identique sur tous les supports ; seul le crt0 (donc l'initialisation) vari.
On est toujours ignorant avant de savoir.
Bon, alors, c'est un peu empirique, mais pour info, voici les latences que j'ai calculé sur les différents support :
- Cartouche : 4 lignes
- Basic : 9 lignes
- DOS : 10 lignes
Du coup, si on retire ces nombres au numéro de ligne où l'on souhaite une interruption, on obtient une interruption qui a bien lieu à la même ligne quelque soit le support.
Ces variances de temps de réponse venant de la lourdeur variable du code d'interruption d'un support à l'autre, elles ont une autre conséquence très fâcheuse : le temps qu'il nous reste pour notre propre programme au cours d'une frame, vari lui aussi ! En gros, on peut exécuter plus de code en 1 frame depuis une cartouche que depuis le DOS ou le Basic !!
En tout cas, tout ça me conforte dans l'idée de débrancher complètement les interruptions du Bios durant l'exécution d'un jeu.
J'en suis pas encore là, mais ça muri.
- Cartouche : 4 lignes
- Basic : 9 lignes
- DOS : 10 lignes
Du coup, si on retire ces nombres au numéro de ligne où l'on souhaite une interruption, on obtient une interruption qui a bien lieu à la même ligne quelque soit le support.
Ces variances de temps de réponse venant de la lourdeur variable du code d'interruption d'un support à l'autre, elles ont une autre conséquence très fâcheuse : le temps qu'il nous reste pour notre propre programme au cours d'une frame, vari lui aussi ! En gros, on peut exécuter plus de code en 1 frame depuis une cartouche que depuis le DOS ou le Basic !!
En tout cas, tout ça me conforte dans l'idée de débrancher complètement les interruptions du Bios durant l'exécution d'un jeu.
J'en suis pas encore là, mais ça muri.
On est toujours ignorant avant de savoir.
A ma connaissance, « l'OS qui tourne en arrière plan » se limite à la seule et unique fonction d'interruption à l'adresse 0038h (qui elle, appelle ensuite des sous-routines).
Je ne vois pas comment l'OS pourrait utiliser des ressources d'une autre façon...
Je ne vois pas comment l'OS pourrait utiliser des ressources d'une autre façon...
On est toujours ignorant avant de savoir.
Ce que je veux dire c'est que le DOS gère sa mémoire tout seul en "swippant" les pages, c'est une action qu'il fait, et qui n'existe pas en mode ROM. Donc ça doit bien prendre un peut de temps de faire ça ?
Mais je dis peut être une connerie.
Mais je dis peut être une connerie.
Je connaissais rien au MSX-DOS y a qq semaines donc je vais trop m'avancer, mais de ce que j'ai compris, le DOS s'installe en RAM au démarrage, mais ensuite -- pendant l'exécution de notre programme --, il ne fait rien d'autre que sa gestion des interruptions. Par contre, d'après mes constations, il fait surement plus de chose pendant ces interruptions vu qu'elle dure plus longtemps (et que le hook H.KEYI est appelé plus tard). Il faudrait désassembler MSXDOS2.SYS pour savoir exactement ce qu'il fait... mais j'ai vraiment pas le courage de le faire. 
Dans mon cas, c'était juste nécessaire de comprendre qu'il y avait des latences pour la gestion du H-blank variable d'un support à l'autre. Pour le moment j'ai pas nécessité à aller plus loin (même si ça m'intrigue).
On pourrait p'être demander sur MSX.org, y a surement quelqu'un qui a ces infos.
Dans mon cas, c'était juste nécessaire de comprendre qu'il y avait des latences pour la gestion du H-blank variable d'un support à l'autre. Pour le moment j'ai pas nécessité à aller plus loin (même si ça m'intrigue).
On pourrait p'être demander sur MSX.org, y a surement quelqu'un qui a ces infos.
On est toujours ignorant avant de savoir.
Citation :
c'était juste nécessaire de comprendre qu'il y avait des latences pour la gestion du H-blank variable d'un support à l'autre.
Et c’est d’ailleurs tes intéressant
Avant de revenir à mes moutons... enfin, à mes chèvres... heu... mes footballeurs, je fais encore un peu mumuse avec le MSX 1.
Je voulais tester l'entrelaçage de sprites pour généré plus de couleurs (en gros, on alterne entre 2 images d'une frame à l'autre pour générer de nouvelles couleurs).
Le résultat est mitigé.
Au début, ça donnait vraiment la gerbe, mais en m'assurant que le changement d'image se fasse bien pendant le v-blank (quand l'écran n'est pas en train de dessiner l'image) ça corrige pas mal de soucis.
Reste le problème majeur : le scintillement.
Je sais que c'est inerrant à ce genre de techno, mais en analysant l'image (sur OpenMSX, BlueMSX et mon NMS8250) j'ai l'impression que ce qui choc la rétine, c'est que le temps de visibilité de chaque couleur semble très inégal.
Est-ce que c'est un phénomène connu ?
Est-ce qu'il y a des éléments connu pour interférer avec l'affichage des sprites ?
Dans mon test, tout ce que je fais, c'est attendre le v-blank, regarder si la frame est pair ou impaire, et changer le pattern d'un sprite en fonction (le sprite 0, le plus prioritaire).
Si quelqu'un peut tester le programme sur de vrais MSX (surtout des MSX1) et me dire ce que ça donne, ça serait sympa.
Voici : s_g1.zip
EDIT : J'ai oublié de préciser mais vous pouvez vous déplacer à droite et à gauche avec les flèches [<][>] et changer la taille du sprite avec [1] et [2].
Je voulais tester l'entrelaçage de sprites pour généré plus de couleurs (en gros, on alterne entre 2 images d'une frame à l'autre pour générer de nouvelles couleurs).
Le résultat est mitigé.
Au début, ça donnait vraiment la gerbe, mais en m'assurant que le changement d'image se fasse bien pendant le v-blank (quand l'écran n'est pas en train de dessiner l'image) ça corrige pas mal de soucis.
Reste le problème majeur : le scintillement.
Je sais que c'est inerrant à ce genre de techno, mais en analysant l'image (sur OpenMSX, BlueMSX et mon NMS8250) j'ai l'impression que ce qui choc la rétine, c'est que le temps de visibilité de chaque couleur semble très inégal.
Est-ce que c'est un phénomène connu ?
Est-ce qu'il y a des éléments connu pour interférer avec l'affichage des sprites ?
Dans mon test, tout ce que je fais, c'est attendre le v-blank, regarder si la frame est pair ou impaire, et changer le pattern d'un sprite en fonction (le sprite 0, le plus prioritaire).
Si quelqu'un peut tester le programme sur de vrais MSX (surtout des MSX1) et me dire ce que ça donne, ça serait sympa.
Voici : s_g1.zip
EDIT : J'ai oublié de préciser mais vous pouvez vous déplacer à droite et à gauche avec les flèches [<][>] et changer la taille du sprite avec [1] et [2].
On est toujours ignorant avant de savoir.
Gdx s'était penché sur ce qu'il semble être un Bug concernant les timing du mode entrelacé.
Le sujet est ici => http://msxvillage.fr/forum/topic.php?id=2087#m48509
C'était pour faire mumuse
Le sujet est ici => http://msxvillage.fr/forum/topic.php?id=2087#m48509
C'était pour faire mumuse
C'est chouette cet effet 3d
Par contre, j'ai l'impression que c'est assez différent de mon problème.
D'une frame à l'autre, je ne change que le pattern qu'utilise un sprite ; je touche pas du tout à la page qui est affiché, ni aux adresses des tables, ni au timing du mode entrelacé du MSX2.
Je suis étonné que le temps d'affichage des sprites semble si chaotique d'une frame à l'autre.
J'aimerai bien pouvoir tester ce programme sur de vrais MSX...
Par contre, j'ai l'impression que c'est assez différent de mon problème.
D'une frame à l'autre, je ne change que le pattern qu'utilise un sprite ; je touche pas du tout à la page qui est affiché, ni aux adresses des tables, ni au timing du mode entrelacé du MSX2.
Je suis étonné que le temps d'affichage des sprites semble si chaotique d'une frame à l'autre.
J'aimerai bien pouvoir tester ce programme sur de vrais MSX...
On est toujours ignorant avant de savoir.
aoineko, quand tu gères ton interruption HBLANK, tu le fais à partir de quel hook ?
Logiquement, la gestion des interruptions ne fait rien d'autre que de transférer le contrôle au hook lors d'une interruption HBLANK. Le travail d'arrière plan des interruptions (qui prends un temps certain) ne se produit que lors de l'interruption VBLANK.
Logiquement, la gestion des interruptions ne fait rien d'autre que de transférer le contrôle au hook lors d'une interruption HBLANK. Le travail d'arrière plan des interruptions (qui prends un temps certain) ne se produit que lors de l'interruption VBLANK.
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)
Vu qu'il n'y a pas (à ma connaissance) de hook pour la de gestion des H-Blank, je check le flag qui le gère dans le hook H.KEYI.
Le problème c'est que dans le mode d'interruption par défaut (IM1), toutes les interruptions passe par le même code (38h) donc la quantité de code qu'il y a entre le début de l'interruption et l'exécution du hook H.KEYI et le même que l'interruption ait été déclenché par le H-Blank ou le V-Blank.
Je sais pas si en mode IM2 le VDP nous renverrai un code différent pour ces deux interruptions ?
Si c'est le cas, on pourrait géré ces cas séparément sans que la gestion de l'un ne ralentisse celle de l'autre.
L'autre solution c'est de remplacer le code de gestion en 38h (c'est mon but) pour avoir quelque chose de plus optimal pour un jeu (en gros, ne check que les flags du VDP).
Le problème c'est que dans le mode d'interruption par défaut (IM1), toutes les interruptions passe par le même code (38h) donc la quantité de code qu'il y a entre le début de l'interruption et l'exécution du hook H.KEYI et le même que l'interruption ait été déclenché par le H-Blank ou le V-Blank.
Je sais pas si en mode IM2 le VDP nous renverrai un code différent pour ces deux interruptions ?
Si c'est le cas, on pourrait géré ces cas séparément sans que la gestion de l'un ne ralentisse celle de l'autre.
L'autre solution c'est de remplacer le code de gestion en 38h (c'est mon but) pour avoir quelque chose de plus optimal pour un jeu (en gros, ne check que les flags du VDP).
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie