La Place des Développeurs [EN COURS] un seul chargement et deux destinations. Comment charger une fois pour deux emplacements.
Reprise du message précédent
GDX :
On peut accélérer, la méthode des VDP en testant le bit 0 du registre de statut 2 juste avant de changer la valeur du registre 46.
Attendre la VBL ne fait que ralentir.
z80 :
Attendre la VBL
Attendre la VBL ne fait que ralentir.
Faux, généralement on attend la VBL et on fait tout ce que qu'on a a faire avec le VDP. En suite on fait de la musique, on gère le héros les ennemis etc...
Faut, juste pas attendre la VBL pour chacun de COPY... Tu attends la VBL puis tu balances tes COPY.
GDX :
Tu es sûr pour l'accès à la VRAM ?
z80 :
Couper l'écran et les sprites accélère les COPY et l'accès à la VRAM
Tu es sûr pour l'accès à la VRAM ?
Certain, expérimenté dans des démos principalement, mais aussi quand tu as besoin d'accès rapide à la VRAM ou que les commandes du VDP s'exécutent à la vitesse la plus rapide possible. Edité par z80 Le 28/03/2015 à 20h02
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
La VSYNC sert à synchroniser pas à accélérer. C'est pour ça que l'on utilise pour de la musique, le déplacement des ennemis, etc...
D'ailleurs sur MSX, les interruptions ne sont pas tellement utilisées pour les accès au VDP car le système n'est pas prévu pour. Toutes les routines du Bios pour le VDP coupent et activent les interruptions lors des accès. En général, on se sert de la VBL seulement pour activer ou désactiver des flags afin de synchroniser les routines VDP hors de l'interruption. On est obligé de faire des accès directs pour mettre des routines du VDP pendant une interruption.
Il faut aussi prendre en compte que le VDP du MSX2/2+ est assez lent. On ne peut faire que quelques petits COPY entre 2 interruptions. Edité par GDX Le 29/03/2015 à 08h54
D'ailleurs sur MSX, les interruptions ne sont pas tellement utilisées pour les accès au VDP car le système n'est pas prévu pour. Toutes les routines du Bios pour le VDP coupent et activent les interruptions lors des accès. En général, on se sert de la VBL seulement pour activer ou désactiver des flags afin de synchroniser les routines VDP hors de l'interruption. On est obligé de faire des accès directs pour mettre des routines du VDP pendant une interruption.
Il faut aussi prendre en compte que le VDP du MSX2/2+ est assez lent. On ne peut faire que quelques petits COPY entre 2 interruptions. Edité par GDX Le 29/03/2015 à 08h54
C'est tellement pas utiliser que tout le monde utilise VSYNC.... Et les scrolling en mode COPY se font très bien, je l'ai déjà fait. OK on utilise les Setpage pour switcher page 0 et 1.
Et vu les petits COPY que veux faire Igal ça doit le faire.
Si tu coupes l'affichage et les spirites à la ligne 212 et que tu allumes le tout en début de période d'affichage, tu peux faire des accès rapide à la VRAM.
Après tu me crois ou tu me crois pas.
Et vu les petits COPY que veux faire Igal ça doit le faire.
Si tu coupes l'affichage et les spirites à la ligne 212 et que tu allumes le tout en début de période d'affichage, tu peux faire des accès rapide à la VRAM.
Après tu me crois ou tu me crois pas.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Je n'ai pas dit que la VSYNC n'est pas utilisée. J'ai dit que la VSYNC sert à synchroniser pas à accélérer et que les routines du système n'étaient pas appropriées pour être insérées dans la routine d'interruption.
Si on fait des accès directs en machine, c'est possible sauf peut-être pour Igal qui ne travaille pas en assembleur
Si on fait des accès directs en machine, c'est possible sauf peut-être pour Igal qui ne travaille pas en assembleur
En BASIC, oublie ! En turbo BASIC ça peux se tenter. En fait on attends plutôt la ligne 212 comme ça tu as plus de temps.... La VBL ne dure que 6 lignes de mémoire. Alors si tu coupes tout à la ligne 212, tu gagne pas mal de temps.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
z80 :
GDX :
Certain, expérimenté dans des démos principalement, mais aussi quand tu as besoin d'accès rapide à la VRAM ou que les commandes du VDP s'exécutent à la vitesse la plus rapide possible.z80 :
Tu es sûr pour l'accès à la VRAM ?Couper l'écran et les sprites accélère les COPY et l'accès à la VRAM
Voir ici : http://map.grauw.nl/articles/vdp_commands_speed.php
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)
les test de GRAUW avec les daigrame temporels sont pourtant clair et montre trous les accès à la VRAM avec sprite ON/OFF et DISPLAY ON/OFF.
Mes test perso étaient simple comme je les ai pas mal expliqués:
1 - attente ligne 212.
2 - coupure sprite et display.
3 - color 0 = 255,255,255 (blanc).
4 - tranfert RAM à VRAM de N kilo octet.
5 - color 0 = 0,0,0 (noir).
6 Sprite ON, Display ON.
7 - CALL au replayer music.
8 - Gestion Héro et ennemis.
Du coup dès que tu vois du blanc sur le haut de l'image, c'est que tu n'as pas eu le temps de faire le boulot dans le temps imparti.
Pour tester, tu modifie le point 2. Tu coupes ou pas les sprites et/ou l'affichage.
Tu peux remplacer en 4 le transfert RAM vers VRAM, par des fonction COPY de ton choix...
Mes test perso étaient simple comme je les ai pas mal expliqués:
1 - attente ligne 212.
2 - coupure sprite et display.
3 - color 0 = 255,255,255 (blanc).
4 - tranfert RAM à VRAM de N kilo octet.
5 - color 0 = 0,0,0 (noir).
6 Sprite ON, Display ON.
7 - CALL au replayer music.
8 - Gestion Héro et ennemis.
Du coup dès que tu vois du blanc sur le haut de l'image, c'est que tu n'as pas eu le temps de faire le boulot dans le temps imparti.
Pour tester, tu modifie le point 2. Tu coupes ou pas les sprites et/ou l'affichage.
Tu peux remplacer en 4 le transfert RAM vers VRAM, par des fonction COPY de ton choix...
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Ben il précise bien que les temps d'accès attribué au fonction du VDP (COPY, LINE, etc...) sont aussi les slot de temps attribués au accès directes du Z80 à la VRAM.
Les accès du Z80 à la VRAM est prioritaire à l'exécution des commandes du VDP.
Les accès du Z80 à la VRAM est prioritaire à l'exécution des commandes du VDP.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
J'espère ne pas être à coté du sujet d'autant que tu maîtrises largement les détails qui suivent!
La Vram n'est accessible qu'au travers du VDP!
Il n'y a pas de passerelle Z80 => VRAM ou encore RAM => VRAM.
Il s'agit de l'architecture même du VDP.
La seule alternative à ma conaissance est de passer par le Color Bus:
MEDIA => VDP COLOR BUS => VRAM
Une alternative qui n'attend qu'un média gérable par le RS232 de Eric
La Vram n'est accessible qu'au travers du VDP!
Il n'y a pas de passerelle Z80 => VRAM ou encore RAM => VRAM.
Il s'agit de l'architecture même du VDP.
La seule alternative à ma conaissance est de passer par le Color Bus:
MEDIA => VDP COLOR BUS => VRAM
Une alternative qui n'attend qu'un média gérable par le RS232 de Eric
Quand je dis "accès direct à la VRAM", je parle de la méthode suivante, celle qui n'utilise pas de commande du VDP (et qui fonctionne aussi sur MSX1).
On ne risquait pas de se comprendre donc.
Code TEXT :
ram2vram: ld a,0 di out (099h),a ld a,80h+14 out (099h),a ld a,01fh out (099h),a ld a,040h ei out (099h),a ex (sp),hl; Wait for ex (sp),hl; MSX1 VDP ld hl,data ld bc,0698h otir ret DATA: DB "Hello!"
On ne risquait pas de se comprendre donc.
igal :
J'espère ne pas être à coté du sujet d'autant que tu maîtrises largement les détails qui suivent!
La Vram n'est accessible qu'au travers du VDP!
Il n'y a pas de passerelle Z80 => VRAM ou encore RAM => VRAM.
Il s'agit de l'architecture même du VDP.
La seule alternative à ma conaissance est de passer par le Color Bus:
MEDIA => VDP COLOR BUS => VRAM
Une alternative qui n'attend qu'un média gérable par le RS232 de Eric
La Vram n'est accessible qu'au travers du VDP!
Il n'y a pas de passerelle Z80 => VRAM ou encore RAM => VRAM.
Il s'agit de l'architecture même du VDP.
La seule alternative à ma conaissance est de passer par le Color Bus:
MEDIA => VDP COLOR BUS => VRAM
Une alternative qui n'attend qu'un média gérable par le RS232 de Eric
Oui c'est via le VDP, il n'y a pas d'autre méthode sur MSX1, 2, 2+, TrbR
C'est comme l'explique le code assembleur de GDX.
Il faut comprendre directe au sens ou on ne passe pas par des commandes VDP (registre 46 ou 47, je ne sais plus).
Bref on écrit de la donnée brute sans traitement par le VDP.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)
Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...
Je déterre un peu puisque j'ai quelques heures libres pour faire ce que j'ai envie lol.
Alors voilà.
A défaut d'une méthode "clinique" pour faire un seul chargement et deux destinations...
Sachant qu'en affichant une IMAGE.SC5 dans un SCREEN7 duplique les données vidéo de l'image en lui donnant deux destinations. (il en est de même si on affiche une IMAGE.SC5 en SCREEN8, 10, 12.
Quelque soit l'explication, dans la pratique, on a un seul chargement et deux destinations
Avez vous une idee même "batarde" selon laquelle:
1) je créer une IMAGE.SCx sous SCREEN x
2) je charge l'IMAGE.SCx (une seule fois) sous SCREEN 5
3) les données chargées en phase (2) s'affichent sur 2 pages différentes
Les idées farfelues sont les bienvenues.
Nb: oui je sais que les images en screen5 sont constituées d'octets organisées différemment que dans les autres screens cités plus haut!
Justement, c'est peut être une possibilité de contourner le problème mais j'attends vos idées
Alors voilà.
A défaut d'une méthode "clinique" pour faire un seul chargement et deux destinations...
Sachant qu'en affichant une IMAGE.SC5 dans un SCREEN7 duplique les données vidéo de l'image en lui donnant deux destinations. (il en est de même si on affiche une IMAGE.SC5 en SCREEN8, 10, 12.
Quelque soit l'explication, dans la pratique, on a un seul chargement et deux destinations
Avez vous une idee même "batarde" selon laquelle:
1) je créer une IMAGE.SCx sous SCREEN x
2) je charge l'IMAGE.SCx (une seule fois) sous SCREEN 5
3) les données chargées en phase (2) s'affichent sur 2 pages différentes
Les idées farfelues sont les bienvenues.
Nb: oui je sais que les images en screen5 sont constituées d'octets organisées différemment que dans les autres screens cités plus haut!
Justement, c'est peut être une possibilité de contourner le problème mais j'attends vos idées
en fait la destination est identique puisque tu rempli la vram a chaque fois
c'est l'exploitation des données qui change suivant le mode d'écran
il n'y a pas duplication c'est juste le nombres d'octets pour un pixel qui change
en screen 5 un octet = 2 pixels (1111 2222) les 4 bits codent la couleur
en screen 6 un octet = 4 pixels (11 22 33 44) les 2 bits codent la couleur
en screen 7 un octet = 2 pixels (1111 2222) les 4 bits codent la couleur
en screen 7 un octet = 1 pixel (VVV RRR BB) la palette est de 256 couleurs (le bleu est codé sur 2 bits)
rajout:
tu peux faire des essais avec des VPOKE pour comprendre comment la VRAM se remplit
c'est l'exploitation des données qui change suivant le mode d'écran
il n'y a pas duplication c'est juste le nombres d'octets pour un pixel qui change
en screen 5 un octet = 2 pixels (1111 2222) les 4 bits codent la couleur
en screen 6 un octet = 4 pixels (11 22 33 44) les 2 bits codent la couleur
en screen 7 un octet = 2 pixels (1111 2222) les 4 bits codent la couleur
en screen 7 un octet = 1 pixel (VVV RRR BB) la palette est de 256 couleurs (le bleu est codé sur 2 bits)
rajout:
tu peux faire des essais avec des VPOKE pour comprendre comment la VRAM se remplit
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie