what easy and fast ways are there to fill a complete page in VRAM with a color??

There are FILL instructions but they the FAST ones always leave some lines at the edges uncolored...

Dunno, I usually use commands. Just a highspeed fill would do the trick. (cmd $C0) You could also use setwrt and then out a gazillion of $00's or whatever other color you need... This is pretty basic stuff tho, are you sure you read the command section of the VDP's manual?

yeah I read it,
but everytime I use an instruction like the $c0 command,
there is allways 1 line at a edge which is not filled.....
It's like this command leaves out some spaces......

with sx=0,sy=0,dx=0,dy=0,nxl=255,nyl=255...............

anyway a fast command allways copies / fills with 2 pixels at a time..

so if I can fill for instance (40,40)-(41,79) -> 2 vertical lines
or (0,0)-(1,9) -> 2 vertical lines
or (0,0)-(9,1) -> horizontal lines

but because it only fills with 2 pixels at a time...

(0,0)-(2,20) is not possible, and when there coordinates have been given then...

then what???

will (0,0)-(1,19) be filled????

screenlenght=256, remember!

fillvram: (pseudo code)
vdp_setwrite(adress)
212*(256/2): out(vdp),colour

would be very fast. doing the VDP command ($c0) you'd only have to command the VDP and it will to the trick itself, don't have to wait for it.

Quote:

anyway a fast command allways copies / fills with 2 pixels at a time.. so if I can fill for instance (40,40)-(41,79) -> 2 vertical lines or (0,0)-(1,9) -> 2 vertical lines or (0,0)-(9,1) -> horizontal lines but because it only fills with 2 pixels at a time... (0,0)-(2,20) is not possible, and when there coordinates have been given then... then what??? will (0,0)-(1,19) be filled????

then the FAST command can't be used

Quote:

screenlenght=256, remember! fillvram: (pseudo code) vdp_setwrite(adress) 212*(256/2): out(vdp),colour would be very fast. doing the VDP command ($c0) you'd only have to command the VDP and it will to the trick itself, don't have to wait for it.

Would this be fast enough to fill within 1 frame???
because the fill instruction does fill the entire screen within 1 frame (at least I dont see any hampering if I keep filling....

dunno, never tested that. but in any case you'll have to wait untill fill is done (either by looping throught the "out' instructions or for the VDP to finish the command) it WILL take some time, dunno if it'll fit a frame. why would ya?! if it's for screen build up, better fill the gaps with little fills I suppose.

Quote:

Quote: screenlenght=256, remember! fillvram: (pseudo code) vdp_setwrite(adress) 212*(256/2): out(vdp),colour would be very fast. doing the VDP command ($c0) you'd only have to command the VDP and it will to the trick itself, don't have to wait for it. Would this be fast enough to fill within 1 frame??? because the fill instruction does fill the entire screen within 1 frame (at least I dont see any hampering if I keep filling....

No, the VDP is crap, as is the Z80... Even without taking wait-states, refresh and the loop into consideration just doing an OUT($98),A a total of 128x212 times would take 128x212x11 = 298496 T-States. Assuming there's 60000 T-States / Interrupt (and it's less) that would mean 5 ints to clear the screen. When taking into account you'll need to do the SETWRT, there are M1 waitstates and realisticly at least 212 loops you're looking at 6-7 ints, probably even a little more. Anyhoo, use the command like I suggested. If you use the command, you'll be looking at roughly 4.75 ints, plus it doesn't tie up the CPU. As you can see though, clearing the screen on MSX is not something that can be done in an int...

thats what I figured out as well,
I made a loop with writing to the VDP in order to 'clear' the screen,
didnt work within a frame....
no indead, 6-7 ints looked more like it.

However $c0 instruction did do the fill within one int. but had some problems with the edges,
thats why I started this post....
It seemed stupid to me, a fast fill instruction that cant fill the ENTIRE screen.....

Quote:

It seemed stupid to me, a fast fill instruction that cant fill the ENTIRE screen.....

But it can, if you set the right parameters

Quote:

thats what I figured out as well, I made a loop with writing to the VDP in order to 'clear' the screen, didnt work within a frame.... no indead, 6-7 ints looked more like it. However $c0 instruction did do the fill within one int. but had some problems with the edges, thats why I started this post.... It seemed stupid to me, a fast fill instruction that cant fill the ENTIRE screen.....

Idd, 6-7 ints would be the estimate. But, unless you discovered some fill I had never heard of, the fill command didn't wipe the screen in one int either. It would need at least 4 ints, as far as I know... About the size, remember that 0,0 - 255,211 would not be nx 255, ny 211 but nx 256 and ny 212. You're forgetting that line 0 is also counted, as is 'column' 0. So, set NX to $0100 and NY to $00D4 and it should do the trick just fine...

try looking into the LMMV VDP command. Something like

LINE (100,30)-(195,135),12,BF

will look like this for the VDP:

R#36 & R#37 = DX = 100
R#38 & R#39 = DY = 30
R#40 & R#41 = NX = (195-100+1)=96
R#42 & R#43 = NY = (135-30+1)=106
R#44 = COL =12
R#45 = ARG = 0
R#46 = CMD = LMMV = $80

of course there are people who will say HMMV ($C0) will do things faster. I can only agree with them. This is because HMMV fills an area on byte level which can cause issues around the edges when the NX is an odd value, since 1 pixel (SCREEN 8), 2 pixels (SCREEN 5 and 7) or 4 pixels (SCREEN 6). LMMV works on pixel level and enables logic operations which makes the entire command slower.

Thanx alot !!!!

The stupid thing is that I allways used NX=255, and NY=255.
Because when loading to registers also a value from 0 to 255 is accepted....

I guess thats the problem.

And as far as filling the whole page in 1 interrupt.
I didnt see any stuttering in the game when I filled the whole page,
but I guess it means that the fill is just devided over 2 (maybe 3) frames without affecting gameplay....

Quote:

set NX to $0100 and NY to $00D4 and it should do the trick just fine...

ehrm, but when in my assembler I use:

db $100
or
db 256
I get an error.
Value too big