Well, some time has passed and I've been busy but I'm still working on this topic...
I'm trying to split vdp command in 2 steps:
1) set-up from screen line coordinates (x0,y0)-(x1,y1) to byte stream to be written to vdp
2) poll vdp and, when ready, to issue the previously prepared command stream

The poll routine is giving me some speed troubles so I've isolated a particular piece of code to make tests.
The following routine simply checks for 300 times if vdp is ready to accept a new command:

myCnt: defs 2

VdpRdy@::

    ld c,99h       ; VDPIO@ + 1, C = command/status port      ; LINE A

    ld c,1           ; dummy I/O port                                           ; LINE B

    ; select status reg. 2
    ld	a,2
    di
    out	(c),a
    ld	a,80h+15
    out	(c),a

    ; read register value
    in a,(c)
    ex af,af'

    ; select status reg. 0
    xor a
    out	(c),a
    ld	a,80h+15
    out	(c),a

    ei
    ex af,af'
    and 1           ; S#2.CE (bit 0)
    xor 1
    ret

myTest@::
    ld hl,300

?111:
    ld (myCnt),hl
    call VdpRdy@
    ld hl,(myCnt)
    dec hl
    ld a,h
    or l
    jp nz,?111
    ret

I use openMsx in TurboR - R800DRam mode.
I use TurboR's system timer to evaluate how much time is spent when myTest@ is called.
I consider reading system timer trascurable (300 iterations are by far longer).
I've measured the following times:

when LINE A is used and LINE B commented: 12526 ms so approx 41,89us per iteration

when LINE B is used and LINE A commented: 4075 ms so approx 13,5us per iteration

if I replace all in/out instructions with a NOP I get 2698 ms so approx 8,9us per iteration

Looking at these results I would assume that each I/O operation to VDP is:

(41,89 - 13,5) / 5 = 5,678 us longer than I/O to other ports.

Is this correct?
Thanks for your attention
Marco

I'm not entirely sure what it is exactly you're trying to do, but if your question is "is the VDP slow as shit in R800 mode?", then the answer is yes. It's not that the VDP is slower of course, but the R800 incurs *massive* wait-penalties when writing to the VDP. Successive OUTs to the VDP take much longer than on the Z80, and the wait is much longer than actually needed. The engine enforces a wait 3 times longer than actually needed, of -I think- 8us, which is like 57 t-states for the R800. It probably should've been at most half that time, but hey, it's not the only flaw the tR has...

There's a scene myth about it being possible to disable this automatic wait, but no-one has ever figured out how to do this. The stunning lack of data about any of the components unique to this computer doesn't help either, of course.

I'm not sure if the timing in openMSX (or any other emulator) is reliable enough to draw conclusions like this! You should really compare on real hardware and let us know the differences