Well here it is.
At the moment only 4 modes, c## indicates colormode, [ ] indicates normal (XTAL1) and ( ) indicates overscan (MCKIN).
Further more to know is that these are again 60Hz values, and those values are in kb. All values do not differ wether TPSET or PSET is used (or any LOG operation for that matter).
The accuracy is now < +256 bytes.

Command | c16[ ] | c16( ) | c64[ ] | c64( ) |
---------------------------------------------
 LMMM   | 36.250 | 22.500 | 36.250 | 22.500 |
 BMLL   | 18.125 | 11.250 | 36.250 | 22.500 |
 BMXL   | 36.500 | 22.625 | 36.500 | 22.750 |
 BMLX   | 36.250 | 22.500 | 36.250 | 22.500 |
 LMMV   | 51.750 | 33.000 | 76.750 | 48.750 |

Somehow I feel BMLL is a bit off... have to check that sometime later.

Did you test it with image width equal to the lines you copied. I expect a bigger difference between BMLL and LMMM when it's not. equal

For the rest I think these values are not bad at all. Would be nice to put the 25Mhz osc on the v9990,which is used for VGA modes. Probably it will be 1.2 * faster (25Mhz/21Mhz). Btw I don't expect a big difference between 50 and 60hz,because the v9990 has dual port dram. The copy stuff doesn't have to wait for non display periods like in the v99x8.

No difference between 50 Hz and 60 Hz!
Sure, but not if you set a testperiod that is from vblank to vblank (one int). 1/60 of a second is less than 1/50 of a second, so having more time results in more bytes transfered.
I could post the 50 Hz table, but multiplying the 60 Hz table with 1.2 gives a very accurate 50 Hz approximate value, so I am not even gonna bother.

Now the difference between BMLL and LMMM very strange to say at least. In my latest tests LMMM is faster by far (like 2x), must be a bug?!

On the other hand BMXL seems to be a bit faster than LMMM. Not as much as you would espect.
(Yes msd, I did use unequal widths, does not seem to have effect at all).

GhostWriterP: what would be very useful to the openMSX team is the testprogram used to obtain those results. Then if we implement the timing in openMSX we can immediately test whether we get the same results as on a real MSX... Please share it!

@GhostwriterP: Yeah okay per int maybe. But the transfer speed per second is the same or isn't?

That BMLL and LMMM difference is very strange indeed. I would expect it the other way around. Did you try anything in 16bit mode too?

Here is a new updated table:

Command | c16[ ] | c16( ) | c64[ ] | c64( ) |
---------------------------------------------
 LMMM   | 36.250 | 22.500 | 36.250 | 22.500 |
 BMLL   | 36.250 | 22.500 | 36.250 | 22.500 |
 BMXL   | 36.500 | 22.625 | 36.500 | 22.750 |
 BMLX   | 36.250 | 22.500 | 36.250 | 22.500 |
 LMMV   | 51.750 | 33.000 | 76.750 | 48.750 |

BMLL silly mistake, works in bytes not in dots

@msd: the b/s transfer speed is indeed the same for both 50 Hz and 60 Hz. That is why you can use the scale factor 1.2 to get those 50 Hz values. BMXL seems to be the fastest, not by far, but still.

@manuel: I will think about it, but I must warn you, the test takes a few minutes. The faster the v9990 command the longer takes the test.

Quote:

Quote: This part is really badly documented in the v9990 manual.. Only a small very vague note about it Euh? The mapping of VRAM addresses to the VRAM banks is very clearly documented. With that info you should be able to figure out how these copy commands should be set up...

Yeah right, easy to set up, but I still get a 'scaled' version so I really don't think BMXL is gonna work in P1.
And with 'scaled' I mean something like: o7o7o -> o 7 o 7 o. Nice but not quite right is it?.

I don't care how long the test takes So, please share it It will give us an opportunity to greatly improve the emulation accuracy of the V9990 command engine.

@gostwriter: I will do some testing on the bmxl command too