La Place des Développeurs [ MSX2 ] SCREEN 8 256 x 212 en 256 couleurs ?
Reprise du message précédent
Oui il semble que le VDP écrive ces données en swappant dans les 2 parties de la VRAM pour le MODE SCREEN8.Donc ce n'est pas un problème mais un comportement normal.
Le vrai problème c'est que la DOC indique une info qui ne correspond pas à ce qui ce passe réellement (utilisation de la VRAM Haute et basse)
Voici la nouvelle version du code de test SCREEN8 et l'on peut voir que la aussi les données occupent les 2 parties de la VRAM :
la ROM à tester : 256.zip pas tester sur une machine réelle mais sur emu.
;***************************************
;
; MSX2 test 256x212 256colors
;
; (c) 2018 6502MAN
;
;***************************************
; VDP Ports MSX2
VDPCTRL .EQU $99 ; PORT #1
VDPDATA .EQU $98 ; PORT #0
; ecrire registres : DATA port #1 ensuite Reg +80h port #1
.org $4000
.DB "AB" ; HEADER CARTDRIGE = AB + $LLMM
.DW Main ; EXEC ADRESS LSB
Main
DI
CALL ModeGfx
CALL ClearVRAM
CALL WaitIntVDP
Bmp2VRAM
CALL SetVDPAddress ; Adress VRAM = $00000
LD BC,$3FFF
ld DE,SCREEN
Bitmap2VRAMloop
LD A,(DE)
out (VDPDATA),a
inc DE
dec c
jr nz,Bitmap2VRAMloop
dec b
jr nz,Bitmap2VRAMloop
FIN
EI
JP FIN
;------------------------------------------------------------------
;-------------------------------------------
; Fixe le mode du VDP en mode SCREEN8
; bitmap 256x212 en 256 couleurs
;-------------------------------------------
ModeGfx
ld hl,DataGfx
ld b,20
ld c,VDPCTRL
otir
RET
; R0 R1 R2 R3 R4 R5 R6 R7 R8 R9
DataGfx .db $0E,$80,$60,$81,$1f,$82,$80,$83,$00,$84,$f7,$85,$1E,$86,$07,$87,$08,$88,$80,$89
;-------------------------------------------
; Efface la VRAM du VDP
;-------------------------------------------
ClearVRAM
call @SetVDPAddress
ld bc,$Ffff
ld a,$00
ClearVRAMLoop
out (VDPDATA),a
dec c
jr nz,ClearVRAMLoop
dec b
jr nz,ClearVRAMLoop
RET
;-------------------------------------------
; Fixe l'adresse d'ecriture du VDP MSX2
; VRAM 00000h-1FFFFh
; { Reg #45 = 0 MSX MXD MXS DIY DIX EQ MAJ } not necessary
; Reg #14 = 0 0 0 0 0 A16 A15 A14
; PORT #1 = A7 A6 A5 A4 A3 A2 A1 A0
; PORT #1 = 0 R/W A13 A12 A11 A10 A9 A8
; after read or write by PORT #0
;-------------------------------------------
SetVDPAddress
LD A,$00
OUT (VDPCTRL),a ; data==>R14
LD A,14+$80
OUT (VDPCTRL),a ; R14
LD A,$00
OUT (VDPCTRL),a ; P1
LD A,$40
OUT (VDPCTRL),a ; P1
RET
;-------------------------------------------
; Attend la fin de balayage du VDP
;
;-------------------------------------------
WaitIntVDP
LD A,$00 ; => status 00
OUT (VDPCTRL),a ; data==>R15
LD A,15+$80
OUT (VDPCTRL),a ; R15
IN A,(VDPCTRL)
RL A
JR NC,WaitIntVDP
RET
SCREEN
;************** IMAGE ******************
#include "VisNoDit.ASM"
.ORG $BFFE
.db $ff
.END
6502man :
Oui il semble que le VDP écrive ces données en swappant dans les 2 parties de la VRAM pour le MODE SCREEN8.
Donc ce n'est pas un problème mais un comportement normal.
Le vrai problème c'est que la DOC indique une info qui ne correspond pas à ce qui ce passe réellement (utilisation de la VRAM Haute et basse)
Donc ce n'est pas un problème mais un comportement normal.
Le vrai problème c'est que la DOC indique une info qui ne correspond pas à ce qui ce passe réellement (utilisation de la VRAM Haute et basse)
En fait non. Après longue discussion sur le sujet sur msx.org, il s'avère que ce comportement est uniquement lié au hardware (RAM et bande passante), mais est transparent pour l'utilisateur. On s'en aperçoit parce qu'on a la possibilité de pauser l'émulateur et de visualiser la VRAM, mais il faut bien se rendre compte que cela n'est pas faisable pour un utilisateur normal de la machine d'origine. Et pour lui, l'utilisation de la VRAM est linéaire : si on allume un pixel à l'écran, sa valeur sera bien stockée au bon endroit, car lorsqu'il interrogera la VRAM à l'adresse concernée, le VDP lui donnera bien la bonne valeur.
Ce que tu as mis en évidence ici est un phénomène qui se passe "en coulisse" du VDP et de la VRAM, mais qui, en fait, est bien transparent pour l'utilisateur.
Et par conséquent, la documentation est correcte. Edité par Metalion Le 01/07/2018 à 09h22
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)
Très intéressant les phénomènes inattendu+s 
Je suppose que le phénomène se produit aussi de la même facon lorsqu'on utilise la commande {Copy Screen 0] ou encore [Copy Screen 1].
Pour rappel, lorsqu'on utilise la commande [Copy Screen], le Msx remplace la couleur [Noir] par la couleur [Transparent] sans que l'utilisateur se rende compte du phénomène puisqu'en théorie, l'utilisateur ne visualise la [Numérisation] qu'après "relecture" de l'image stockée en VRAM qui au passage interprète le "Transparent" comme étant du "Noir" alors qu'il s'agissait bien de transparent interprété/analysé par le Color Bus et visualisé en temps réel par le VDP
Edité par
igal
Le 04/07/2018 à 07h18
Je suppose que le phénomène se produit aussi de la même facon lorsqu'on utilise la commande {Copy Screen 0] ou encore [Copy Screen 1].
Pour rappel, lorsqu'on utilise la commande [Copy Screen], le Msx remplace la couleur [Noir] par la couleur [Transparent] sans que l'utilisateur se rende compte du phénomène puisqu'en théorie, l'utilisateur ne visualise la [Numérisation] qu'après "relecture" de l'image stockée en VRAM qui au passage interprète le "Transparent" comme étant du "Noir" alors qu'il s'agissait bien de transparent interprété/analysé par le Color Bus et visualisé en temps réel par le VDP
Edité par
igal
Le 04/07/2018 à 07h18
GreenBeret :
Est-ce que ce phénomène ne serait pas un moyen du standard de nettoyer les données en page 1 qui sont rémanente par rapport a la page 0 volatile?
Non, d'après ce que j'ai compris, c'est lié à l'accès à la VRAM par VDP.
Etant donné que le volume de données est plus important à traiter, les temps d'accès aux puces RAM deviennent un goulot.
Et pour contourner ce problème, les concepteurs ont réparti la tâche entre les 2 pages de 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)
Donc on pourrait théoriquement bénéficier de plus de VRAM sans ralentir le système 
Les VDP 38 et 58 peuvent gérer jusqu'à 192ko de VRAM, soit 3 pages en screen8, sauf que cette 3eme page n'est accessible que en assembleur et non par le Basic
A quand une routine qui le permettrait en rajoutant une fonction au basic.
. Ca a peut déjà ete fait!?
Edité par
GreenBeret
Le 05/07/2018 à 21h36
Les VDP 38 et 58 peuvent gérer jusqu'à 192ko de VRAM, soit 3 pages en screen8, sauf que cette 3eme page n'est accessible que en assembleur et non par le Basic
A quand une routine qui le permettrait en rajoutant une fonction au basic.
. Ca a peut déjà ete fait!?
Edité par
GreenBeret
Le 05/07/2018 à 21h36
GreenBeret est un beau jeu , si si
@GreenBeret: à priori, il la somme de Vram adressé reste la même.
Le "petit plus" est que plutôt que d'écrire sur la "VRAM 1", le VDP écrit sur la VRAM 1 et 2 de façon complètement transparente pour l'utilisateur
Au final, ça ne change en rien la quantité de VRAM mais juste l'emplacement physique (hardware réel) des données stockées en VRAM du moins loesqu'il s'agit des SCREEN 7 et 8.
Le "petit plus" est que plutôt que d'écrire sur la "VRAM 1", le VDP écrit sur la VRAM 1 et 2 de façon complètement transparente pour l'utilisateur
Au final, ça ne change en rien la quantité de VRAM mais juste l'emplacement physique (hardware réel) des données stockées en VRAM du moins loesqu'il s'agit des SCREEN 7 et 8.
Citation :
Ce que tu as mis en évidence ici est un phénomène qui se passe "en coulisse" du VDP et de la VRAM, mais qui, en fait, est bien transparent pour l'utilisateur.
Et par conséquent, la documentation est correcte.
Et par conséquent, la documentation est correcte.
La doc n'est pas fausse mais ce qui trompe c'est que l'émulateur permet de visionner ce phénomène, alors que c'est transparent pour l'utilisateur
Avec ce VDP on peut utiliser des commandes internes au VDP qui on l'air puissante, je vais essayer de faire quelques tests si j'ai un peu de temps, mais pas facile en ce moment car c'est boulot boulot ....
6502man :
Avec ce VDP on peut utiliser des commandes internes au VDP qui on l'air puissante
Oui, et on a tendance à l'oublier un peu d'ailleurs, mais le VDP du MSX2 était une des toutes premières puces graphiques avec accélération matérielle. C'est un co-processeur graphique, dans la même lignée de ce qui est apparu ensuite, sur l'Amiga par exemple.
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 viens de faire quelques tests avec les commandes internes du VDP.
Donc pour tester la rapidité j'ai repris a partir du précédent code l'affichage d'une portion de visage qui scroll vers le bas de l'écran, la partie à copier est quand même assez grande donc c'est pas hyper rapide, mais c'est pas mal, mais surtout l’intérêt de ces commandes c'est que lorsque le VDP exécute ca commande le Z80 peut faire autre chose en attendant que le VDP est fini d’exécuter la commande
Une petite ROM de test pour vous faire une idée:
Test_Screen8_CMDa.ROM
J'ai aussi utiliser les commandes avec opérations logiques IMP,AND,OR,XOR,NOT sur une petite portion de l'image (l'oeil) et ca donne ce ceci :
Test_Screen8_CMD2.ROM
Il y a plein d'autres possibilités ....
Si ca intéresse quelqu'un je peux poster le code assembleur ???
Donc pour tester la rapidité j'ai repris a partir du précédent code l'affichage d'une portion de visage qui scroll vers le bas de l'écran, la partie à copier est quand même assez grande donc c'est pas hyper rapide, mais c'est pas mal, mais surtout l’intérêt de ces commandes c'est que lorsque le VDP exécute ca commande le Z80 peut faire autre chose en attendant que le VDP est fini d’exécuter la commande
Une petite ROM de test pour vous faire une idée:
Test_Screen8_CMDa.ROM
J'ai aussi utiliser les commandes avec opérations logiques IMP,AND,OR,XOR,NOT sur une petite portion de l'image (l'oeil) et ca donne ce ceci :
Test_Screen8_CMD2.ROM
Il y a plein d'autres possibilités ....
Si ca intéresse quelqu'un je peux poster le code assembleur ???
Salut Igal
Si on n'attend pas que le VDP soit disponible cela donne des graphismes corrompues, dont le résultat est totalement incertain !!!
Si tu ne fait qu'afficher une image le résultat seras identique, par contre si tu doit afficher plusieurs "portions" d"images avec les Commandes internes au VDP tu auras un résultat totalement aléatoire.
Pour tester il te suffit sur la rom "Test_Screen8_CMD2.ROM" que j'ai donné précédemment de changer l'octet à la position 01A5h qui est 38h en 30h et tu verras que cela n'est pas du tout utilisable
Après il faudrait tester sur une vraie machine pour voir le comportement avec un VDP physique ...
Si on n'attend pas que le VDP soit disponible cela donne des graphismes corrompues, dont le résultat est totalement incertain !!!
Si tu ne fait qu'afficher une image le résultat seras identique, par contre si tu doit afficher plusieurs "portions" d"images avec les Commandes internes au VDP tu auras un résultat totalement aléatoire.
Pour tester il te suffit sur la rom "Test_Screen8_CMD2.ROM" que j'ai donné précédemment de changer l'octet à la position 01A5h qui est 38h en 30h et tu verras que cela n'est pas du tout utilisable
Après il faudrait tester sur une vraie machine pour voir le comportement avec un VDP physique ...
Il y a quelques années, j'utilisais Hexedit.
Vais voir si je peux remettre la main dessus
Edit: J'ai modifié avec mon logiciel de gravure d'Eeprom.
J'ai bien trouvé la valeur [38] en [cinquième position] de la ligne 001A que j'ai remplacé par la valeur [30].
Effectivement, il reste plus grand chose du scroll si ce n'est qu'une petite colonne marron sur la gauche.
Edité par igal Le 08/07/2018 à 17h57
Vais voir si je peux remettre la main dessus
Edit: J'ai modifié avec mon logiciel de gravure d'Eeprom.
J'ai bien trouvé la valeur [38] en [cinquième position] de la ligne 001A que j'ai remplacé par la valeur [30].
Effectivement, il reste plus grand chose du scroll si ce n'est qu'une petite colonne marron sur la gauche.
Edité par igal Le 08/07/2018 à 17h57
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie