La Place des Développeurs Projet Carwar
Reprise du message précédent
aoineko :
Quand on écris dans la VRAM sans passer par le BIOS, y a pas moyen de copier un block de donnée sans passer par les coordonnées X/Y (en utilisant directement l'adresse) ?
Ce sont les bases de l'accès à la VRAM en assembleur, et c'est expliqué dans tous les bouquins.
Un peu de recherche et de lecture devrait t'apporter la réponse.
Le forum est là pour aider, et répondre aux questions, mais il faut commencer par chercher un peu soi-même
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)
Metalion :
Le forum est là pour aider, et répondre aux questions, mais il faut commencer par chercher un peu soi-même
Ça fait 2 semaines que je bouffe de la doc MSX tous les soirs...
C'est vraiment pas évident de s'y retrouver pour quelqu'un qui n'a jamais programmé sur MSX (ni sur aucun ordi des années 80) ! Surtout que tout ce que j'ai lu au début, je n'y comprenais pas grand chose. Ceci dit, libre à vous de pas répondre si vous trouvez une question trop bête.
Sinon, pour la solution de MSXosaure, c'est de la copie octet par octet non ? Je chercherai s'il n'existait pas une copie par bloc. Je vais relire la doc au cas ou qq chose m'ait échappé...
On est toujours ignorant avant de savoir.
Je pense que les gens du Village sont là pour t'aider, Aoineko
Et quand on voit ce que tu parviens à faire sans rien connaître au départ du MSX, j'avoue que je suis assez bluffé
Alors continuons tous ensemble vers peut-être un nouveau jeu qui fera date dans le petit monde du MSX
Et quand on voit ce que tu parviens à faire sans rien connaître au départ du MSX, j'avoue que je suis assez bluffé
Alors continuons tous ensemble vers peut-être un nouveau jeu qui fera date dans le petit monde du MSX
Désolé pour ma réponse un peu sèche
Mais j'ai un peu de mal à comprendre que tu ne saches pas répondre toi même à cette question, vu tout ce que tu as déjà accompli jusqu'à maintenant, et tout ce que tu sembles connaitre sur la programmation en assembleur du système MSX.
Soit ... Ce n'est pas grave, après un café et une gaufre au chocolat, mon lundi matin semble mieux parti
La VRAM, on peut y accéder octet par octet, par la méthode donnée par MSXOsaure.
Une remarque, les instructions EX (SP),HL de temporisation ne sont utiles que sur MSX1, en MSX2 on peut les supprimer.
Pour la copie en bloc, tu la connais déjà, il s'agit de la commande HMMC, abordée et expliquée dans le sujet Projet Ambidex
Mais j'ai un peu de mal à comprendre que tu ne saches pas répondre toi même à cette question, vu tout ce que tu as déjà accompli jusqu'à maintenant, et tout ce que tu sembles connaitre sur la programmation en assembleur du système MSX.
Soit ... Ce n'est pas grave, après un café et une gaufre au chocolat, mon lundi matin semble mieux parti
La VRAM, on peut y accéder octet par octet, par la méthode donnée par MSXOsaure.
Une remarque, les instructions EX (SP),HL de temporisation ne sont utiles que sur MSX1, en MSX2 on peut les supprimer.
Pour la copie en bloc, tu la connais déjà, il s'agit de la commande HMMC, abordée et expliquée dans le sujet Projet Ambidex
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)
En fait, j'ai du mal formuler ma question. C'était juste pour savoir s'il existait un moyen de faire une copie d'un bloc en RAM vers la VRAM en passant par des adresses et non pas le système de coordonnées X/Y.
Si j'ai bien compris, ce n'est pas possible. Soit je passe par l'adresse directe et je dois alors faire la copie octet par octet, soit je fait une copie par bloc (HMMC) et dans ce cas, je dois utiliser l'espace 2d (x/y).
Je trouve pas ça très pratique pour écrire dans les zones réservés aux sprites, mais on va faire avec.
Si j'ai bien compris, ce n'est pas possible. Soit je passe par l'adresse directe et je dois alors faire la copie octet par octet, soit je fait une copie par bloc (HMMC) et dans ce cas, je dois utiliser l'espace 2d (x/y).
Je trouve pas ça très pratique pour écrire dans les zones réservés aux sprites, mais on va faire avec.
On est toujours ignorant avant de savoir.
Pour tester, j'ai envoyé mes données de sprites (une entrée dans la TAS, TGS et TCS) via HMMC vers la partie visible de l'écran... et ça à l'air d'être bon (je vois les pixels correspondant aux octets envoyés) ! Par contre, quand je regarde le contenu de ma VRAM via BlueMSX, je trouve mes données à des adresses incohérentes (ne correspondant pas au X + Y * 256 ou j'ai fait ma copie). Vu que j'imagine que le visualiseur de VRAM de BlueMSX fonctionne, j'ai pas du capter qq chose... 
Edité par
aoineko
Le 31/01/2011 à 13h32
Edité par
aoineko
Le 31/01/2011 à 13h32
On est toujours ignorant avant de savoir.
aoineko :
En fait, j'ai du mal formuler ma question. C'était juste pour savoir s'il existait un moyen de faire une copie d'un bloc en RAM vers la VRAM en passant par des adresses et non pas le système de coordonnées X/Y.
Si j'ai bien compris, ce n'est pas possible. Soit je passe par l'adresse directe et je dois alors faire la copie octet par octet, soit je fait une copie par bloc (HMMC) et dans ce cas, je dois utiliser l'espace 2d (x/y).
Je trouve pas ça très pratique pour écrire dans les zones réservés aux sprites, mais on va faire avec.
Si j'ai bien compris, ce n'est pas possible. Soit je passe par l'adresse directe et je dois alors faire la copie octet par octet, soit je fait une copie par bloc (HMMC) et dans ce cas, je dois utiliser l'espace 2d (x/y).
Je trouve pas ça très pratique pour écrire dans les zones réservés aux sprites, mais on va faire avec.
Si c'est possible ... Il existe une solution intermédiaire.
Le VDP accepte les données en écriture séquentielle, c'est à dire que le Z80 peut envoyer les données l'une derrière l'autre et le VDP les transfèrera, en incrémentant lui même l'adresse en VRAM après chaque donnée.
Voici un exemple en syntaxe asMSX (tiré d'un projet de jeu sur MSX2, en chantier depuis plusieurs années ...
)Code :
; Chargement des données sprites
VRAM=18000h
ld a,VRAM>>14 ; Shift right adresse VRAM sur 14 bits
di
out [VDP],a
ld a,80h+14
out [VDP],a
ld a,VRAM&255
out [VDP],a
ld a,40h+(VRAM>>8)&63
out [VDP],a
ld bc,(VDP-1)
ld hl,Level1_SPR
REPT 11
otir ; 11x256 = 2816 octets
ENDR
ei
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)
Et en utilisant LDIRVM ? C'est clair qu'en utilisant le BIOS tu perdras en rapidité mais c'est exactement ce que tu demandes à savoir un transfert de bloc RAM vers VRAM.
MSX un jour, MSX toujours !
Metalion :
Il est possible de paramétrer le VDP pour faire sur le port d'écriture en VRAM une écriture séquentielle, c'est à dire que le Z80 envoie les données l'une derrière l'autre et le VDP les transfère, en incrémentant lui même l'adresse en VRAM à chaque donnée.
J'utilise les séries de outi (je connaissais pas otir) pour envoyer les paramètres des commandes VDP. Le problème, c'est qu'on doit répéter ces instructions un nombres de fois qui ne peut être variable. Ceci dit, pour des données dont la taille est fixe (genre une entrée dans les tables de sprites), c'est une très bonne solution. J'essaye ça ce soir. Merci.
Pour ce qui est du Bios, j'essaye autant que possible d'éviter de l'utiliser.
On est toujours ignorant avant de savoir.
Bon, après moult tests, j'en arrive à 2 conclusions :
Conclusion, le fait que mon sprite ne s'affiche pas viens surement d'ailleurs !
J'ai bien scruté la valeur des registres du VDP et tout semble ok.
Reste les données en elles-mêmes.
Pour mes tests je rempli juste la 1er entrée de chaque table avec pour la TGS :
Pour la TAS :
Et pour la TCS :
Vous voyez qq chose qui cloche ?
Edité par
aoineko
Le 01/02/2011 à 21h30
- Le visualiseur de VRAM de BlueMSX ne marche pas (ou je ne sais pas l'utiliser),
- Que ce soit via un HMMC ou des otir mes données semblent bien en place.
Conclusion, le fait que mon sprite ne s'affiche pas viens surement d'ailleurs !
J'ai bien scruté la valeur des registres du VDP et tout semble ok.
| RO | 0e | Bits 1,2 et 3 à 1 pour mode 8 |
| R1 | 60 | Bits 3 et 4 à 0 pour mode 8; Bits 0 et 1 à 0 pour sprite 8x8 sans MAG |
| R2 | 3f | 1f première page (0000h), 3f seconde (1000h) |
| R3 | 80 | |
| R4 | 00 | |
| R5 | ee | Partie basse adresse TAS 01EEh pour F700h |
| R6 | 1f | Adresse TGS 001Fh pour F800h |
| R7 | 04 | |
| R8 | 99 | Bit 1 à 0 pour afficher les sprites |
| R9 | b1 | Bit 7 à 1 pour mode 212 lignes |
| R1O | 00 | |
| R11 | 01 | Partie haute adresse TAS 01EEh pour F700h |
Reste les données en elles-mêmes.
Pour mes tests je rempli juste la 1er entrée de chaque table avec pour la TGS :
Code CPP :
0x7C, // .#####.. 0xEE, // ###.###. 0xEE, // ###.###. 0xEE, // ###.###. 0xEE, // ###.###. 0xEE, // ###.###. 0xEE, // ###.###. 0x7C, // .#####..
Pour la TAS :
Code CPP :
0x40, 0x40, 0, 0 // Position 64/64, sprite 0
Et pour la TCS :
Code CPP :
0x0F, 0x0F, 0x0F, 0x0F, 0x0F, 0x0F, 0x0F, 0x0F // couleur blanche
Vous voyez qq chose qui cloche ?
Edité par
aoineko
Le 01/02/2011 à 21h30
On est toujours ignorant avant de savoir.
Quand je me balade dans la zone non visible avec ma voiture (et donc que j'écrase les données après D400h) je vois parfois mon sprite apparaitre (le 0). J'en conclu que le problème viens de la TAS/TCS et que les données du TGS sont bonnes. Mais ça m'avance pas beaucoup...
On est toujours ignorant avant de savoir.
Pour afficher les sprites, c'est le bit 1 du R#8 qui doit être à zéro, pas le bit 2. Tu vas me dire qu'avec la valeur $99, la condition est remplie ... Oui, mais le registre R#8 contient toute une série de paramètres auquels il ne vaut mieux pas toucher (structure physique VRAM, paramétrage du bus de couleur, souris, crayon optique ...). Dans ton cas, seul le bit 1 doit être modifié, tout le reste doit rester tel qu'à l'initialisation. Je te conseille donc de prendre la valeur telle quelle et de seulement mettre le bit 1 à zéro.
Autre chose, ta couleur n'est pas bonne ...
En SCREEN8, la couleur est codée en RGB sur 8 bits : G2 G1 G0 R2 R1 R0 B1 B0.
La valeur $0F donne donc une couleur dans l'espace RGB qui doit être du mauve foncé.
Pour avoir du blanc, c'est la valeur $FF que tu dois utiliser.
Le codage des TAS et TGS est correct ...
A part ça je ne vois rien d'autre de flagrant ...
Il faudrait vérifier si tu écris les données aux bonnes adresses dans la VRAM.
Autre chose, ta couleur n'est pas bonne ...
En SCREEN8, la couleur est codée en RGB sur 8 bits : G2 G1 G0 R2 R1 R0 B1 B0.
La valeur $0F donne donc une couleur dans l'espace RGB qui doit être du mauve foncé.
Pour avoir du blanc, c'est la valeur $FF que tu dois utiliser.
Le codage des TAS et TGS est correct ...
A part ça je ne vois rien d'autre de flagrant ...
Il faudrait vérifier si tu écris les données aux bonnes adresses dans la VRAM.
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)
Metalion :
Pour afficher les sprites, c'est le bit 1 du R#8 qui doit être à zéro, pas le bit 2. Tu vas me dire qu'avec la valeur $99, la condition est remplie ... Oui, mais le registre R#8 contient toute une série de paramètres auquels il ne vaut mieux pas toucher (structure physique VRAM, paramétrage du bus de couleur, souris, crayon optique ...). Dans ton cas, seul le bit 1 doit être modifié, tout le reste doit rester tel qu'à l'initialisation. Je te conseille donc de prendre la valeur telle quelle et de seulement mettre le bit 1 à zéro.
Autre chose, ta couleur n'est pas bonne ...
En SCREEN8, la couleur est codée en RGB sur 8 bits : G2 G1 G0 R2 R1 R0 B1 B0.
La valeur $0F donne donc une couleur dans l'espace RGB qui doit être du mauve foncé.
Pour avoir du blanc, c'est la valeur $FF que tu dois utiliser.
Le codage des TAS et TGS est correct ...
A part ça je ne vois rien d'autre de flagrant ...
Il faudrait vérifier si tu écris les données aux bonnes adresses dans la VRAM.
Autre chose, ta couleur n'est pas bonne ...
En SCREEN8, la couleur est codée en RGB sur 8 bits : G2 G1 G0 R2 R1 R0 B1 B0.
La valeur $0F donne donc une couleur dans l'espace RGB qui doit être du mauve foncé.
Pour avoir du blanc, c'est la valeur $FF que tu dois utiliser.
Le codage des TAS et TGS est correct ...
A part ça je ne vois rien d'autre de flagrant ...
Il faudrait vérifier si tu écris les données aux bonnes adresses dans la VRAM.
Pour le R#8, c'est bien le bit 1 (le 2e
) que je mets à zéro.Quant aux couleurs, la doc semble dire qu'en mode 8 on a 16 couleurs prédéfini. Le FFh étant le blanc. Edité par aoineko Le 01/02/2011 à 21h30
On est toujours ignorant avant de savoir.
aoineko :
Quant aux couleurs, la doc semble dire qu'en mode 8 on a 16 couleurs prédéfini. Le FFh étant le blanc.
Oui, tu as raison, autant pour moi.
Les sprites en mode SCREEN8 ne peuvent avoir que 16 couleurs prédéfinies, et le blanc est bien la valeur $0F.
As-tu pu vérifier si les données arrivaient aux bonnes adresses ?
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)
En essayant de copier mes données TAS/TCS un peu avant dans la VRAM je vois apparaitre des choses, parfois un des mes sprites mis en TGS. Y a qq chose de particulier avec l'adressage des tables TAS et TCS ? Pour la TCS, je sais qu'on passe d'une entrée à l'autre en ajoutant 16 à l'adresse (même en mode 8x8), mais à part ça, je vois pas...
Comment faire ? Le viewer de VRAM de BlueMSX ne semble pas fonctionner. Par exemple, il voit pas mes données en 1D400h ou je stock mes sprites alors que tout fonctionne très bien. Par contre, via les HMMC, j'ai retiré un offset pour déplacer mes copies vers la partie visible de l'écran et tout avait l'air bon. Edité par aoineko Le 01/02/2011 à 21h59
Metalion :
As-tu pu vérifier si les données arrivaient aux bonnes adresses ?
Comment faire ? Le viewer de VRAM de BlueMSX ne semble pas fonctionner. Par exemple, il voit pas mes données en 1D400h ou je stock mes sprites alors que tout fonctionne très bien. Par contre, via les HMMC, j'ai retiré un offset pour déplacer mes copies vers la partie visible de l'écran et tout avait l'air bon. Edité par aoineko Le 01/02/2011 à 21h59
On est toujours ignorant avant de savoir.
aoineko :
Comment faire ? Le viewer de VRAM de BlueMSX ne semble pas fonctionner
Si, il fonctionne, je l'ai souvent utilisé.
Re-vérifie ton code, si tu ne vois pas tes données dans le VRAM au bon endroit, c'est que le transfert ne s'est pas fait correctement.
Tu peux poster ton code de transfert des données sprites ?
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)
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie