time depends on the active screen and on the orizontal width of the block
(and on the refresh rate 50/60Hz and on the sprite active and on the moon phase..)

given the screen and the logical operation,

a 16x4 block is faster than a 8x8

you can assume a formula like

T = a* dx*dy + b*dx

where a and b depends on the screen mode on the logical operation

go here for measures

http://map.tni.nl/articles/vdp_commands_speed.php

Yes, I saw the test results on this page, I just don't know, what kind of blocks he filled/copied.
For proportional text output I will need to copy (logical) single W x 8 blocks for each char, where W is between 1 and 8. I am sure, normally you would use byte copy, if the text is not proportional, so I wonder, if in my case it won't be too slow at the end.

I've no fresh data, sorry

Quote:

Quote: transparent mode is fast as any other logical copy i.e. like a (dead) snail Hm, any idea how many micro seconds it (more or less exactly) takes to copy a 8x8 pixel block inside the VRAM with logical copy?

good enough just for typing and showing littles sentences at a time....

very slow for re-drawing all a window at a PAINT event

the vdp allow to do scrooling by itself so that helps, but clipping at the same time is a lot of work for only the CPU taking including seconds to do that.

a fast way is prebuffering but that eats a lot of RAM but it is clean, easy and faster.

The clock chip is on every MSX2. See also http://map.tni.nl/resources/
and http://map.tni.nl/resources/msx_io_ports.php

Quote:

good enough just for typing and showing littles sentences at a time.... very slow for re-drawing all a window at a PAINT event

Hm, bad news. Maybe I should prepare a line of proportional text in the CPU memory and copy it with "vram write" or the "highspeed put byte" command into the vram? Did someone already write a fast proportional text output routine? Just want to know, if it is somehow possible...

Prodatron, i've wrote a 'drawchar' routine that draw a 8x8 pattern requiring hl pointing to the charater shape, d=foreground color e=background color . This sub can draw at any x,y location. To give you an idea of much is fast i can draw about 768 8x8 patterns in less more than 1 second.

If you want, i can send you the source.

Regarding vdp command speed, as already said by artrag, depends much. However, to give an example:

Blitting an area in logical (pixel mode) can copy from a specified location to another location about 100000 pixels/sec. @50hz
Blitting an area in byte ( so called high-speed mode) can copy from a specified location to another location about 175000 bytes/sec. @50hz

If, you disable the HW sprites, you can increase the speed a little. For example:
with sprites on
Blitting an area in byte ( so called high-speed mode) can copy from a specified location to another location about 175000 bytes/sec. @50hz

with sprites off
Blitting an area in byte ( so called high-speed mode) can copy from a specified location to another location about 220000 bytes/sec. @50hz

Umh, I forgot: it is not a proportional routine, it draws an 8x8 pixels area, using 1 bit per pixel font stored in RAM not VRAM

Fill box operations are roungly 2x faster than copy operations. If you want bigger charaters maybe you can get decent result by submitting to vdp single box fill operations for each dot you want to draw. However this can be better that let do the hard work to the cpu only if you work with charaters bigger than 1 dot (for example x/y zoommed charaters).

Thanx, PingPong, maybe your routine can be useful for chars inside the text line. I would be interested in the source (jmika at symbos dot de). Anyway I have more and more the feeling, that preparing a text line in the CPU memory and then copying it into the screen ram will be the fastest way.

Another problem: Currently I try to switch to screen mode 6 with this sequence:
di

ld a,8
out (#99),a
ld a,128+0
out (#99),a

ld a,32
out (#99),a
ld a,128+1
out (#99),a

ld a,0
out (#99),a
ld a,128+2
out (#99),a

ei

After this I set the palette like described here ( http://map.tni.nl/articles/vdp_tut.php#palette ) and then I write 256 bytes starting from address 0 in the VRAM. Unfortunately the screen stays completely black and empty. In the debugger, I can see, that the bytes have written correctly in the VRAM but I don't see anything on the screen.
Any idea what I did wrong?

You need to set bit 6 of register one. This enables the screen.

For practical purposes you need to set a few more registers though. I usually set the screen by writing the first 12 registers with an otir to port $9B. You can copy values for that from basic screens (easiest with an emulator) and change them as you figure out what you need.

Great, now I see something Now there is a repeat of the screen data every 8 lines. So you are right, I didn't initialize all necessary things. Where do I find the default values ("basic screens"?

With that I meant, do a

10 screen 5
20 goto 20

and copy the values from debugger or something

check the regs in the emulator when you set it to a screen mode in basic.