La Place des Développeurs Mon premier jeu en assembleur
Bonjour,
Comme annoncé il y a quelques semaines, je veux faire un jeu asm z80 sur MSX.
J'ai mis un certain temps pour mettre en place un environnement minimum.
Encore un certain temps à lire de la doc technique.
Ça y est, je suis prêt, ça va fuser. Pour l'instant, ça fuse autant qu'une SpaceX fraichement lancée avec désintégration en vol.
Je veux passer en mode GRAPHIC 4 (msx2).
J'ai suivi cette doc: https://konamiman.github.io/MSX2-Technical-Handbook/md/Chapter4a.html#36-graphic-4-mode
Il ne se passe rien. Ça ne plante pas, mais ça ne quitte pas non plus le mode texte.
Je n'ai pas cherché à finasser en utilisant les registres auto-incrémentés pour faire mes « out » (j'aurais pu, vu que les registres se suivent). Je préfère faire simple pour l'instant.
La notation binaire avec les séparateurs, c'est une facilité sjasm pour s'y retrouver dans les champs de bits.
C'est purement informatif et ça génère bien le nombre attendu sans les séparateurs.
Maintenant que j'y pense, l'accès mémoire et les op. logiques dans le bloc di/ei , c'est moyen.
Je pourrais préparer ça en dehors, stocker dans deux registres et enchainer les out.
Mais je ne pense pas que ce soit la cause de mon problème, au pire ça bloque un peu le système.
Merci pour vos suggestions. Edité par zone Le 19/11/2023 à 16h46
Comme annoncé il y a quelques semaines, je veux faire un jeu asm z80 sur MSX.
J'ai mis un certain temps pour mettre en place un environnement minimum.
Encore un certain temps à lire de la doc technique.
Ça y est, je suis prêt, ça va fuser. Pour l'instant, ça fuse autant qu'une SpaceX fraichement lancée avec désintégration en vol.
Je veux passer en mode GRAPHIC 4 (msx2).
J'ai suivi cette doc: https://konamiman.github.io/MSX2-Technical-Handbook/md/Chapter4a.html#36-graphic-4-mode
Code :
VDP_0_7 = $F3DF
ld a,(VDP_0_7) ; état du registre 0 - pour partir des valeurs système
and a,%1111'000'1 ; j’aurais pu mettre %1111’011’1 , mais le triple 0 documente le but
or a,%0000'011'1 ; compléter avec les deux bits à 1 nécessaires - dans R#0 : xxxx011x
di
out ($99),a
ld a,128 ; r#0 en écriture
ld a,(VDP_0_7+1)
and a,%111'00'111 ; dans R#1 : xxx00xxx
out ($99),a
ld a,128+1 ; r#1 en écriture
ei ; le dernier out passe juste avant que « ei » soit pris en compte
out ($99),a
Il ne se passe rien. Ça ne plante pas, mais ça ne quitte pas non plus le mode texte.
Je n'ai pas cherché à finasser en utilisant les registres auto-incrémentés pour faire mes « out » (j'aurais pu, vu que les registres se suivent). Je préfère faire simple pour l'instant.
La notation binaire avec les séparateurs, c'est une facilité sjasm pour s'y retrouver dans les champs de bits.
C'est purement informatif et ça génère bien le nombre attendu sans les séparateurs.
Maintenant que j'y pense, l'accès mémoire et les op. logiques dans le bloc di/ei , c'est moyen.
Je pourrais préparer ça en dehors, stocker dans deux registres et enchainer les out.
Mais je ne pense pas que ce soit la cause de mon problème, au pire ça bloque un peu le système.
Merci pour vos suggestions. Edité par zone Le 19/11/2023 à 16h46
Hello,
Alors, déjà, quel support vises-tu ? Cartouche ? MSX-DOS ?
Est-ce que tu veux essayer de gratter le moindre cycle CPU ou pas ?
Si je demande tout ça, c'est pour savoir si tu as une bonne raison de ne pas utiliser le BIOS.
Avec le BIOS, tu aurais juste besoin de faire un truc du genre :
Sinon, autant je trouve les outils de debug de openMSX pas terribles (notamment comparés à ceux de Emulicious), autant son viewer de registres du VDP est super pratique pour voir si ta configuration est correcte. Edité par aoineko Le 19/11/2023 à 17h13
Alors, déjà, quel support vises-tu ? Cartouche ? MSX-DOS ?
Est-ce que tu veux essayer de gratter le moindre cycle CPU ou pas ?
Si je demande tout ça, c'est pour savoir si tu as une bonne raison de ne pas utiliser le BIOS.
Avec le BIOS, tu aurais juste besoin de faire un truc du genre :
Code ASM :
CHGMOD = $005F SetScreen4: ld a, 4 call CHGMOD
Sinon, autant je trouve les outils de debug de openMSX pas terribles (notamment comparés à ceux de Emulicious), autant son viewer de registres du VDP est super pratique pour voir si ta configuration est correcte. Edité par aoineko Le 19/11/2023 à 17h13
On est toujours ignorant avant de savoir.
Merci !
Je veux faire une megarom MSX2. La megarom, c'est pour embarquer toutes les données avec un accès simple.
Pour l'instant, je fais mes tests depuis le basic, avec un bload c'est plus rapide pour tester des bouts de code.
Je n'avais pas trouvé la fonction bios pour changer au dela des modes graphiques MSX1 (screen 0 et screen 1, je le fais au bios).
Ce n'est pas rentable d'utiliser l'accès direct VDP pour un changement de résolution, on est d'accord.
J'ai regardé la doc de CHGMOD, on ne peut pas changer la taille des sprites (8×8 ou 16×16 je crois). Pour ça, il faut repasser avec un accès VDP ? Je n'ai pas trouvé de fonction bios pour ça.
J'ai juste trouvé
008Ah (GSPSIZ)
Function: Returns the current sprite size
Je crois que je suis bon pour me taper encore pas mal de doc…
je reviens dans deux mois
Je vais utiliser le bios et essayer d'afficher des caractères redéfinis à l'écran. Cette fois avec le port 0x98. J'arrive déjà à le faire en SCREEN 1, plus qu'à redéfinir les caractères.
Par curiosité, si quelqu'un peut me dire ce qui manquait dans mon code d'init GRAPHIC4, ça m'intéresse. Edité par zone Le 19/11/2023 à 17h27
Je veux faire une megarom MSX2. La megarom, c'est pour embarquer toutes les données avec un accès simple.
Pour l'instant, je fais mes tests depuis le basic, avec un bload c'est plus rapide pour tester des bouts de code.
Je n'avais pas trouvé la fonction bios pour changer au dela des modes graphiques MSX1 (screen 0 et screen 1, je le fais au bios).
Ce n'est pas rentable d'utiliser l'accès direct VDP pour un changement de résolution, on est d'accord.
J'ai regardé la doc de CHGMOD, on ne peut pas changer la taille des sprites (8×8 ou 16×16 je crois). Pour ça, il faut repasser avec un accès VDP ? Je n'ai pas trouvé de fonction bios pour ça.
J'ai juste trouvé
008Ah (GSPSIZ)
Function: Returns the current sprite size
Je crois que je suis bon pour me taper encore pas mal de doc…
je reviens dans deux mois
Je vais utiliser le bios et essayer d'afficher des caractères redéfinis à l'écran. Cette fois avec le port 0x98. J'arrive déjà à le faire en SCREEN 1, plus qu'à redéfinir les caractères.
Par curiosité, si quelqu'un peut me dire ce qui manquait dans mon code d'init GRAPHIC4, ça m'intéresse. Edité par zone Le 19/11/2023 à 17h27
Effectivement, le debugger VDP de OpenMSX est vraiment bien.
Je me suis amusé à placer les bits « à la main » pour initialiser GRAPHIC 4 : ça fonctionne.
Quand je trace mon code, il n'y a pas de modification des registres R#0 et R#1 du VDP.
Je me suis planté quelque part, je vais reprendre la doc.
Je me suis amusé à placer les bits « à la main » pour initialiser GRAPHIC 4 : ça fonctionne.
Quand je trace mon code, il n'y a pas de modification des registres R#0 et R#1 du VDP.
Je me suis planté quelque part, je vais reprendre la doc.
zone :
Par curiosité, si quelqu'un peut me dire ce qui manquait dans mon code d'init GRAPHIC4, ça m'intéresse.
Il manque un 'out ($99),a' après le 'ld a,128'.
Et le bit 0 du R#0 doit être à zéro, or ton 'or' vient le mettre à 1. Edité par Metalion Le 19/11/2023 à 20h30
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)
zone :
J'ai regardé la doc de CHGMOD, on ne peut pas changer la taille des sprites (8×8 ou 16×16 je crois). Pour ça, il faut repasser avec un accès VDP ? Je n'ai pas trouvé de fonction bios pour ça.
Effectivement, je ne vois rien dans les fonctions bu BIOS pour choisir la taille des sprites.
Pour une MegaROM, la cartouche ne sera visible par le Z80 que dans les page 1 et 2 (adresse 4000h~BFFFh).
Donc la page 0 est disponible pour le BIOS, à moins que tu l'utilises pour mettre la RAM (sur MSX2 tu es sûr d'avoir de la RAM dispo en page 0).
Après, personnellement, pour ma librairie de jeu en C, je n'utilise que les accès direct pour plus de performance.
Par contre, si tu fais ça, il va falloir que tu digères toute la doc du V9938.
Et quand tu auras fini, il faudra aussi que tu connaisses certaines subtilités comme les temps d'accès minimal à VRAM en fonction du contexte. Edité par aoineko Le 19/11/2023 à 21h55
On est toujours ignorant avant de savoir.
Merci Metalion pour la correction.
Je crois que l'erreur dans le OR mettait bien le bazar , car quand je tapais des caractères en retour de programme, j'avais des glyphes sans rapport qui s'affichaient. Encore plus amusant, ça survivait à un reset (commande « reset » depuis la console OpenMSX).
Et toujours plus curieux, les touches de fonction envoyaient les bons caractères à l'affichage (le 'c' de « color » était bien affiché, alors que les mêmes lettres tapées au clavier renvoyait des caractères aléatoirse de la table ascii 8 bits.
Merci Aoineko pour le coup de main et surtout l'article sur les temps d'accès minimaux pour le VDP.
Il faudra peut-être jouer la sécurité sur les accès, alors…
Je crois que l'erreur dans le OR mettait bien le bazar , car quand je tapais des caractères en retour de programme, j'avais des glyphes sans rapport qui s'affichaient. Encore plus amusant, ça survivait à un reset (commande « reset » depuis la console OpenMSX).
Et toujours plus curieux, les touches de fonction envoyaient les bons caractères à l'affichage (le 'c' de « color » était bien affiché, alors que les mêmes lettres tapées au clavier renvoyait des caractères aléatoirse de la table ascii 8 bits.
Merci Aoineko pour le coup de main et surtout l'article sur les temps d'accès minimaux pour le VDP.
Il faudra peut-être jouer la sécurité sur les accès, alors…
Oui, tu peux commencer avec des accès "lent" (à 29 t-states) qui sont 100% safe, puis tu pourra optimiser plus trad.
Si tu pars pour gérer le VDP avec des accès direct, je te conseil ce tutoriel : https://map.grauw.nl/articles/vdp_tut.php
Amuse-toi bien
Si tu pars pour gérer le VDP avec des accès direct, je te conseil ce tutoriel : https://map.grauw.nl/articles/vdp_tut.php
Amuse-toi bien
On est toujours ignorant avant de savoir.
29 t-states ? D'après ma doc z80 (le PDF de chez zylog , rev.2016) un OUTI c'est 16 t-s , et un OTIR (plus pratique je trouve) c'est 21 t-states.
Je ne vois pas comment faire plus rapide que OTIR (ou éventuellement des OUTI enchainés, mais bof) pour copier les données dans la vram.
Cependant d'après le tableau que tu as fait avec tes mesures, la limite pour les modes graphiques ou semi-graphiques, c'est 15 t-s.
Donc pourquoi 29 t-states (presque le double) ? Edité par zone Le 20/11/2023 à 14h40
Je ne vois pas comment faire plus rapide que OTIR (ou éventuellement des OUTI enchainés, mais bof) pour copier les données dans la vram.
Cependant d'après le tableau que tu as fait avec tes mesures, la limite pour les modes graphiques ou semi-graphiques, c'est 15 t-s.
Donc pourquoi 29 t-states (presque le double) ? Edité par zone Le 20/11/2023 à 14h40
29 t-states, c'est le temps minimum nécessaire entre l'envoi de données vers le VDP du MSX1. Ce qui rend impossible l'utilisation de OTIR sur MSX1.
La solution la plus rapide pour remplacer un OTIR, c'est ces 2 lignes de code, car il faut prendre en compte les wait states du Z80 sur MSX :
Si tu développes sur MSX2, les contraintes de timing du V9938 sont un peu plus souples (mais les wait states existent toujours).
Edité par Metalion Le 20/11/2023 à 18h28
La solution la plus rapide pour remplacer un OTIR, c'est ces 2 lignes de code, car il faut prendre en compte les wait states du Z80 sur MSX :
Code :
outi ; 18 t-states = 16 + 2 wait states
jp nz,$-2 ; 11 t-states = 10 + 1 wait state
Si tu développes sur MSX2, les contraintes de timing du V9938 sont un peu plus souples (mais les wait states existent toujours).
Edité par Metalion Le 20/11/2023 à 18h28
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)
@Zone je pense que tu lis les vitesses a l'envers. C'est un intervalle de temps minimal entre deux accès, donc plus l'intervalle est petit et plus on peut écrire vite et plus l'intervalle est gros et plus c'est lent.
29 t-states (ou "cycles CPU") c'est donc une vitesse plutôt lente. Celle qui permet d'écrire dans n'importe quelle mode et sur n'importe quel MSX de façon sûr.
L'intervale le plus court c'est 12 t-states ; non pas que le VDP ne puisse être accédé plus vite dans certaines conditions, mais coté Z80 c'est l'instruction I/O la plus rapide (des out (n),a). Edité par aoineko Le 20/11/2023 à 23h51
29 t-states (ou "cycles CPU") c'est donc une vitesse plutôt lente. Celle qui permet d'écrire dans n'importe quelle mode et sur n'importe quel MSX de façon sûr.
L'intervale le plus court c'est 12 t-states ; non pas que le VDP ne puisse être accédé plus vite dans certaines conditions, mais coté Z80 c'est l'instruction I/O la plus rapide (des out (n),a). Edité par aoineko Le 20/11/2023 à 23h51
On est toujours ignorant avant de savoir.
aoineko :
non pas que le VDP ne puisse être accédé plus vite dans certaines conditions
Et pourtant, c'est bien le cas : 29 t-states c'est le délai le plus long, pour un accès durant le traçage sur MSX1. Le délai est plus court en HBLANK et VBLANK (et sur MSX2). Edité par Metalion Le 21/11/2023 à 07h11
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 ne dis pas le contraire
Par "plus vite", je parle d'intervalle inférieur à 12 t-states qui semblent théoriquement gérable par le VDP dans certaines conditions (durant le V-Blank par ex.) mais qu'on ne peut pas exploiter sur MSX vu que l'instruction la plus rapide fait 12 t-states.
Par "plus vite", je parle d'intervalle inférieur à 12 t-states qui semblent théoriquement gérable par le VDP dans certaines conditions (durant le V-Blank par ex.) mais qu'on ne peut pas exploiter sur MSX vu que l'instruction la plus rapide fait 12 t-states.
On est toujours ignorant avant de savoir.
ça me rappelle, j'avais lancé ça à une époque...
https://msxvillage.fr/forum/topic.php?id=2518#m59838
https://msxvillage.fr/forum/topic.php?id=2518#m59838
Le MSXien le plus à l'ouest
... ou presque 
Je n'avais pas pensé aux cas où les sprites sont désactivés ou le tracé pendant hbl/vbl (j'avais bien compris que les « t-states » corresponaient à un intervalle minimum entre deux tracés). Pour moi ça devrait aller vu que je vise le MSX/2.
Il y a beaucoup de choses sur ce forum (rapport au post de MSXosaure), ça vaut le coup d'explorer .
Je n'ai pas posté depuis un moment, car je suis coincé sur mon tracé en mode 3 (screen 4).
Je définis l'adresse mémoire du tracé à $1800 (adresse des caractères), puis je trace. Ce qui apparait à l'écran n'a aucun rapport.
J'ai l'impression qu'il manque un truc, et que l'adresse du début de l'affichage n'est pas $1800.
Pourtant dans mes docs , ce n'est pas abordé.
Mais en explorant les registres du VDP avec le debugger OpenMSX, j'ai trouvé le registre 2 (pattern name table base address register).
Il est à $c00 par défaut. Si je le passe à $1800, ça a l'air d'aller nettement mieux.
Bizarre ? Normal ? J'ai rien compris ?
Edité par zone Le 22/11/2023 à 16h57
Il y a beaucoup de choses sur ce forum (rapport au post de MSXosaure), ça vaut le coup d'explorer .
Je n'ai pas posté depuis un moment, car je suis coincé sur mon tracé en mode 3 (screen 4).
Je définis l'adresse mémoire du tracé à $1800 (adresse des caractères), puis je trace. Ce qui apparait à l'écran n'a aucun rapport.
Code :
ld a,0 ; adresse video ram, partie haute (reg.14)
di
out ($99),a ; on reste dans la partie basse
ld a,14+128
out ($99),a ; écriture dans registre 14
ld a,0 ; adresse vram (partie basse)
out ($99),a
ld a,$18+64 ; adresse vram (partie haute) pour écrire (+64d) à 0x1800
out ($99),a
ei
ld c,3
draw_loop_main:
ld b,255
ld hl,message
draw_loop:
ld a,(hl)
inc hl
out ($98),a
dec b
jr nz,draw_loop
dec c
jr nz,draw_loop_main
J'ai l'impression qu'il manque un truc, et que l'adresse du début de l'affichage n'est pas $1800.
Pourtant dans mes docs , ce n'est pas abordé.
Mais en explorant les registres du VDP avec le debugger OpenMSX, j'ai trouvé le registre 2 (pattern name table base address register).
Il est à $c00 par défaut. Si je le passe à $1800, ça a l'air d'aller nettement mieux.
Bizarre ? Normal ? J'ai rien compris ?
Edité par zone Le 22/11/2023 à 16h57
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie