I think emulators emulate VDP commands at a higher level than should be, timing is not accurate but a close estimation. (an openmsx dev like wouter can probably tell more about it)

about accuracy i think this:
- we do not have documentation about timing and the vdp - state machine steps.
- we have probably done some measurements and emulated the speed in the average way.
- this lead to good accuracy for the most used commands (box fill, copy, even logical or byte based), however i think others command are emulated less precisely, because they are used seldom (point, src, pset, line), or becase the cpu is slower than the speed the vdp can operate.
However, will be fine to have a real model of the VDP, especially for FPGA implementations.

@Manuel: update. tested on openmsx 0.9 rc1. Results are the same as bluemsx. A little faster than real hw

The VDP command timing in openMSX and blueMSX is identical as far as I know. The timing model in both emulators (and all other emulators?) has known limitations. I'll take a HMMV command of size (X,Y) as an example. Both emulators assume that each of the X*Y pixels takes exactly 49 VDP clock cycles to execute (21MHz) (sprites and display disabled). I once started doing more detailed measurements and found that a better model is 49 cycles per pixels plus 63 cycles per line (so per Y size). This model approximates the real VDP timing better, but it's still not 100% exact. I didn't yet include this improved timing model in openMSX, and I also didn't do measurements yet on other commands than HMMV. I should continue working on this some day. Help would be appreciated.

@Manuel: update. tested on openmsx 0.9 rc1. Results are the same as bluemsx. A little faster than real hw

The VDP command timing in openMSX and blueMSX is identical as far as I know. The timing model in both emulators (and all other emulators?) has known limitations. I'll take a HMMV command of size (X,Y) as an example. Both emulators assume that each of the X*Y pixels takes exactly 49 VDP clock cycles to execute (21MHz) (sprites and display disabled). I once started doing more detailed measurements and found that a better model is 49 cycles per pixels plus 63 cycles per line (so per Y size). This model approximates the real VDP timing better, but it's still not 100% exact. I didn't yet include this improved timing model in openMSX, and I also didn't do measurements yet on other commands than HMMV. I should continue working on this some day. Help would be appreciated.

Maybe i can send you a small .com file that i've used to measure timing in active area.
work in this way:
for example: linespd 200 200
Draw a line of 200x200 pixels on screen and i do measurement in this way:
1) the command is started on scanline 0
2) i set an int @ scanline 211 and i verify that vdp command flag is not "busy". If it is not busy i try with scanline 210, 209 and so one, until i reach a "busy" condition.
3) I print out the n. of scanline where i've found the last not busy condition

because of the time the z80 take to start the command, react to interrupts etc. there are almost 3 scanlines of delay that i need to take into account.

ARTRAG did some test with this program and it does appear that a single "pset" when doing a line take approx 6.8 us
It also appear that the vdp takes more time (!) when doing a diagonal line with both width == height
A full horizontal line or vertical line or little takes somewhat less.
a 200x200 lines take approx 25 scanlines.

I can send, if is useful the test program.
Please suggest me some interesting test on line command. I've tryed those:

1) the command is started on scanline 0
2) i set an int @ scanline 211 and i verify that vdp command flag is not "busy". If it is not busy i try with scanline 210, 209 and so one, until i reach a "busy" condition.
3) I print out the n. of scanline where i've found the last not busy condition

This does not seem very accurate... I did another test that syncs to CPU speed that should be pretty accurately emulated on both BlueMSX and OpenMSX, please try it:

... sources are included. It has also possibility to save screenshots for more easy comparison between emulator created image and real hardware created image. As long as you run the software with same key presses it should generate identical picture on emulators as well as real hardware. You may also want to try it in different screen modes.

Tip: Start of line is the end where first color is white and next is green

I have only tested this now on BlueMSX, so I leave the actual tests and math for you. Sources should be pretty self explaining.

About active area.
If you got the timing of the whole screen and the timing of blanked screen then you can make guesses about speed in the active area. 50hz vs 60hz is different percentage of active area, also 212 vs 192, giving additional hints on whether obtained figures are plausible.

So you could start with a tiny app that just draws lines for around ten seconds.
run with disabled interrupts.
Does MSX2 have timers. if not, do 60 seconds and use a stopwatch

In the end that may be less % off than line interrupt handlers trying to do things.

p.s. I wonder what sprite engine is doing in the border.
I mention it because of blitter speedup with sprites turned off, another factor.

I would suspect it continues same DMA
But wasnt there something about collision on MSX2 being different in the border? Or was that in horizontal border?
Does MSX2 in vertical border turn off DMA.
Need to know in the whole-screen vs blank calculations.