La Place des Développeurs Projet Ambidex
aoineko
Membre non connecté
Conseiller Municipal
Bon, j'avance enfin un peu.
J'ai retrouvé le doc (en espagnol) ou est expliqué la création d'une ROM à partir d'un code en C (faudrait que je la traduise sur le forum à l'occaz) ; du coup j'ai enfin compris le format d'entête des cartouches et comment mon code se retrouvé dans la 2e page.
Et en rélisant la doc du V9938, j'ai aussi enfin compris mon problème dans mon accès direct à la VRAM en écriture en mode 8.
En fait, la valeur des 17 bits de l'adresse VRAM est coupé en 3 parties : les 3 bits (16-14) envoyé dans le Registre#14 puis 8 bits (7-0) et bits restants (8-13) sur le port 1 du VDP.
Du coup, j'ai plus de problème décalage entre mon allumage de pixel via commande VDP et par écriture en VRAM. Pour les curieux, voici le pseudo code ASM que j'utilise (certainement optimisable).
Prochaine était, copie d'un block mémoire de ma cartouche vers la VRAM... Si quelqu'un peut m'aiguiller, ça serait cool.
J'ai retrouvé le doc (en espagnol) ou est expliqué la création d'une ROM à partir d'un code en C (faudrait que je la traduise sur le forum à l'occaz) ; du coup j'ai enfin compris le format d'entête des cartouches et comment mon code se retrouvé dans la 2e page.
Et en rélisant la doc du V9938, j'ai aussi enfin compris mon problème dans mon accès direct à la VRAM en écriture en mode 8.
En fait, la valeur des 17 bits de l'adresse VRAM est coupé en 3 parties : les 3 bits (16-14) envoyé dans le Registre#14 puis 8 bits (7-0) et bits restants (8-13) sur le port 1 du VDP.
Du coup, j'ai plus de problème décalage entre mon allumage de pixel via commande VDP et par écriture en VRAM. Pour les curieux, voici le pseudo code ASM que j'utilise (certainement optimisable).
Code ASM :
;// Écriture directe en VRAM en mode 8 lda,5(ix) ;// Bits haut de mon adresse en VRAM and#0xC0 ;// Ne garder que les bits 15-14 rra rra rra rra rra rra ;// Décalage des 2 bits les plus haut vers les plus bas ;// Ici, on peux mettre le 3e bit (0x04) a 1 pour atteindre la VRAM au delà de 0xFFFF di out(VDP_ADDR),a ;// Envoi des donné vers le port 1 du VDP; VDP_ADDR = #0x99 lda,VDP_REG(14) ;// Sélection du registre 14; VDP_REG(x) = #0x80 + x out(VDP_ADDR),a lda,4(ix) ;// On envoi les bits 7-0 de l'adresse VRAM out(VDP_ADDR),a lda,5(ix) ;// Bits haut de mon adresse en VRAM (ne garder que les bits 13-8) and#0x3F ;// Mettre à 0 les 2 dernier bits or#0x40 ;// Demander l'accès en écritude out(VDP_ADDR),a lda,6(ix) ;// Ma couleur (8 bits) out(VDP_DATA),a ei
Prochaine était, copie d'un block mémoire de ma cartouche vers la VRAM... Si quelqu'un peut m'aiguiller, ça serait cool.
On est toujours ignorant avant de savoir.
aoineko
Membre non connecté
Conseiller Municipal
RibbSayan :
Avec le bios, tu peux utiliser cette commande :
Le but est d'éviter d'accéder au Bios pour un maximum de performance. Il me semble qu'il a une commande VDP pour copier de la RAM vers la VRAM mais je vois pas comment faire autrement que ligne par ligne. Y a t'il un moyen de copier un block (hauteur/largeur) vers la VRAM ?
On est toujours ignorant avant de savoir.
Metalion :
C'est l'intruction HMMC du VDP.
Tout est expliqué en page 152 de "Pratique du MSX2", format PDF.
Tout est expliqué en page 152 de "Pratique du MSX2", format PDF.
granced :
Je pense que tu parles de la commande HMMC (High speed Move to Memory from Computer).
Vois Pratique du MSX2 en page 151.
Vois Pratique du MSX2 en page 151.
Je crois qu'on est synchro !
MSX un jour, MSX toujours !
aoineko
Membre non connecté
Conseiller Municipal
Merci ! Je zieute ça à midi. Par contre, je donnerai cher pour avoir une version numérique de la doc du V9938. C'est une mine d'information, mais la version PDF scanné est vraiment pas pratique pour chercher une info.
On est toujours ignorant avant de savoir.
aoineko :
Merci ! Je zieute ça à midi. Par contre, je donnerai cher pour avoir une version numérique de la doc du V9938. C'est une mine d'information, mais la version PDF scanné est vraiment pas pratique pour chercher une info.
Ce n'est pas nécessaire : tout est clairement expliqué dans "Pratique du MSX2".
Il faut prendre la peine de le lire, de digérer l'info, puis ensuite de poser éventuellement les questions qui s'imposent.
aoineko :
Pour les curieux, voici le pseudo code ASM que j'utilise (certainement optimisable).
Au lieu d'utiliser 6 fois l'opcode RRA, tu peux plutôt utiliser 2 fois l'opcode RLC A (gain : 8 T-states).
Et tu peux anticiper ton EI d'une opération (le mettre entre le LD et le OUT), car le temps de basculement physique d'autorisation des interruptions permet en fait l'éxécution d'une opération supplémentaire. Cela permet de ne pas bloquer le VDP trop longtemps (ou tout autre interruption d'ailleurs).
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)
aoineko
Membre non connecté
Conseiller Municipal
Metalion :
Ce n'est pas nécessaire : tout est clairement expliqué dans "Pratique du MSX2".
Il faut prendre la peine de le lire, de digérer l'info, puis ensuite de poser éventuellement les questions qui s'imposent.
Il faut prendre la peine de le lire, de digérer l'info, puis ensuite de poser éventuellement les questions qui s'imposent.
Je l'ai lu, mais c'est très difficile de tout absorber au début.
(En fait, on comprend mieux quand on a un cas concret à réaliser).
Metalion :
Au lieu d'utiliser 6 fois l'opcode RRA, tu peux plutôt utiliser 2 fois l'opcode RLC A (gain : 8 T-states).
J'étais pas sur que le RLC transfert bien le dernier bit vers le premier (y a tellement d'instruction de shift différent dans le Z80 ).
Metalion :
Et tu peux anticiper ton EI d'une opération (le mettre entre le LD et le OUT), car le temps de basculement physique d'autorisation des interruptions permet en fait l'éxécution d'une opération supplémentaire. Cela permet de ne pas bloquer le VDP trop longtemps (ou tout autre interruption d'ailleurs).
Oui, on me l'avait déjà dit... toi surement d'ailleurs.
Juste pour être sur d'avoir bien compris le principe du HMMC ; Si on veut copier 256 pixels (16*16), on doit passer le premier pixel dans la commande VDP puis faire une boucle "copie + attendre" pour les 255 pixels suivants. Est-ce bien ça ?
On est toujours ignorant avant de savoir.
aoineko :
J'étais pas sur que le RLC transfert bien le dernier bit vers le premier (y a tellement d'instruction de shift différent dans le Z80 )
Ta bible (à connaître par coeur) : http://www.zilog.com/docs/z80/um0080.pdf
aoineko :
Juste pour être sur d'avoir bien compris le principe du HMMC ; Si on veut copier 256 pixels (16*16), on doit passer le premier pixel dans la commande VDP puis faire une boucle "copie + attendre" pour les 255 pixels suivants. Est-ce bien ça ?
Oui. Tu initialises les registres, tu charges la première valeur et puis tu boucles.
Comme indiqué dans le livre :
1 - charger les registres
2 - mettre à 11110000B ($F0) le registre 46.
3 - envoyer l'octet suivant à mettre en VRAM dans le registre 45 (le premier octet a été traité à l'étape 1) par un OUT du Z80.
4 - lire le registre d'état 2 (status).
5 - lire le registre d'état du bit CE, si celui-ci est à 0, alors l'instruction est terminée, sinon on passe à l'étape 6.
6 - tester l'état du bit TR, si celui-ci se trouve à 0, alors le processeur vidéo n'est pas prêt à recevoir l'octet suivant, recommencer en 4. Si par contre, ce bit est à 1, reprendre toute l'opération au niveau 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)
aoineko
Membre non connecté
Conseiller Municipal
Metalion :
Ta bible (à connaître par coeur) : http://www.zilog.com/docs/z80/um0080.pdf
Le lien ne marche pas, mais j'ai le Z80 Fimily CPU User Manual (300 pages). Mais bon, même avec un bon manuel, c'est vraiment pas facile au début. Surtout que dans mon cas, il faut que je désapprenne tout ce que je fait au quotidien sur des plateformes modernes. Mais bon, je désespère pas, ça commence à rentrer tout doucement.
On est toujours ignorant avant de savoir.
Walter
Membre non connecté
Conseiller Municipal
aoineko :
Le lien ne marche pas, mais j'ai le Z80 Fimily CPU User Manual (300 pages). Mais bon, même avec un bon manuel, c'est vraiment pas facile au début. Surtout que dans mon cas, il faut que je désapprenne tout ce que je fait au quotidien sur des plateformes modernes. Mais bon, je désespère pas, ça commence à rentrer tout doucement.
Le lien de Metalion fonctionne très bien.
Tu dis faire "au quotidien sur des plateformes modernes". Quel intérêt peux-tu avoir, de programmer sur MSX aujourd'hui ?
C'est sûrement moins intéressant, que sur XBox '360 (par exemple) ?
aoineko
Membre non connecté
Conseiller Municipal
Walter :
Tu dis faire "au quotidien sur des plateformes modernes". Quel intérêt peux-tu avoir, de programmer sur MSX aujourd'hui ?
C'est sûrement moins intéressant, que sur XBox '360 (par exemple) ?
C'est sûrement moins intéressant, que sur XBox '360 (par exemple) ?
C'est pas plus ou moins intéressant, c'est simplement différent. Le problème avec la 360, c'est qu'on touche plus trop à la machine (l'API est très puissante et cache une grosse partie du système). Sur PS3, avec son architecture assez particulière, c'est déjà plus le cas.
Pour ce qui est de l'intérêt de dev sur MSX, c'est pour enrichir mes connaissances sur le hardware en général, et surtout pour voir ce que j'aurai pu faire à l'époque. Durant ma période MSX (85-90), j'avais 10-15 et pour moi c'était avant tout une console de jeu. Et puis, j'aime bien les challenges. Edité par aoineko Le 18/01/2011 à 22h51
On est toujours ignorant avant de savoir.
aoineko
Membre non connecté
Conseiller Municipal
Argh, j'ai perdu pas mal de temps à chercher pourquoi le tableau que je construisais ne voulais pas s'initialiser... hum... il était en ROM, donc pas éditable.
Bon, une fois trouvé, j'ai commencé à coder la copie RAM -> VRAM (le HMMC) mais je tombe sur os.
L'initialisation des registres 36 à 46 se fait correctement si j'en crois le débogueur de BlueMSX, mais c'est surement dans la boucle de copie qu'il y a un problème (le MSX semble crasher).
Je mets ici le code de la boucle au cas ou quelqu'un comprennes mon erreur ou me donne une piste pour savoir vers ou chercher.
Des idées, conseils ? Edité par aoineko Le 21/01/2011 à 00h16
Bon, une fois trouvé, j'ai commencé à coder la copie RAM -> VRAM (le HMMC) mais je tombe sur os.
L'initialisation des registres 36 à 46 se fait correctement si j'en crois le débogueur de BlueMSX, mais c'est surement dans la boucle de copie qu'il y a un problème (le MSX semble crasher).
Je mets ici le code de la boucle au cas ou quelqu'un comprennes mon erreur ou me donne une piste pour savoir vers ou chercher.
Code ASM :
;// Copie des 63 couleurs restants (sprites de 8x8) di ;// je le laisse la pour l'instant pour plus de clarté SEND_NEXT_COLOR: ;// 3 - envoyer l'octet suivant à mettre en VRAM dans le registre 45 (le premier octet a été traité à l'étape 1) par un OUT du Z80 ;// Send next color lda,#252 ;// couleur en dur pour mes tests out(VDP_ADDR),a ;// VDP_ADDR = 99h lda,VDP_REG(45) ;// VDP_REG(x) = 80h + x out(VDP_ADDR),a WAIT_REG2: ;// 4 - lire le registre d'état 2 (status) ;// Get status ragister #2 lda,#2 out(VDP_ADDR),a lda,VDP_REG(15) out(VDP_ADDR),a ;// 5 - lire le registre d'état du bit CE, si celui-ci est à 0, alors l'instruction est terminée, sinon on passe à l'étape 6 nop ina,(VDP_ADDR) ldb,a ;// backup reg#2 rra ;// send CE bit into Carry jrnc,COLOR_COPY_END ;// 6 - tester l'état du bit TR, si celui-ci se trouve à 0, alors le processeur vidéo n'est pas ;// prêt à recevoir l'octet suivant, recommencer en 4. Si par contre, ce bit est à 1, reprendre toute l'opération au niveau 3 lda,b ;// restore reg#2 rla ;// send TR bit in the Carry jrnc,WAIT_REG2 jpSEND_NEXT_COLOR COLOR_COPY_END: ei
Des idées, conseils ? Edité par aoineko Le 21/01/2011 à 00h16
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie