Difference between revisions of "Emulators"

From MSX Game Library

(Emulicious)
Line 13: Line 13:
  
 
=== openMSX ===
 
=== openMSX ===
 +
<img style="height:32px; float:right;" src="https://openmsx.org/images/penguin.gif" />
  
 
=== Emulicious ===
 
=== Emulicious ===
Line 38: Line 39:
  
 
=== blueMSX ===
 
=== blueMSX ===
 +
<img style="height:32px; float:right;" src="https://www.bluemsx.com/img/bluemsx.png" />
 
Setup emulation for [https://www.msx.org/articles/obsonet ObsoNET cartridge]: https://www.msx.org/forum/msx-talk/emulation/bluemsx-emulating-obsonet-and-tcp-ip-unapi
 
Setup emulation for [https://www.msx.org/articles/obsonet ObsoNET cartridge]: https://www.msx.org/forum/msx-talk/emulation/bluemsx-emulating-obsonet-and-tcp-ip-unapi
  

Revision as of 12:46, 22 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.

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:

For MSX-DOS 1 or BASIC:

For MSX-DOS 2:

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

blueMSX

Setup emulation for ObsoNET cartridge: https://www.msx.org/forum/msx-talk/emulation/bluemsx-emulating-obsonet-and-tcp-ip-unapi

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).