La Place des Développeurs [ MSX2 ] SCREEN 8 256 x 212 en 256 couleurs ?
Me voici de retour 
D'après les docs du VDP intégré dans les MSX2 le mode SCREEN 8 du Basic permet d'afficher une image en 256 X 212 en 256 couleurs.
Toujours d'après cette doc 1 octet code 1 point au format RRRGGGBB donc un écran occupe 256x212 octets soit 54272 octets.
l"emplacement doit être entre $0000-$D3FF !
Seulement lorsque sous BlueMsx je passe en SCREEN 8 il utilise 2 fois cette taille
De plus une option permet d'avoir un mode entrelacé 256 x 424 (si j'ai bien compris) et malgrès que cette option soit désactivé le VDP utilise 2 x 54272 octets pour construire l'image à l'écran
Est ce que j'ai rien compris au Basic MSX2 ou il y a une erreur dans les DOCs (impossible) ?
Pour faire le test j'ai configuré BM en MSX2 NMS-8250 et executé ce code BASIC :
Ensuite en ouvrant le debuggeur j'ai visualisé la VRAM et modifié les premiers octets de la VRAM ($00000) et la j'ai put observer que l'image ne modifié qu'un pixel sur 2 (pixels paires) et en allant modifier les octets à partir de ($10000) les (pixels impaires)
Mais qu'est ce que ce bazar
Donc j'aurais 2 questions à soumettre à votre sagacités :
1) Comment obtenir l'affichage 256X212 en 256 couleurs ?
2) Existe t'il un mode 512X... en 256 couleurs sur MSX2 (pas le 2+ ou turbo) ?
Merci d'avance pour votre aide
D'après les docs du VDP intégré dans les MSX2 le mode SCREEN 8 du Basic permet d'afficher une image en 256 X 212 en 256 couleurs.
Toujours d'après cette doc 1 octet code 1 point au format RRRGGGBB donc un écran occupe 256x212 octets soit 54272 octets.
l"emplacement doit être entre $0000-$D3FF !
Seulement lorsque sous BlueMsx je passe en SCREEN 8 il utilise 2 fois cette taille
De plus une option permet d'avoir un mode entrelacé 256 x 424 (si j'ai bien compris) et malgrès que cette option soit désactivé le VDP utilise 2 x 54272 octets pour construire l'image à l'écran
Est ce que j'ai rien compris au Basic MSX2 ou il y a une erreur dans les DOCs (impossible) ?
Pour faire le test j'ai configuré BM en MSX2 NMS-8250 et executé ce code BASIC :
Citation :
10 SCREEN 8
20 GOTO 20
10 SCREEN 8
20 GOTO 20
Ensuite en ouvrant le debuggeur j'ai visualisé la VRAM et modifié les premiers octets de la VRAM ($00000) et la j'ai put observer que l'image ne modifié qu'un pixel sur 2 (pixels paires) et en allant modifier les octets à partir de ($10000) les (pixels impaires)
Mais qu'est ce que ce bazar
Donc j'aurais 2 questions à soumettre à votre sagacités :
1) Comment obtenir l'affichage 256X212 en 256 couleurs ?
2) Existe t'il un mode 512X... en 256 couleurs sur MSX2 (pas le 2+ ou turbo) ?
Merci d'avance pour votre aide
si tu veux afficher les 256 sur une ligne
10 SCREEN8
20 FOR I=0 TO 255
30 VPOKE I,I
40 NEXT
100 GOTO 100
BlueMSX est peut-être en entrelacé par défaut dans ta config
le seul mode 512X est le SCREEN7 mais il n'y a que 16 couleurs
seul le GFX9000 propose des modes 512X en 256 couleurs
10 SCREEN8
20 FOR I=0 TO 255
30 VPOKE I,I
40 NEXT
100 GOTO 100
BlueMSX est peut-être en entrelacé par défaut dans ta config
le seul mode 512X est le SCREEN7 mais il n'y a que 16 couleurs
seul le GFX9000 propose des modes 512X en 256 couleurs
En screen8 on a 2 pages 54ko avec 128ko de Vram : la page 1 qui sert de page de stockage qui conserve les donnés et la page 0, la page de travail qui s'efface quand on quite le programme.
Le mode entrelacer permet d'alterner la meme image afin d'obtenir un format 256x424, mais ca syntille si le moniteur ne suit pas
Le mode entrelacer permet d'alterner la meme image afin d'obtenir un format 256x424, mais ca syntille si le moniteur ne suit pas
GreenBeret est un beau jeu , si si
Il doit y avoir une erreur dans ta config ou dans ton interprétation de la VRAM, car la documentation est correcte.
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 met pas en doute la documentation, mais plutôt ma compréhension du fonctionnement du SCREEN 8 en basic :'(
Car j'ai beau faire tous les tests dans tous les sens il y a toujours les 2 pages qui sont modifié
J'ai préparé une disquette pour faire les tests :Screen8.zip
1) executer le programme "256.bas"
2) lorsque l'image est entièrement chargée "pauser" bluemsx et aller dans le debbuggeur
3) selectionner la VRAM dans la fenetre memory
4) regarder à l'adresse 0000 puis à l'adresse 10000 (1 puis 4 zéro)
5) "continuer" l'execution de bluemsx pendant que les lignes du haut s'efface "pauser" et retourner dans le debbuggeur pour vérifier les adresses en VRAM 0000 et 10000 (faire défiler la fenetre vers le bas jusqu'a voir des 0 en rouges) et l'on peut voir que les deux zones sont mis à zéros
6) "continuer" et refaire "pause' et revérifier la VRAM ....
BlueMSX en mode MSX2 french .
Peut être faut il que je fasse un programme en assembleur pour que le comportement corresponde à la DOC ....
Edité par 6502man Le 27/06/2018 à 22h50
Car j'ai beau faire tous les tests dans tous les sens il y a toujours les 2 pages qui sont modifié
J'ai préparé une disquette pour faire les tests :Screen8.zip
1) executer le programme "256.bas"
2) lorsque l'image est entièrement chargée "pauser" bluemsx et aller dans le debbuggeur
3) selectionner la VRAM dans la fenetre memory
4) regarder à l'adresse 0000 puis à l'adresse 10000 (1 puis 4 zéro)
5) "continuer" l'execution de bluemsx pendant que les lignes du haut s'efface "pauser" et retourner dans le debbuggeur pour vérifier les adresses en VRAM 0000 et 10000 (faire défiler la fenetre vers le bas jusqu'a voir des 0 en rouges) et l'on peut voir que les deux zones sont mis à zéros
6) "continuer" et refaire "pause' et revérifier la VRAM ....
BlueMSX en mode MSX2 french .
Peut être faut il que je fasse un programme en assembleur pour que le comportement corresponde à la DOC ....
Edité par 6502man Le 27/06/2018 à 22h50
Effectivement, le comportement en VRAM est bien celui que tu décris.
Et qui plus est, c'est identique si on remplace VPOKE par PSET (j'ai essayé).
- soit c'est lié à l'utilisation du BASIC, mais je ne vois pas très bien pourquoi
- soit c'est un bug dans BlueMSX, mais ce serait étonnant
- soit il y a quelque chose qui nous échappe ...
Et qui plus est, c'est identique si on remplace VPOKE par PSET (j'ai essayé).
- soit c'est lié à l'utilisation du BASIC, mais je ne vois pas très bien pourquoi
- soit c'est un bug dans BlueMSX, mais ce serait étonnant
- soit il y a quelque chose qui nous échappe ...
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 il y a bien un truc avec le mode SCREEN8 en basic, j'ai joué à modifier un peut tous les registres du VDP mais toujours le même comportement 
Si demain j'ai le temps je prépare un petit programme assembleur pour vérifier si cela donne le même comportement ...
Si demain j'ai le temps je prépare un petit programme assembleur pour vérifier si cela donne le même comportement ...
Pour vérifier il suffit d'observer la VRAM lors de l'affichage du LOGO du BOOT MSX2 et la effectivement il n'utilise que la première partie de la VRAM comme énoncé dans les DOCs
Les registres ne sont pas définis de la même manière que le mode SCREEN8 du BASic ????
Je vais étudier de plus près ...
OUPS le logo est en mode SCREEN5 pas en mode SCREEN8
Edité par
6502man
Le 28/06/2018 à 22h30
Cette fois j'ai trouvé pourquoi ce comportement : le positionnement du bit 3 (VR) du registre 8 qui est positionné à 1 par le Basic !
Pour vérifier il suffit d'exécuter mon petit programme de test et de "pauser" blueMsx et de mettre à zéro le registre 8 du VDP et de reprendre l’exécution et la ca fonctionne en utilisant que la première partie de la VRAM .
Mais du coup la modification de ce bit du registre 8 sur une vraie machine risque de donner un comportement inattendu puisque d'après les docs voici à quoi sert ce bit :
Les MSX ont tous le même type de VRAM ?
Sinon ca voudrait dires que le BASIC est modifié selon les modèles
Pour vérifier il suffit d'exécuter mon petit programme de test et de "pauser" blueMsx et de mettre à zéro le registre 8 du VDP et de reprendre l’exécution et la ca fonctionne en utilisant que la première partie de la VRAM .
Mais du coup la modification de ce bit du registre 8 sur une vraie machine risque de donner un comportement inattendu puisque d'après les docs voici à quoi sert ce bit :
Selects the type and organization of VRAM. if set to 1 VRAM is 64Kx1bit or 64Kx4bits. if set 0 VRAM is 16kx1bit or 16Kx4bits
Les MSX ont tous le même type de VRAM ?
Sinon ca voudrait dires que le BASIC est modifié selon les modèles
Visiteur
Vagabond
Message : 0
Figure toi que j'avais soupçonné un truc pareil dans l'analyse hier, car cela ressemble furieusement à du "mirroring", qui se produirait peut-être avec une VRAM de 64K. J'avais vérifié la définition de la machine "MSX2 French", mais elle a bien 128K.
Bon par contre, je viens de vérifier avec une machine MSX2 générique, et le problème est le même ...
C'est à n'y rien comprendre. Mais c'est effectivement le BASIC qui est responsable.
Bon par contre, je viens de vérifier avec une machine MSX2 générique, et le problème est le même ...
C'est à n'y rien comprendre. Mais c'est effectivement le BASIC qui est responsable.
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 un programme ASM mais c'est très différent du VDP des MSX1 et je connaissais pas encore.
Mais d"après mes premiers test l’écriture ce fait bien conformément à la DOC c'est à dires sur la première partie de la VRAM !!!
Les donnèes en VRAM correspondent bien aux donnèes envoyées au VDP
Le code brut un peu vite fait mais dans le seul but de tester l’écriture en VRAM, il faut revoir la boucle d'envoie des données par rapport à la taille des données à envoyer
J'ai testé avec le Registre 8 à 0 ca donne le même résultat.
Par contre l'image affiché n'est pas conforme je doit vérifier le positionnement des registres ...
Demain si j'arrive à trouver une heure comme aujourd'hui ....
Oups j'ai glissé sur le code
Il y a avait une erreur concernant les registres du VDP !
Je vous post le nouveau code corrigé avec un .ROM pour test ...
Edité par 6502man Le 30/06/2018 à 12h21
Mais d"après mes premiers test l’écriture ce fait bien conformément à la DOC c'est à dires sur la première partie de la VRAM !!!
Les donnèes en VRAM correspondent bien aux donnèes envoyées au VDP
Le code brut un peu vite fait mais dans le seul but de tester l’écriture en VRAM, il faut revoir la boucle d'envoie des données par rapport à la taille des données à envoyer
J'ai testé avec le Registre 8 à 0 ca donne le même résultat.
Par contre l'image affiché n'est pas conforme je doit vérifier le positionnement des registres ...
Demain si j'arrive à trouver une heure comme aujourd'hui ....
Oups j'ai glissé sur le code
Il y a avait une erreur concernant les registres du VDP !
Je vous post le nouveau code corrigé avec un .ROM pour test ...
Edité par 6502man Le 30/06/2018 à 12h21
J'ai posé la question sur msx.org : https://www.msx.org/forum/msx-talk/graphics-and-music/strange-vram-behaviour-with-screen8
Il semblerait que ce soit un comportement normal du VDP dû au fait que dans les modes 7 et 8 il ait besoin d'une plus grande bande passante en VRAM. Je n'ai pas encore tout compris, mais logiquement, cela devrait être transparent pour l'utilisateur. A suivre.
Il semblerait que ce soit un comportement normal du VDP dû au fait que dans les modes 7 et 8 il ait besoin d'une plus grande bande passante en VRAM. Je n'ai pas encore tout compris, mais logiquement, cela devrait être transparent pour l'utilisateur. A suivre.
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)
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
Edité par
6502man
Le 13/07/2018 à 15h10
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
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie