Difference between revisions of "Emulators"
From MSX Game Library
Line 9: | Line 9: | ||
src="https://docs.google.com/spreadsheets/d/e/2PACX-1vQ_k1n0StRUX8zagkpZrF-ZtkFYwanLKVA6wUm2jlcjMFjCr44wIb6aEKDQcAD7wn0XLwRjYNL7Lk_e/pubhtml"> | src="https://docs.google.com/spreadsheets/d/e/2PACX-1vQ_k1n0StRUX8zagkpZrF-ZtkFYwanLKVA6wUm2jlcjMFjCr44wIb6aEKDQcAD7wn0XLwRjYNL7Lk_e/pubhtml"> | ||
</iframe></html> | </iframe></html> | ||
+ | |||
+ | === VRAM access timing emulation === | ||
+ | {{:VRAM access timing/Emulation}} |
Revision as of 12:13, 4 July 2023
Support
MSXgl's Build tool can automatically launch the emulator of your choice with a configuration that match your project options. Not all emulators support all available options. Here's a list of supported options for each emulator.
VRAM access timing emulation
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).