Difference between revisions of "VRAM access timing/Emulation"
From MSX Game Library
(Created page with "==== 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...") |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | ==== openMSX ==== | + | ==== {{openMSX}} openMSX ==== |
| + | <img style="height:32px; float:right;" src="https://openmsx.org/images/penguin.gif" /> | ||
openMSX <small>(18.0)</small> supports VRAM access time emulation with the following limitations: | 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. | * 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. | ||
| Line 5: | Line 6: | ||
* 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. | * 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>Note</u>: openMSX emulates quite faithfully write failures linked to a VDP command active on the same VRAM zone. |
| − | ==== Emulicious ==== | + | ==== {{Emulicious}} Emulicious ==== |
| + | <img style="height:32px; float:right;" src="https://emulicious.net/Emulicious.svg" /> | ||
Emulicious <small>(2023-04-22)</small> has a limited emulation of VRAM access time: | 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 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. | ||
| Line 13: | Line 15: | ||
* On V9938/58, no limitation seems to be emulated at all. | * On V9938/58, no limitation seems to be emulated at all. | ||
| − | <u>Note | + | <u>Note</u>: A forthcoming version of Emulicious should enable more precise emulation of VDP access timing. |
==== Others ==== | ==== 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>. | 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>. | ||
Latest revision as of 22:21, 12 January 2024
openMSX
openMSX (18.0) 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.
Note: openMSX emulates quite faithfully write failures linked to a VDP command active on the same VRAM zone.
Emulicious
Emulicious (2023-04-22) 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.
Note: 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 (6.0), blueMSX (2.8.2), MEISEI (1.3.2), RuMSX (0.83) and WebMSX (6.0.4).