Hey, I was just after some wisdom from the mighty gfx9000 coders here. I'm planning my tooling for symbos game mode, so was hoping for some advice. I will be using just P1 mode as it offers parallax/sprites etc. My question is since I'm trying to hide a coder from the hardware, is it best I reserve 256x4 patterns purely for sprites at a fixed position on the pattern table. Trying to move the 256 sprite offset around seems limiting and an extra level of complexity for the coder.
Consequently I assume I will be able to easily copy a 8x8 pattern tile into the position of a sprite pattern tile. Patterns are stored linear right? And Yes I know I'd have to do it 4 times.
Around how many is it reasonable to be able to copy a second... I was hoping to do sprite animation at perhaps 5-10 times a second.
I cant see any method for flipping x/y of patterns. I assume I'm not missing something?
Hope I'm making some sense and not coming across as a complete idiot Never done any vdp coding (Amstrad CPC bitmap guy) so I probably am.
Cheers Rob
The memory in P1 mode is divided into 5 blocks:
0x00000-0x3fdff: Pattern Generator Table for plane A and Sprite Generator Table. This is a big bitmap: 256x2044x4bpp, so the 0,0 and 1,0 pixels are located at 0x00000, 2,0 and 3,0 are at 0x00001 and 0,1 and 1,1 are located at 0x00080.
That memory is used for tiles and sprites graphics.
0x3fe00-0x3fff4: Sprite Attribute Table. Attributes for 125 sprites (Y,PAT,X,ATR)*125
0x40000-0x7bfff: Pattern Generator Table for plane B. The same as Pattern Generator Table for plane A, except the bitmap is 256x1920x4bpp
0x7c000-0x7dfff: Name Table for plane A
0x7e000-0x7ffff: Name Table for plane B
is it best I reserve 256x4 patterns purely for sprites at a fixed position on the pattern table.
Register 25 modifies the offset for the sprites in the Sprite Generator Table. You can, set R#25 to 4, then the firsts 512 lines in that bitmap can be used as tiles (2048 8x8 tiles ) and the next 256 lines as sprites (256 16x16 sprites).
Trying to move the 256 sprite offset around seems limiting and an extra level of complexity for the coder.
Do you need more than 256 sprites?, You can copy graphics placed outside the Sprite Generator Table using LMMM command as you need them.
Consequently I assume I will be able to easily copy a 8x8 pattern tile into the position of a sprite pattern tile.
This is the graphics structure in GnG: Stage 6 Sprites
Tiles are not visible in that file.
"Usable sprites" are in In the first block (lines 512 to 767 in the bitmap). Lines 768 and above can be copied using LMMM to the first block as they are needed.
Around how many is it reasonable to be able to copy a second... I was hoping to do sprite animation at perhaps 5-10 times a second.
V9990 is quick enough to make some copys, but maybe you can make animation using the "usable sprites". You only need to change the pattern number in the Sprite Attribute Table.
Thanks. Seeing the graphics laid out helps. Its actually in some ways more flexible being able to copy various sized areas around.
Hey I hope somebody can help. I'm trying to implement v9990 into Quigs language. Can anyone please tell me what I need to pass in B,C,D & E as I want to set the screen up in P1 mode. Cheers
SetScreenMode: ; A = Mode ; B = Bit per dot ; C = Image size ; D = Interlace ; E = Palette control register LD L,A ADD A,A ADD A,L ; A = A * 3 LD HL,G9K_MODE_TABLE ADD_HL_A LD A,G9K_SCREEN_MODE0 OUT (G9K_REG_SELECT),A LD A,(HL) ; Get fixed settings for mode reg 6 INC HL OR A,B ; Set bits per dot OR A,C ; Set image size OUT (G9K_REG_DATA),A LD A,(HL) ; Get fixed settings for mode reg 7 INC HL DEC D INC D ; Is d 0? JR Z,$+4 OR A,G9K_SCR1_EO+G9K_SCR1_IL OUT (G9K_REG_DATA),A LD A,(HL) OUT (G9K_SYS_CTRL),A G9kWriteReg G9K_PALETTE_CTRL,e RET
I only want to set p1 mode, so is this correct
.Quig_g9k_SetMode ld a,g9k_SCREEN_MODE0 out (g9k_REG_SELECT),a ld a,1 out (g9k_REG_DATA),a ld a,0 out (g9k_REG_DATA),a ld a,g9k_SYS_CTRL_XTAL out (g9k_SYS_CTRL),a ld a,g9k_PALETTE_CTRL out (g9k_REG_SELECT),a ld a,0 out (g9k_REG_DATA),a ret
I have problems with my PC. Three attempts to write this program this weekend, and three times the PC shutted down...
Program assembled with sjasm:
output "p1.rom" org 0x8000 db "AB" dw start ds 12 start: call set_p1_mode ;clear First 256KB using commands ld hl,clear_vram_1st_half_parameters call clear_vram ;clear Second 256KB using commands ld hl,clear_vram_2nd_half_parameters call clear_vram ;initial palette is all black ld hl,palette ;this is a copy of v9918 palette call write_palette ;draw tile 0 as a set of little boxes showing all 16 colors ld hl,write_tile_0_command call write_tile_0 ld b,32 ld c,0x62 ld hl,tile_0 .next_byte: outi jr nz,.next_byte jr $ set_p1_mode: xor a out (0x67),a ld a,6+01000000b ;register 6. Read does not increment register but Write does. out (0x64),a ld a,00000101b out (0x63),a ;register 6 ld a,00000000b out (0x63),a ;register 7 in a,(0x63) and 01111100b or 10000010b ;screen enabled. Ram 512KB out (0x63),a ;registrer 8 ret write_tile_0: ;wait for command end in a,(0x65) rra jr c,$-3 ld a,36 out (0x64),a ld b,12 ld c,0x63 otir ld a,52 out (0x64),a ld a,0x10 out (0x63),a ret write_tile_0_command: dw 0 ;dx 36 37 dw 0 ;dy 38 39 dw 8 ;nx 40 41 dw 8 ;ny 42 43 db 0 ;arg 44 db 0x0c ;lop 45 dw 0xffff ;mask 46 47 tile_0: db 0x00,0x11,0x22,0x33 db 0x00,0x11,0x22,0x33 db 0x44,0x55,0x66,0x77 db 0x44,0x55,0x66,0x77 db 0x88,0x99,0xaa,0xbb db 0x88,0x99,0xaa,0xbb db 0xcc,0xdd,0xee,0xff db 0xcc,0xdd,0xee,0xff write_palette: ld a,14 out (0x64),a xor a out (0x63),a ld c,0x61 ld b,16*3 ;16 colors*(r,g,b) otir ret palette: db 0x00, 0x00, 0x00 db 0x00, 0x00, 0x00 db 0x08, 0x16, 0x09 db 0x0e, 0x19, 0x0f db 0x0b, 0x0a, 0x1b db 0x10, 0x0e, 0x1d db 0x16, 0x0b, 0x0a db 0x0c, 0x1b, 0x1d db 0x1b, 0x0c, 0x0b db 0x1f, 0x11, 0x0f db 0x19, 0x18, 0x0b db 0x1b, 0x19, 0x10 db 0x07, 0x14, 0x08 db 0x16, 0x0c, 0x16 db 0x19, 0x19, 0x19 db 0x1f, 0x1f, 0x1f clear_vram: ;wait for command end in a,(0x65) rra jr c,$-3 ld a,36 out (0x64),a ld b,14 ld c,0x63 otir ld a,52 out (0x64),a ld a,0x20 out (0x63),a ret clear_vram_1st_half_parameters: dw 0 ;dx 36 37 dw 0 ;dy 38 39 dw 256 ;nx 40 41 dw 2048 ;ny 42 43 db 0 ;arg 44 db 0x0c ;lop 45 dw 0xffff ;mask 46 47 dw 0x0000 ;color 48 49 clear_vram_2nd_half_parameters: dw 512 ;dx 36 37 dw 0 ;dy 38 39 dw 256 ;nx 40 41 dw 2048 ;ny 42 43 db 0 ;arg 44 db 0x0c ;lop 45 dw 0xffff ;mask 46 47 dw 0x0000 ;color 48 49 ds 0xc000-$
Thanks, thats really helpful. I did manage to make a little progress myself, but thats great. I hope you will like the results
assembler,
With W7 in the OpenMSX, load well.
@Trebmint2: It is very usefull to read the v9990 manual.
But anyway.. This are the settings for p1
LD A,G9K_MODE_P1
LD B,G9K_SCR0_4BIT
LD C,G9K_SCR0_XIM256
LD D,0
LD E,G9K_PAL_CTRL_PAL
Hello,
I am a fan of the CPC.
A year or two ago the CPC Powergraph was released which has a V9990 graphics chip on it. It was made by Technobytes.
I was loaned one by @Prodatron and I've been testing it with a view to emulate it in my CPC emulator.
So far I've tested the Command Engine and made a set of tests. With the help of the openMSX guys I have made MSX versions of these tests.
I am documenting my discoveries here on the CPCWiki:
http://www.cpcwiki.eu/index.php/V9990
I hope this information will be useful to those writing games for V9990 on MSX.