The latest version of the openMSX manual can be found on the openMSX home page:
http://openmsx.sourceforge.net/manual/
You can also use this URL to get up-to-date versions of the hyper links if you printed out this manual.
This manual is about openMSX, the open source MSX emulator that tries to achieve near-perfect emulation by using a novel emulation model. You can find more information about openMSX on the openMSX home page. You can also download the emulator itself from there.
openMSX is in alpha state, which means that some things work but not all features are implemented yet. Many emulation features are implemented, but in terms of user interface it is rather bare bones, unless you use the optional Graphical User Interface dubbed openMSX Catapult, which has separate manuals for now. However, since the emulation is already pretty good, it would be nice if non-insiders would be able to play with it, too. For those people, we have written this guide. It explains how you can make use of the features of the emulator, once you have got it running.
This manual tells you how you can use openMSX, once it has been installed and properly set up. You should be able to use most of the features of openMSX if you have read it. If you are using using openMSX with Catapult, you don't have to pay attention to the exact command and setting names. However it is still useful to read this document to find out how openMSX works and learn its terminology.
Disclaimer: We do not claim this guide is complete or even correct. What you do with the information in it is entirely at your own risk. We just hope it helps you enjoy openMSX more.
The following people contributed to this document in one way or another:
Thanks to all of them!
This section gives an overview of the changes that were made to this document. It doesn't contain every single modification (use the CVS log for that), only the big picture.
If you start openMSX without any command line parameters, you will get the default machine, which you have set up in settings.xml
, see the Setup Guide. When you use the shipped file, this means you will get a machine that uses C-BIOS. In this chapter we will tell you how to use other machines and how to use extensions.
To use a specific MSX machine that is present on your system (i.e. your openMSX installation), simply use the -machine
command line argument, like this:
Extensions are simply MSX cartridges (extensions to the MSX system) that you can plug into the emulated MSX. In the next paragraph we explain this using an example.
If you have setup an FMPAC hardwareconfig.xml
file in
~/.openMSX/share/extensions/fmpac
e.g. (i.e. for Linux: in your custom extensions directory in this case), you can add -ext
fmpac
to your command line to use an FMPAC. But, as I just said, you
need to have a hardware description in that subdirectory of
share/extensions/
, see Setup Guide. Fortunately,
openMSX comes with a predefined FMPAC extension. You only need to add the
fmpac.rom
in share/extensions/fmpac/roms/
; it's the ROM that is built in the FMPAC. If you look at that share/extensions
directory, you will find more extensions. E.g. using -ext mbstereo
gives you the Moonblaster stereo effect: FMPAC on one channel and MSX Audio on
the other. Try them out, if you like, but again, keep in mind that some
extensions need a ROM image installed in their roms/
directory, which is explained in the Setup Guide.
Often used other command line options will be discussed later in this manual. For a complete list of them, type the following command:
openMSX has a built-in command interface called the console, which allows you to control various aspects of openMSX while it is running. You can access the console by pressing F10 (with default key mapping) when the focus is on the emulator window. This will give you a command line in the openMSX window.
Typing help
gives a list of commands.
If you type help [command]
you will get help
for the specified command.
This manual describes a few important commands;
a full list can be found in the file doc/commands.txt
.
The console can be used to change disk images, plug in joysticks or mice,
change settings at run time and to change key bindings, among others.
One very practical feature of the console command line is that you can use "completion" features. Just try typing half a command and then press the TAB key; openMSX will then try to finish the word you were typing or show the possibilities in case of ambiguities. You can use it also for file names, connectors, pluggables and settings.
You can reset your MSX with the Console command reset
and quit openMSX with the command quit
. Other commands will be discussed later on in this manual.
An interesting console command is set
. You can use it to change the various
settings. E.g., you can use it to set the current renderer. If you issue set with only the setting (like set renderer
), you will get the current value of that setting.
Settings that have only two possible values can also be toggled with the toggle
command (an example is the default key binding of F12 to toggle
fullscreen
, see also below). A complete list of settings should also be in the file
commands.txt
in the doc
directory. Note that using the "tab completion" feature can help you a lot in getting an idea of what settings are possible, as it will only complete possible options. Just try that.
If the MSX goes too fast or too slow, adjust the emulation speed with the
speed
setting, which has the speed percentage as parameter. So, typing set
speed 120
, will let the emulated MSX run at 120% of normal MSX speed. This is useful for debugging purposes (slow down) or when you want to skip certain parts of a demo for example (speed up).
If you got the MSX sped up to maximum (set throttle off
), but
openMSX is still not going fast enough for you, you can increase the
maxframeskip setting: set maxframeskip 10
will mean that openMSX may
skip 10 screens to be displayed, just to get to the requested speed. Note that
you can also force openMSX to skip frames, with the minframeskip setting. This
sets the amount of frames that will be skipped always. Of course frame skipping
makes emulation a lot less accurate.
Some MSX machines like the Panasonic FS-A1GT have built in software, that can be switched on and off via a switch on the machine itself. In openMSX the internal software is switched off by default, but you can switch it on with the following setting: set frontswitch on
.
The console command plug
can be used to plug the so called pluggables (devices) into connectors on the MSX. Examples of connectors are the joystick ports, the printer port, the MIDI in and out connector, the cassette port, etc. Examples of pluggables are joysticks and mice (see below), but also printer loggers and MIDI equipment. The command plug
without any parameters will show a list of connectors and what pluggables are plugged into them. Using plug [connector]
will only show what is plugged into [connector]. You will not be surprised that the command plug [connector] [pluggable]
will plug the [pluggable] into the [connector].
Note that using the "tab completion" feature can help you a lot in getting an idea of what plug commands are possible, as it will only complete possible connectors and their possible pluggables. Also just try this.
With this information, you can run most of the existing MSX software.
Suppose you want to run the ROM file galious.rom
. Then you simply type:
and the emulated MSX will run the game. (Of course,
in this case, the file galious.rom
should be in the current directory or in one
of the UserDirectories you specified in the settings.xml
, see the Setup Guide.)
If things go terribly wrong, openMSX may not have the .rom extension registered as a ROM image (it does have that by default, though, but this is just an example). You can then indicate this by typing:
This lets openMSX know that the file is a ROM cartridge and that openMSX should insert it in the first available free cartridge slot. You can also use -carta
to explicitly specify cartridge slot A.
Or, maybe openMSX didn't have the ROM in the ROM database and failed auto detection of the mapper type. You can specify the mapper to KONAMI4 like this:
Note that in practice you won't need this, since most ROM images are in the database or auto detected if they are not. Also note that the ROM type names may change in future versions of openMSX.
To run a disk image, you can type:
for example. Or, if you haven't registered the .dsk extension for disk images:
You can also change disks at run time of course. Just type
in the console to put the specified disk image in drive A. To eject the disk from drive A, use:
Disk images in XSA format are also supported, use them as regular disk images, but do note that they are read only. The same counts for (g)zipped disk images. Note that in zipped disk images the first file that is packed into the zip file will be used as disk image.
To use a real disk, just specify /dev/fd0
as a disk image. This is of
course a Linux (Unix, actually) specific feature, but for now it is usable. It
may be a bit slow though, with the FDC emulation enabled. It should be just as
slow as a real disk drive, however! Don't forget that you shouldn't have it mounted to be able to use it this way. We recommend to use only write-protected disks! It is possible that you damage the contents of your disk if you don't. Windows users can try real disks by using the DirAsDisk feature. This feature is still experimental and should always used with write protected disks. Only regular disks with normal files will work with it; specify A: as disk image to use it.
openMSX supports WAV files for tape emulation! Just configure your MSX with a cassette port (or use a premade MSX that already has it):
Then type in the console:
And then in MSX Basic, type:
(or another command to load the program on 'tape'.)
Note that in Linux, one should not use the special file /dev/pcm
for tape input. openMSX will try to read the file until the end, which doesn't exist.
You can also use the so-called CAS files. In the console, type:
and
to remove the tape from the virtual cassette player. This only works with a
patched BIOS ROM, though. You can find an example of the patch in
exampleconfigs.xml
. This means you will have to modify the hardware configuration file of the MSX you are using. See the Setup Guide.
Because patching a BIOS is not really something you want, a new feature was recently added to openMSX. You can use CAS files with cassetteplayer as if they were WAV files now! They are automatically converted to WAV files, internally. Note that the loading time is drastically longer this way. On the other hand, you will be able to hear the cassette sounds now also with the CAS files... What is using cassettes with an MSX without those characteristic sounds?
Other cassetteplayer related commands/settings you need to know of are:
cassetteplayer rewind
, to rewind the tapecassetteplayer eject
, to eject the tapeset cassetteplayer_volume
, to set the volume of the cassette player sound (yeah, the screeching tape sounds!)A final note: saving to cassette is not supported in openMSX yet.
The special MSX keys are mapped as follows:
L-CTRL | MSX CTRL key |
R-CTRL | MSX dead (accents) key |
L-ALT | MSX GRAPH key |
R-ALT | MSX CODE key |
L-Windows | MSX iee ('no') key |
R-Windows | MSX hai ('yes') key |
F7 | MSX SELECT key |
F8 | MSX STOP key |
Several emulator functions are available under keys as well:
Pause | Pause emulation |
ALT+F4 | Quit openMSX |
CTRL+Pause (Break) | Quit openMSX (not in Windows) |
PrtScr | Save current screen to a file (screen shot) |
F9 | Toggle full throttle (maximum speed) |
F10 | Toggle console display |
F11 | Toggle audio mute |
F12 | Toggle full screen mode |
The table above lists the default key mapping.
It can be changed in the init.tcl
file by using "bind" commands, see the Setup Guide.
If you have a joystick connected to your PC, use the following command to connect it to the emulated MSX:
To connect a fake joystick (emulated with the arrow keys), you can use this plug
command:
will connect a fake joystick to joystick port A. Button A of the joystick is mapped to the space bar and Button B to Left-Alt (GRAPH), when using the default configuration. For now there can be only one keyjoystick. Note that it only works if it is configured in settings.xml
. This is of course done in the settings file that ships with openMSX. Feel free to change the configuration there.
To connect a mouse, you can also use the plug
command:
will connect a mouse to joystick port A. If you want the joystick emulation feature that some mice (like the Philips SBC-3810 and the Sony MOS-1) have, keep the left mouse key pressed when plugging it in, just as on a real MSX.
A renderer is a part of the emulator that generates the graphical part of the emulation: the MSX 'screen'. At the moment, there are three working renderers:
You can set the renderer in the settings.xml
file. Look for <config
id="renderer">
. You can also specify there whether the emulator should switch
to full screen when started. Of course all of this can also be changed at run time via the console.
Note that openMSX can be compiled without the SDLGL renderer; if that is true for the build you're using, you will not be able to switch to the SDLGL renderer.
The accuracy
setting controls how often the renderer is synchronised with the MSX video processor (VDP).
There are three options:
Higher accuracy creates a higher CPU load. However, it is not as bad as it may seem at first: openMSX synchronises only when it is actually needed, so the amount of synchronisation points depends more on the program you're running than on the accuracy setting.
Most MSX screen modes are only 256×212 pixels big. However, the SDLHi renderer uses a 640×480 screen mode to display the MSX screen. The conversion from the low resolution MSX image to the high resolution PC image is done by a scaler. openMSX contains several scalers:
A small demonstration of the algorithms can be found on the openMSX web site.
PC monitors can have different gamma values than MSX monitors.
To compensate for this, openMSX has a gamma correction feature.
It is controlled by the gamma
setting.
A value of 1.0 disables gamma correction; a lower value makes the image darker; a higher value makes it brighter.
If you want to know what gamma correction really means, read this page about monitor gamma. The gamma correction value you can set in openMSX should be the gamma of your PC screen divided by the gamma of the MSX screen. I measured the gamma of my PC screen (TFT) at 2.0 and the gamma of my MSX monitor at 2.5. That puts the gamma correction at 2.0 / 2.5 = 0.8. So if I enter that value, the openMSX image will have comparable brightness to the MSX image. However, 0.8 is not the value I'm actually using: I prefer a brighter image than my MSX monitor, so I chose to use a gamma correction of 1.1.
openMSX contains a couple of special effects that can be applied to the video output:
deinterlace
setting controls this feature:
it can be on (enabled) or off (disabled); it is enabled by default.
This feature works in the SDLHi
and SDLGL
renderers.
SDLHi
and SDLGL
renderers,
but is disabled when a scaler other than simple
is used.
blur
settings control this:
0 means no blur (completely sharp), 50 means some blur (like a monitor),
100 means maximum blur (like a TV).
All other values between 0 and 100 are also possible of course.
This feature works only in the SDLGL
renderer.
glow
setting controls the amount of after glow:
0 means no after glow, 100 means maximum after glow.
This feature works only in the SDLGL
renderer.
There is a master_volume
setting, which controls the overall output volume of openMSX (it applies to all sound devices). Volume 0 means no sound, volume 100 is maximum.
There is also a mute
setting, to disable all sound from openMSX at once. It can be on (muted) or off (sound is audible). By default, mute is bound to the F11 key.
Each sound device in the MSX you are emulating also has its own volume setting. Volume 0 means no sound, volume 100 is maximum. For example: set "MSX Music_volume" 50
.
All mono sound devices have an additional mode setting. You can use it to select whether this device should be audible on the left channel ("left"), the right channel ("right") or both channels ("mono"). Example: set PSG_mode left
.
openMSX supports the MSX-MIDI interface of the MSXturboR GT.
To use this feature, start openMSX with the machine
Panasonic_FS-A1GT
and plug in a MIDI device on the console.
For example:
This logs all MIDI commands to a file. Because there is no timing information logged, this is not very useful yet.
It's more interesting to connect MSX-MIDI to an actual PC MIDI device,
such as a MIDI out port or the internal synthesizer of your sound card.
On Linux, you can use the midi-out-logger
and set a MIDI
device node, for example /dev/midi
, as its output file. This is done by default. To play with this setting, use set midi-out-logfilename
.
On Windows, real MIDI devices are separate pluggables.
This chapter describes how the debug device, built in openMSX, can be used to the advantage of an MSX programmer. This device is an artificial MSX device that is connected to an MSX I/O port. It can be used to send debug messages to the host operating system.
The easiest way to enable the debugdevice is to start openMSX with the
debugdevice extension. To do this, simply add -ext debugdevice
to the
openMSX command line.
Another way to make the device work is to add it to the hardwareconfig.xml
from
the machine that is used. If, for example, the device has to be used on the
Philips NMS 8250, the following lines can be added to the hardwareconfig.xml
file in the share/machines/Philips_NMS_8250
directory.
<device id="DebugDevice"> <type>DebugDevice</type> <parameter name="filename">~/debugout.txt</parameter> </device>
The third line is optional and can specify any filename you
like, including stdout
.
Controlling the device is done from within an MSX program. For this purpose, the output ports 0x2E and 0x2F are used. The first port is the Mode Set Register. Bytes sent to this port have the following meaning.
bit(s) | meaning |
---|---|
7 | unused |
6 | line feed mode (0 = line feed at mode change, 1 no line feed) |
4-5 | output mode (0 = OFF, 1 = single byte, 2 = multi byte) |
0-3 | parameters for mode 1 (see below) |
0-1 | parameters for mode 2 (see below) |
When using mode 1, single byte mode, these are the parameters:
bit(s) | meaning |
---|---|
0 | hexadecimal mode on/off |
1 | binary mode on/off |
2 | decimal mode on/off |
3 | ascii mode on/off |
So, every parameter bit turns an output format on or off and more than one output format can be specified at the same time.
The parameters for mode 2 (multi byte mode) are as follows:
bit(s) | meaning |
---|---|
0-1 | mode (0 = hex, 1 = binary, 2 = decimal, 3 = ascii mode) |
In mode 1, any write to port 0x2F will result in output. This way, the
programmer can see if a specific address is reached by adding a single OUT
to
the code. The output depends on the parameters set with the mode register. Each
bit represents a specific format, and by turning the bits on and off, the
programmer can decide which formats should be used.
Here is an example:
LD A,65 OUT ($2f),A
This will give the following output:
41h 01000001b 065 'A' EmuTime:087a09c75a (when all bits are on, mode register = 0x1F)
or
41h 065 'A' EmuTime: 087a09c75a (when the binary bit is off, mode register = 0x1D)
or
41h EmuTime: 087a09c75a (when only the hexbit is on, mode register = 0x11)
and so on.
The EmuTime part is a special number that keeps track of the openMSX emulation. The larger this number is, the later the event took place. This is a great way to find out in what order things are called.
If the character to print is a special character, like carriage return, linefeed, beep or tab, the character between the ' ' will be a dot (.) and the normal character is 'displayed' at the very and of the line, so it won't mess up the layout of the whole line.
In mode 2, writing to 0x2F does not output any text. All bytes written to this register are stored in a buffer and only when the mode register is set again the output is shown. Unlike mode 1, the data in this mode is always shown in one mode only. It's either in hex mode, binary mode, decimal mode or ascii mode, but never a combination. Also the EmuTime bit is left out.
Here is an example:
LD A,xx OUT ($2e),A LD A,$41 OUT ($2f),A OUT ($2f),A OUT ($2f),A LD A,xx OUT ($2e),A
Only at this last instruction the output appears.
If we substitute $20
for xx
, we get:
41h 41h 41h
and if we substitute $22
for xx
, we get:
065 065 065
The extra zero is added to keep alignment. Finally, if we want ASCII
output, all we need to do is change xx
for $23
:
AAA
In this special case, the space in between the data is left out. Any special character like carriage return, linefeed, beep or tab will be printed as can be expected.
The openMSX console can be used to control the output of the device. This is
done by the setting debugoutput
. You can set it to any file name or to the special settings stdout
and stderr
, which lets the output go to these special streams.
Since openMSX is still in heavy development, feedback and bug reports are very welcome!
If you encounter problems, you have several options:
openmsx-user
mailing list.
More info on the
openMSX mailing lists,
including an archive of old messages, can be found at SourceForge.
#openMSX
on irc.freenode.net
and ask your question there.
openmsx-devel
mailing list.
More info on the
openMSX mailing lists,
including an archive of old messages, can be found at SourceForge.
In any case, try to give as much information as possible when you describe your bug or request.
$Id: user.html,v 1.28 2004/05/22 09:06:07 manuelbi Exp $