Difference between revisions of "Emulators"

From MSX Game Library

(How to debug using VS Code)
(How to run a MSX-DOS or BASIC program)
Line 21: Line 21:
 
==== How to run a MSX-DOS or BASIC program ====
 
==== 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.
+
Emulicious contains only the basic C-BIOS free BIOS, which can only run programs in ROM format. By changing a few options in "Options" > "Emulation" > "MSX" menu, you can run programs on disk using proprietary BIOSes.
  
 
First, change BIOS:
 
First, change BIOS:
Line 35: Line 35:
  
 
Now you can auto-launch your disk program from [[Build tool]] or load your .DSK file directly from Emulicious.
 
Now you can auto-launch your disk program from [[Build tool]] or load your .DSK file directly from Emulicious.
 +
 +
==== How to enable MSX-Music ====
 +
 +
Set ''"FM PAC ROMs"'' option in "Options" > "Emulation" > "MSX" menu to [https://aoineko.org/msx/roms/DISK.ROM DISK.ROM].
  
 
==== How to debug using VS Code ====
 
==== How to debug using VS Code ====

Revision as of 23:30, 23 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 options in "Options" > "Emulation" > "MSX" menu, 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 enable MSX-Music

Set "FM PAC ROMs" option in "Options" > "Emulation" > "MSX" menu to DISK.ROM.

How to debug using VS Code

Here are the steps for debugging your program with Emulicious from VS Code:

1. Install Emulicious VS Code extension.

2. Setup "Emulicious Path" in Emulicious extension's settings.

3. Create a launch.json from the "Run and Debug" panel. Configuration should look like:

"configurations": [
        {
            "type": "emulicious-debugger",
            "request": "attach",
            "name": "Attach to Emulicious",
            "port": 58870
        },
        {
            "type": "emulicious-debugger",
            "request": "launch",
            "name": "Launch in Emulicious",
            "program": "${workspaceFolder}/emul/rom/mygame.rom",
            "port": 58870,
            "stopOnEntry": true
        }
    ]

Replace ${command:AskForProgramName} by emul/rom/mygame.rom (where "mygame" is your own game name). If you already have a launch.json, select the "Add configuration" option and select one of the 2 Emulicious configuration.

4. Enable remote debugging in Emulicious. Launch Emulicious et check "Enabled" in "Tools" > "Remote Debugging" menu.

5. Now you are ready to debug your application from VS Code. Go to "Run and Debug" panel and select Launch or Attach (if Emulicious is already running). If "stopOnEntry" is set to true, the VS Code debugger should break at the beginning of your main() function.

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