Mystery: game Bestial Warrior with corrupted colors in MSX1

Let me clarify:
To me the point is another. I agree to the fact that the vram timing limit should be reported in openMSX, (and is great that openmsx does this) what i consider totally pointless is the need of emulating this corruption in a perfect way. To know that i'm doing too fast I/O to vdp it is more useful and reliable a message in the console or screen. When i see a small corruption on openMSX and a more large corruption on real machine what is the gain? In both cases i know i'm doing a too fast I/O. The fact that the corruption appears in openMSX and real is non identical way does not help me in solving the issue. It only show me that there is a issue.
It is more useful to get a message like 'too fast I/O at address xxxxx' than relying on a relatively small pixel corruption that may also disappear from time to time anytime i do some screen update.

Thanks to him for testing
But it seems that the pics can't be accessed :/

I used the Sharp_HB-8000_1.2 with the patched/original openMSX code, and it turns out that the blue block that you can see in the menu (at the bottom) is useful to adjust the timing. Of course, this is not accurate at all, but it gives a rough idea. I emulated the Sharp_HB-8000_1.2. In other machines with the TMS9128 the blue block doesn't appear (no matter if it's patched or not).
Original:

Patched:

The more (negative) delay in the VDL access slot, the earlier the blue block begins.
If we could see that menu in real machine it would give us a better idea of the time shift needed in the TMS9128.

Reposting....

The owner of a VG-8020 has told me that back in the time, Dinamic games which were direct conversions from Spectrum ones were very often affected by this issue. It appears that indeed, they shipped these games to the users with that defect.

There's one issue with the tests as I devised them. Apparently, having the CPU clock in sync with the VDP one is not all that common, and that has potential for causing non-deterministic results. Manuel told me in IRC that the models with separate clocks are identified as such in the machine XML files. The V9938 has a CPUCLK pin which is probably used in most models, so the MSX2 results will probably be more consistent.

I guess that the emulator will always run with synced clocks no matter the model.

In this page https://xtremeretro.com/bestial-warrior-parte-2/ (in Spanish, but I think it can be Google translated without much problem) the authors speak about the game. I love the last paragraph, when the authors says that "The MSX was borrowed from a cousin" :D
So yes... most probably what happened is that him used an MSX2, showed quickly to Dinamic, and then the green light was given to sell them game. Without much testing.
In MSX2 the artifacts don't appear since they have usually the 9938 VDP, which is faster than the 9918 and equivalents in MSX1.

Looking at the captures Manuel posted here, it seems that indeed the artifacts are not deterministic, unfortunately. The frame of the menu's screen up colorized at the beginning, and its colors are never changed. However, two different executions of the game (and I assume they're different) give different colors in the frame. In the emulator (patched or not) it's always the same.

If that's the case, then it's much more complicated that a simple time shift. I think it might look like a time shift + some random shift. This "random" actually is not, but I don't there's any way to simulate it with the discrete master clock of the emulator. It's more like forcing the VDP to be outside its working rate, and then probably it's not just that less access windows are caught by the problem, but also that the VDP internally behaves in a pretty (literally) chaotic way that probably not even its designers really master.

To me the key question is to understand if the observed time shifts (that I assumed are in the access windows). I'm thinking of several options.
1) A normal behaviour of the VDP. They open access windows regularly, but with a time shift that the emulator doesn't take into account.
2) There's a bug in openMSX. The code assumes all the time that it's a V9938 and it divides its speed by 8 in the case of one MSX1. But it could be that the time the V/H syncs or starts of display are not accurate. Actually, it never adjusts the number of ticks per line. I'm not saying that there's a bug there at all or that the approach is not exact. Actually the code of the emulator is so great :) All I'm saying that I'll have a look to understand better how its done.
3) The 50/60 Hz difference causes a de-synchronization time shift. This could be related with the previous point.
4) Some changes might be activated with raising edges and some others by falling, and (perhaps) this is not taken into account.
5) Outside its working rate, most of the assumptions about the VDP are not valid. It could advance the access windows just because it's not working correctly.
I'm just guessing some possibilities, without any confirmation.

My guess is that there's a real large time shift in the appearance of the access windows of unknown origin + some (small) "random" malfunction of the VDP because it's working out of the specifications. At least, the observations suggest this to me.