Difference between revisions of "Emulators"
From MSX Game Library
(→Emulicious) |
|||
| Line 10: | Line 10: | ||
</iframe></html> | </iframe></html> | ||
| − | == | + | == Specific setting == |
| − | |||
| − | |||
| − | |||
| − | |||
=== openMSX === | === openMSX === | ||
| Line 39: | Line 35: | ||
==== How to debug using VS Code ==== | ==== How to debug using VS Code ==== | ||
| + | |||
| + | |||
| + | |||
| + | == VRAM access timing emulation == | ||
| + | [[VRAM access timing]] limitations are supported by few emulators. | ||
| + | |||
| + | {{:VRAM access timing/Emulation}} | ||
Revision as of 12:26, 22 July 2023
Contents
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.
Specific setting
openMSX
Emulicious
Here is some tips to test your MSXgl program using Emulicious.
How to run a MSX-DOS or BASIC program
Emulicious contains only the basic C-BIOS free BIOS, which can only run programs in ROM format. By changing a few optiosn, you can run programs on disk using proprietary BIOSes.
First, change BIOS:
- MSX 1: Set "MSX1 BIOSes" option to MSX.ROM,
- MSX 2: Set "MSX2 BIOSes" option to MSX2.ROM and MSX2EXT.ROM.
For MSX-DOS 1 or BASIC:
- Set "Disk ROM" option to DISK.ROM.
For MSX-DOS 2:
- Set "Disk ROM" option to DISK.ROM.
- Set "MSXDOS2 ROMs" option to MSXDOS2.ROM.
Now you can auto-launch your disk program from Build tool or load your .DSK file directly from Emulicious.
How to debug using VS Code
VRAM access timing emulation
VRAM access timing limitations are supported by few emulators.
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).