wait 15 T-States between reading and writing to Vram

In an attempt to save a few cycles I've jumped the bandwagon and looked into this. Seemingly there isn't much gain when the screen is on, but I wanted to do something in the screen blank / immediately at the interrupt start. From what I can see, norakomi's question was not about vblank, but when screen is on, so this is slightly on the side but still very much related.

It is mentioned both on the wiki and the map-pages that there is no speed limit, in this case. Result:

It works in openmsx17.
It doesn't work on physical machines.

Tested on a1-wsx (T9769C chipset) and svi-738-msx2.

My test: Updating sprite attribute table from a list of bytes with yx-values, like this: y, x, y, x, y, x ...
Code: Unrolled macro like this:

.macro writeSpriteAttrTableRamToVramMasksOne
	outi
	outi
	in a, ( VDPIO )
	in a, ( VDPIO )
.endm

==>

.rept 8
	writeSpriteAttrTableRamToVramMasksOne
.endm

Unless I misunderstood something or did something wrong, openmsx does not emulate this 100% and there is actually a speed limit here.

Yes. During this development, I have tested on these machines in openmsx:

* Sanyo_phc-70FD2 (+2 wait-states)
* Panasonic_FS-A1WSX (+1 wait-states) - this one tested physically on
* Philips_NMS_8250

All the above works in openmsx. I don't have a openmsx machine-"profile" for my modded SVI-738 MSX2.

I know, I know, to fix this, we must have an isolated test-case! I don't have that, it may be a bit of work to set up, which will take some time. My current results comes from Lilly's Saga, which does comes with a lot of code that is not ready for sharing at this point in time. Given that I'm not mistaking here, and this (edge-)case really is an error, how interesting is it for the openmsx-team to fix it? It would help me to know your priorities wrt how I should prioritise providing an isolated testcase.

A copy of the SAT takes 3.2% cpu. And then with the two IN it is 16% faster. You spend huge effort in trying to save 16% of 3.2% cpu.
So, this thread practicaly is saying the typical "the MSX VDP is slow", for something that took 0.5% cpu... But the time is not taken by the VDP but by some unknown code.

But something got broken. With this "optimization" of copying only 2 of 4 bytes, pattern animation is lost.
When you need 0.5% cpu, why not search in the other 97% (!), why insist to search in those tiny 3% and then break something.

Effectively...
And again the usual mantra: "VDP is slow".
the vdp is not so slow, in most operations, the very high overhead is the VRAM address ptr setup which have a lot of ceremony to be executed, expecially on msx2 machines.
for some contiguos block operations (vram operations tends to be block operations) the speed, even in active area is not that bad.
a typical otir takes the same amount of time of an LDIR and due to autoincrement feature of VDP could save some z80 registers and increments that could be used for extra things.