La Place des Développeurs Projet Carwar
aoineko
Membre non connecté
Conseiller Municipal
Reprise du message précédent
En fait, je regarde la valeur des registres VDP via le débuggeur de BlueMSX (quand je suis en mode 8). Si ça se trouve, y a un bug dans BlueMSX.EDIT :
Je passe en mode 8 en changent directement les registres R#0 à R#2. Je touche pas aux autres... c'est donc certainement normal que j'ai des valeurs bizarre dans mes registres d'adressages. Je vais me faire une routine d'initialisation plus propre.
Par contre, je vois pas de registre pour setter l'adresse des zones TCS (table des couleurs sprite) et TPL (table de palette) ; elles sont dépendante de l'adresse de la TAS et de la TGS ? Edité par aoineko Le 29/01/2011 à 17h55
On est toujours ignorant avant de savoir.
assembleur et périphériques MSX
il n'y a pas de TGS la couleur est codée dans la TAS
octet 0 coordonée verticale
octet 1 coordonnée horizontale
octet 2 nom ( numéro )
octet 4 b7,0,0,0 couleur
le 4éme octet contient dans ses bits 0 a 3 la couleur du sprite les bits 4 a 6 sont a 0 le bit 7 est le bit de retard
il n'y a pas de TGS la couleur est codée dans la TAS
octet 0 coordonée verticale
octet 1 coordonnée horizontale
octet 2 nom ( numéro )
octet 4 b7,0,0,0 couleur
le 4éme octet contient dans ses bits 0 a 3 la couleur du sprite les bits 4 a 6 sont a 0 le bit 7 est le bit de retard
aoineko
Membre non connecté
Conseiller Municipal
Jipe :
assembleur et périphériques MSX
il n'y a pas de TGS la couleur est codée dans la TAS
octet 0 coordonée verticale
octet 1 coordonnée horizontale
octet 2 nom ( numéro )
octet 4 b7,0,0,0 couleur
le 4éme octet contient dans ses bits 0 a 3 la couleur du sprite les bits 4 a 6 sont a 0 le bit 7 est le bit de retard
il n'y a pas de TGS la couleur est codée dans la TAS
octet 0 coordonée verticale
octet 1 coordonnée horizontale
octet 2 nom ( numéro )
octet 4 b7,0,0,0 couleur
le 4éme octet contient dans ses bits 0 a 3 la couleur du sprite les bits 4 a 6 sont a 0 le bit 7 est le bit de retard
Tu veux dire, pas de TCS (table des couleurs sprite) et TPL (table de palette) ? La TGS, c'est le nom de la table des formes dans Le livre du MSX2. On s'y perd avec tout ces acronymes.
C'est bizarre, que ce soit Le livre du MSX2 ou Pratique du MSX2 ils donnent tous des adresses « stanbard » pour la TCS et la TPL dans la description du mode 8. Si ces tables ne servent pas, pourquoi les évoquer ?
Bon, en gros, pour résumer, pour utiliser les sprites en mode 8, j'ai juste besoin de placer la TGS et la TAS qq part en VRAM ?
On est toujours ignorant avant de savoir.
par curiosité as tu déja essayé les sprites en screen 8 sous basic ?
les couleurs sont limitées au niveau palette , pas de couleurs franches comme en screen 5
4 bits = 16 couleurs sur 256
au fait j'ai essayé blueMSX avec un jeu en screen8 au hasard les registres sont bons , il faut juste initialiser les tiens
les couleurs sont limitées au niveau palette , pas de couleurs franches comme en screen 5
4 bits = 16 couleurs sur 256
au fait j'ai essayé blueMSX avec un jeu en screen8 au hasard les registres sont bons , il faut juste initialiser les tiens
Cela dépend du mode sélectionné pour les sprites.
Si c'est le mode 2, il y a bien une TCS, mais elle est automatiquement située 512 octets avant le début de la TAS.
Pour rappel, dans le mode 2, le sprite 16x16 possède une couleur par ligne.
Il n'y a pas de table de palette.
La palette de couleur utilisée est celle définie par les registres spécifiques du VDP.
Et elle n'est pas recopiée en VRAM.
Si c'est le mode 2, il y a bien une TCS, mais elle est automatiquement située 512 octets avant le début de la TAS.
Pour rappel, dans le mode 2, le sprite 16x16 possède une couleur par ligne.
Il n'y a pas de table de palette.
La palette de couleur utilisée est celle définie par les registres spécifiques du VDP.
Et elle n'est pas recopiée en 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 :
Cela dépend du mode sélectionné pour les sprites.
Si c'est le mode 2, il y a bien une TCS, mais elle est automatiquement située 512 octets avant le début de la TAS.
Pour rappel, dans le mode 2, le sprite 16x16 possède une couleur par ligne.
Si c'est le mode 2, il y a bien une TCS, mais elle est automatiquement située 512 octets avant le début de la TAS.
Pour rappel, dans le mode 2, le sprite 16x16 possède une couleur par ligne.
Pour quelques éclaircissements au niveau du mode 2 des sprites sur MSX suivre cette discussion.
En mode 1 les sprites n'ont qu'une couleur qui est définie par le 4èmé octet du plan de sprite correspondant de la TAS
En mode 2 les sprites peuvent avoir une couleur par la ligne définie dans la TCS, le 4ème octet de la TAS ne sert plus à rien!
Metalion :
Il n'y a pas de table de palette.
La palette de couleur utilisée est celle définie par les registres spécifiques du VDP.
Et elle n'est pas recopiée en VRAM.
La palette de couleur utilisée est celle définie par les registres spécifiques du VDP.
Et elle n'est pas recopiée en VRAM.
Mais alors comment la palette est-elle sauvegardée quand on enregistre un fichier si elle n'est pas dans la VRAM
Et TPL ça correspond à quoi dans la VRAM alors?
Le MSXien le plus à l'ouest ... ou presque
aoineko
Membre non connecté
Conseiller Municipal
Jipe :
par curiosité as tu déja essayé les sprites en screen 8 sous basic ?
Le basic est moi, ça fait 53.
Jipe :
les couleurs sont limitées au niveau palette , pas de couleurs franches comme en screen 5
4 bits = 16 couleurs sur 256
4 bits = 16 couleurs sur 256
Les 16 couleurs décrites dans
http://www.msxvillage.fr/forum/topic.php?id=332 ?
Jipe :
au fait j'ai essayé blueMSX avec un jeu en screen8 au hasard les registres sont bons , il faut juste initialiser les tiens
J'ai nettoyé mon code... et j'ai découvert que j'étais en 256x192 à cause d'un bug qui écrasé le bit de résolution verticale du R#9.
Par contre, je viens de voir qu'on gagne pas en résolution ; c'est juste les bandes noires qui deviennent plus étroites.
On est toujours ignorant avant de savoir.
aoineko
Membre non connecté
Conseiller Municipal
J'ai fait le ménage dans l'organisation de ma VRAM et j'ai récupéré 33*256 pixels sur la première page et 44*256 sur la seconde.
C'est marrant le hasard quand même... mes sprites qui ont presque 15 ans et qui étaient fait pour le PC font juste 11 pixels de haut ; juste de quoi en mettre 4 en VRAM.
Sinon, dans le Livre du MSX2 il est dit :
Ce qui veut dire qu'en 8x8, je ne peux pas utiliser les 256 entrées de la TAS et que je suis limités à 64 !? Les 3/4 de la mémoire étant alors inutilisé.
J'espère avoir mal compris... mais le Pratique de MSX2 semble dire la même chose. Edité par aoineko Le 30/01/2011 à 09h13
C'est marrant le hasard quand même... mes sprites qui ont presque 15 ans et qui étaient fait pour le PC font juste 11 pixels de haut ; juste de quoi en mettre 4 en VRAM.
Sinon, dans le Livre du MSX2 il est dit :
Citation :
La TGS est organisée comme suit : les blocs de 8x8 octets sont groupés 4 par 4. Si le sprite est au
format 8x8 ou 16x16 avec le bit d'agrandissement = 1, un seul bloc de 8 octets est occupé sur les 4,
les 3 autres n'étant pas considérés par le VDP.
format 8x8 ou 16x16 avec le bit d'agrandissement = 1, un seul bloc de 8 octets est occupé sur les 4,
les 3 autres n'étant pas considérés par le VDP.
Ce qui veut dire qu'en 8x8, je ne peux pas utiliser les 256 entrées de la TAS et que je suis limités à 64 !? Les 3/4 de la mémoire étant alors inutilisé.
J'espère avoir mal compris... mais le Pratique de MSX2 semble dire la même chose. Edité par aoineko Le 30/01/2011 à 09h13
On est toujours ignorant avant de savoir.
Tout est utilisable:
En 16 x 16 tu peux faire 64 sprites de 4 blocs de 8 octets: 64 x 4 x 8 x 8 = 16384 (h4000)
En 8 x8 tu peux faire 256 sprites d'un seul bloc de 8 octets: 256 x 8 x 8 = 16384 (h4000)
C'est vrai que c'est pas clair dans le bouquin, il doit vouloir dire qu'en 16 x 1 6 il saute les trois blocs suivant le premier, et le sprite suivant commence au bloc suivant les 4 premiers...
Attention d'ailleurs, il me semble qu'en 16 x 16 pour appeler les sprites 0,1,2,3,... il faut multiplier par 4 le N° du sprite (0,4,8,12,...).
En 16 x 16 tu peux faire 64 sprites de 4 blocs de 8 octets: 64 x 4 x 8 x 8 = 16384 (h4000)
En 8 x8 tu peux faire 256 sprites d'un seul bloc de 8 octets: 256 x 8 x 8 = 16384 (h4000)
C'est vrai que c'est pas clair dans le bouquin, il doit vouloir dire qu'en 16 x 1 6 il saute les trois blocs suivant le premier, et le sprite suivant commence au bloc suivant les 4 premiers...
Attention d'ailleurs, il me semble qu'en 16 x 16 pour appeler les sprites 0,1,2,3,... il faut multiplier par 4 le N° du sprite (0,4,8,12,...).
Le MSXien le plus à l'ouest ... ou presque
MSXosaure :
Attention d'ailleurs, il me semble qu'en 16 x 16 pour appeler les sprites 0,1,2,3,... il faut multiplier par 4 le N° du sprite (0,4,8,12,...).
C'est exact ... Et pour être plus précis, n'importe lequel des 4 numéros indexant les 4 blocs de 8x8 constituants le sprite de 16x16 peut être utilisé. Donc, pour utiliser le premier sprite 16x16 en TGS, on peut utiliser l'index 0,1,2 ou 3.
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)
MSXosaure :
Mais alors comment la palette est-elle sauvegardée quand on enregistre un fichier si elle n'est pas dans la VRAM
Et TPL ça correspond à quoi dans la VRAM alors?
Et TPL ça correspond à quoi dans la VRAM alors?
Autant pour moi, il y a bien une recopie des valeurs de la palette en VRAM
Mais par contre, je pense qu'elle n'est gérée qu'en BASIC, parce que je n'ai pas trouvé de registres du VDP qui déterminent son adresse en VRAM. Et d'ailleurs, ce ne sont pas les valeurs en VRAM qui déterminent une palette, mais bien les valeurs envoyées via le port 2 du VDP sur les registres de palette spécifiques.
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 :
Autant pour moi, il y a bien une recopie des valeurs de la palette en VRAM
Mais par contre, je pense qu'elle n'est gérée qu'en BASIC, parce que je n'ai pas trouvé de registres du VDP qui déterminent son adresse en VRAM. Et d'ailleurs, ce ne sont pas les valeurs en VRAM qui déterminent une palette, mais bien les valeurs envoyées via le port 2 du VDP sur les registres de palette spécifiques.
MSXosaure :
Mais alors comment la palette est-elle sauvegardée quand on enregistre un fichier si elle n'est pas dans la VRAM
Et TPL ça correspond à quoi dans la VRAM alors?
Et TPL ça correspond à quoi dans la VRAM alors?
Autant pour moi, il y a bien une recopie des valeurs de la palette en VRAM
Mais par contre, je pense qu'elle n'est gérée qu'en BASIC, parce que je n'ai pas trouvé de registres du VDP qui déterminent son adresse en VRAM. Et d'ailleurs, ce ne sont pas les valeurs en VRAM qui déterminent une palette, mais bien les valeurs envoyées via le port 2 du VDP sur les registres de palette spécifiques.
De rien Metalion, chacun sa spécialité
Ce post est une vraie mine pour les développeurs, on en apprend chaque jour un peu plus!
Le MSXien le plus à l'ouest ... ou presque
aoineko
Membre non connecté
Conseiller Municipal
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) ?
Organisation de ma VRAM :
J'ai beau envoyer 8 octets (forme du sprite) à la position [0,248], puis 4 octets (attribut du sprite) à la position [0,247], puis 8 octets (couleurs) à la position [0,245], le contenu de la VRAM aux adresses des zones TCS, TAS et TGS ne correspond pas aux données envoyées. Pourtant, les adresses de ces zones ont l'air bonne à en croire les registres du VDP.
Une idée ? Edité par aoineko Le 30/01/2011 à 23h34
Organisation de ma VRAM :
Zone | Adr | Ligne |
TNP1 (table des noms) | 0000h | 0 |
33 lignes de travail | D400h | 212 |
TCS(table des couleurs sprite) | F500h | 245 |
TAS(table des attributs sprite) | F700h | 247 |
TGS(table des formes de sprite) | F800h | 248 |
TNP2 (table des noms) | 10000h | 256 |
44 lignes de travail | 1D400h | 468 |
J'ai beau envoyer 8 octets (forme du sprite) à la position [0,248], puis 4 octets (attribut du sprite) à la position [0,247], puis 8 octets (couleurs) à la position [0,245], le contenu de la VRAM aux adresses des zones TCS, TAS et TGS ne correspond pas aux données envoyées. Pourtant, les adresses de ces zones ont l'air bonne à en croire les registres du VDP.
Une idée ? Edité par aoineko Le 30/01/2011 à 23h34
On est toujours ignorant avant de savoir.
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)
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie