View source for VRAM access timing/Emulation

==== openMSX ====
openMSX <small>(18.0)</small> supports VRAM access time emulation with the following limitations:
* In the default mode (display and sprites enable), it is a little too optimistic, i.e. within about 1~2 t-states, accesses that will work on openMSX will not work on a real machine. For example, on a Philips NMS 8250, an access with an interval of 19 t-states will work on openMSX but may fail on a real machine.
* With display disabled, it does not emulate at all the access time limitations of the non-bitmap display modes on V9938/58. This can be a major source of error, as this limitation doesn't exists on TMS9918 and don't seem to be documented.
* With sprites disabled, it still emulates too optimistically, sometimes with a 3 t-state gap between valid intervals in openMSX and those observed on a real machine. For example, while an access in graphics mode 1 with an interval of 12 t-states is valid in openMSX, it requires at least 15 t-states on a real machine.

<u>Note:</u> openMSX emulates quite faithfully write failures linked to a VDP command active on the same VRAM zone.

==== Emulicious ====
Emulicious <small>(2023-04-22)</small> has a limited emulation of VRAM access time:
* On TMS9918, a limitation exists for the default mode (display enabled) but it does not correspond to the value observed on a real machine. All screen modes seem to have an access limit of 25 t-states, whereas valid intervals are supposed to be 12 t-states for Text 1 mode and 29 for the others.
* On the other hand, with the screen off, access times are correct.
* On V9938/58, no limitation seems to be emulated at all.

<u>Note:</u> A forthcoming version of Emulicious should enable more precise emulation of VDP access timing.

==== Others ====
Other emulators do not emulate VDP access timing constraints at all: fMSX <small>(6.0)</small>, blueMSX <small>(2.8.2)</small>, MEISEI <small>(1.3.2)</small>, RuMSX <small>(0.83)</small> and WebMSX <small>(6.0.4)</small>.