Emulator:MESS

About

MESS stands for Multi Emulator Super System, the goal of the project was simlar to MAME where MAME only emulated arcade systems MESS took the MAME source code and extended it to include support for consoles, computer systems and calculators. That is not to say the scope was limited to only these 3 classes of device, The MESS project was happy to emulate any non-arcade system, leaving the arcade work up to the MAME project.

Being based on the same source code oas the MAME project means the project shared similar goals, that is accuracy and documentation over playability with the byproduct of accurate emulation being the ability to load ROMs.

As of MAME 0.167 the MESS source code was integrated into the main MAME source tree and the projects unified. This made sense because of the lot of the contributors to MESS were also MAME developers and the projects shared a common codebase.

Note: some examples in this document may refer to the MAME project now post the merge. MAME and MESS should now be considered interchangeable terms.

The default MAME compilation as of 0.167 will build a unified MAME/MESS project (commonly referred to as UME) although as of MAME 0.217 it is still possible to build MESS alone by passing a SUBPROJECT variable during compilation.

Configuration

Platform	Version	Device	Exec	Type	commandline_format
Linux	000000	N/A	README	D	N.A

Usage

Some general usage notes are listed here, due to the scope of the MESS project these should get you most of the way when using any system that isn't explicitly covered in its own article.

Fundamentals

Let start with some key fundamentals you will benefit from understanding when approaching mess for the first time.

Terminology

Term	Description
Full Emulation	This term does not relate to the status of the emulation of the device nor machine but is instead a runtime state for MESS and as it happens the default state for MESS when you launch a machine/device. When in Full Emulation the MESS UI is no longer accessible using the standard keys and if the machine you are running supports a keyboard all applicable keys (TAB) will be assigned to the machine NOT your host when the emulator has focus.
Partial Emulation	Just like Full Emulation this is a runtime state for MESS, when in this mode the emulator returns control of the Keyboard to the host even if you are using a machine with a full keyboard that has a TAB key assigned as part of the input configuration, the TAB key operation will interact with you host not the emulator internally. In this case pressing tab will open the MESS UI and allow you manage attached devices, disks, tapes, inputs etc.
Driver	A driver is the main software defined machine configurations, states etc, it may define multiple systems and/or machines
System	A system is equivalent in all respects to a machine, although multiple machine versions may be grouped under a system.
Machine	A machine is an emulated device (e.g. an Atari 2600 or an MSX). Machines are defined in drivers by stipulating their specific hardware. They may as be as complicated as they need to or just a clone/branding change (e.g. CreatiVision as Dick Smith Electronics Wizzard). You start a machine, that machine may be configured with slotted devices and software. Some machines require software or slotted devices be filled (e.g. Amstrad CPC464) before they will do anything, MESS should warn you of this as you start the machine.
Interface	An Interface just like on a real device is somewhere you connect external items, a cartridge interface is a good example of this. This is different from a slot in so far it is externally facing, interfaces depending on how they are defined may still show up in the Slot Devices UI menu.
Slot	A slot just like on a real device is somewhere you connect devices, taking a relatable example on the ct486 device you can add ISA cards to a slot. Internal slots are available for expanding the machine. This is different from an interface where an interface is externally facing.
Media	Media is the supported forms for software that the machine can handle, this is different for every machine, and example of this would be the Nintendo N64 machine with a game cartridge. The media that is supported will be assigned to a type and accept various types of file. So looking at the N64 again, the cartridge media type will support files of .v64, .z64, .rom, .n64, .bin.
Software List	A software list is a predefined XML for a system that is able to recognise known good working version of a ROM, Disk Images, CD-ROM etc. These are specific to the machine to which they built for and are built to define compatible software for specific interfaces within that machine definition.

Information

Obtaining information about a machine is fairly simple once you understand the above. There are 3 major command line options to inquire on a system

Term	Description
-listslots	This will show you the available slots for the machine, as per the terminology table these are generally internal slots of the machine (e.g. ISA slots). The output here will also include the items you can configure for the particular slot. The output can look verbose although there are a lot of duplications; if your machine has 3 ISA slots for example all of the available ISA slot items will be output once for each slot.
-listdevices	Displays all the applicable devices for the machine including vga, cpu, ram, speaker devices etc. This command is useful when configuring a machine from the command line. It can be used to understand how to map an device so the slots are made available
-listmedia	Displays all compatible media, the device it is compatible with and what filetypes the machine will accept.

You can call each of the above options without a machine name and MESS will output information for all know systems

Example

Finding the media supported for the ct486 driver

$./mame64 ct486 -listmedia

SYSTEM           MEDIA NAME       (brief)    IMAGE FILE EXTENSIONS SUPPORTED
---------------- --------------------------- -------------------------------
ct486            floppydisk1      (flop1)    .dsk  .ima  .img  .ufi  .360  .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  
                 floppydisk2      (flop2)    .dsk  .ima  .img  .ufi  .360  .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  
                 harddisk         (hard)     .chd  .hd   .hdv  .2mg  .hdi  
                 printout         (prin)     .prn  

Emulation Modes

There are two runtime emulation modes for MESS as stated in the terminologies section above these are Full and Partial emulation modes. The main differences between the modes from a users perspective is already covered in the terminology section of this document so we wont repeat it here. We will hover cover some items likes switching modes, risks etc.

Switching emulation modes is very simple, by default you toggle modes with the Scroll Lock key on your keyboard, you will be notified that the mode has switched by a popup window on the display.

Make a note to remember what mode you are in because this popup dialog will soon disappear and there is no onscreen indication of the mode you are in thereafter.

WARNING if you are in Partial Emulation mode then the Escape (ESC) key will be mapped to exit the emulator as per the MAME default and will not operate as Escape on the internal emulated system. It is extremely easy to lose work this way.

Specifying a System

Most systems will have a (brief) means of configuring devices. In most cases only the fixed hardware is scoped into the machine definition after that there is flexibility around what you can do. Want to run 64m of ram on a 486DX/25, sure, don't pretend any of us could afford that back in the day. Want to run additional serial ports on the same machine, add an ISA card (see -listslots) with the additional ports.

The most basic means of specifying a system is to run it by the machine name only, if it has any specific requirements like a -cart argument (e.g cpc464p) before it can boot it will notify you. Alternatively this information can be found by reading the source code but that is outside the scope of this document.

Simple Systems

We'll use the Amstrad CPC464+ machine for this example.

First lets list out the available media for this machine

$ ./mame64 cpc464p -listmedia
SYSTEM           MEDIA NAME       (brief)    IMAGE FILE EXTENSIONS SUPPORTED
---------------- --------------------------- -------------------------------
cpc464p          printout         (prin)     .prn  
                 snapshot         (dump)     .sna  
                 cassette         (cass)     .wav  .cdt  
                 floppydisk1      (flop1)    .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  .dsk  
                 floppydisk2      (flop2)    .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  .dsk  
                 cartridge        (cart)     .bin  .cpr  

When you load the machine without a cartridge you will see a warning that the system requires at least the cart argument. You can get this machine running very simply by getting a copy of the Amstrad OS cartridge and load it into the cart slot.

$ ./mame64 cpc464p -cart <amstrados.bin>

The machine wont do much after this except display the information from the cart on the screen

Next lets see what else it can do.

Looking at the media list we generated earlier we saw it would also run with 2 floppy drives, lets get some software to load into the first slot.

You will now need a copy of

• Amstrad Basic 1.x (Locomotive Basic)
• Software to load (see external links)

$ ./mame64 cpc464p -cart <amstradbasic.bin> -flop1 <software.dsk>

This will start the machine with Amstrad Basic in the cart slot (booted) and your software already inserted into the first floppy drive.

For more specific commands and/org references for specific systems you will need to visit their dedicated pages on the wiki. Some machines will start the software automatically others like the cpc464 require you to load the software from the disk into the system ram then run it.

Once the machine is running you can switch Emulation Modes as necessary to configure the running machine, remap control, control tape drives, swap disks etc.

Custom Systems

Lets move back to using the ct486 machine, running a -listmedia on this machine shows it will run a single HDD from the command line but if we check the bios on the machine once it starts to boot we can see it will in theory support a second HDD.

$ ./mame64 ct486 -listmedia
SYSTEM           MEDIA NAME       (brief)    IMAGE FILE EXTENSIONS SUPPORTED
---------------- --------------------------- -------------------------------
ct486            floppydisk1      (flop1)    .dsk  .ima  .img  .ufi  .360  .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  
                 floppydisk2      (flop2)    .dsk  .ima  .img  .ufi  .360  .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  
                 harddisk         (hard)     .chd  .hd   .hdv  .2mg  .hdi  
                 printout         (prin)     .prn  

We can start this machine with a single hard disk image using the following command line.

A hard disk image will be a pre-existing CHD file, you will need to have already obtained one or created your own.

$ ./mame64 ct486 -hard <harddisk.chd>

The machine will be started with the hard disk image attached, you can confirm this by changing to Partial Emulation mode and browsing the File Manager in the menu. Providing the hard disk bootable and configured correctly in the bios the machine will boot form the image.

You can enter the bios by pressing the DEL key on your keyboard when prompted while the machine is POSTing. When in the bios under STANDARD CMOS SETUP you will notice there support for a second hdd as drive D: we will now look at attaching a second CHD an alternate slot.

For this we will need to take a look at the devices and/or slots the machine supports as opposed to just using the listmedia view which showed us what media works with what interface. We will use -listslots and truncate the output for use in this document.

$ ./mame64 ct486 -listslots

SYSTEM           SLOT NAME        SLOT OPTIONS     SLOT DEVICE NAME
---------------- ---------------- ---------------- ----------------------------
ct486            board3:ide:ide:0 cdrom            ATAPI CD-ROM
                                  hdd              IDE Hard Disk
                                  px320a           PleXCombo PX-320A CD-RW/DVD-ROM Drive

                 board3:ide:ide:1 cdrom            ATAPI CD-ROM
                                  hdd              IDE Hard Disk
                                  px320a           PleXCombo PX-320A CD-RW/DVD-ROM Drive

So we do have 2 ide slots which can support a number of options one of those being hdd. It is reasonable to assume in most cases the second slot would be taken by a cdrom which in turn would allow you to just call -cdrom with an iso file defined on the command line when launching the machine but thats boring so lets add another hdd instead which is not so straight forward.

Firstly lets try calling -hard2 without enabling the slot

$ ./mame64 ct486 -hard <harddisk.chd> -hard2 <harddisk2.chd>

Error: unknown option: -hard2 We need to enable the slot before we can pass a chd to it as -hard2 so lets do that this time. Remembering the output from -listslots we can take that output and translate that into a command line argument.

$ ./mame64 ct486 -hard <harddisk.chd> -board3:ide:ide:1 hdd -hard2 <harddisk2.chd>

On first boot with the new HDD you will need to configure it in the BIOS for the machine to understand its CHS layout, but again this is outside the scope of this document.

Taking this approach you may be able to see that it is possible to define some complex machine configurations from the command line.

Something like this machine I use, it has been configured with

• 2xHDD
• ISA VGA
• Sound Cards,
• 2x ISA Serial port cards
• 1x ISA IDE controller (CD-Rom drive)

Note: Serial Ports have their own section

./mame64 ct486 \
  -board3:ide:ide:0 hdd \
  -hard1 "${HARD1}" \
  -board3:ide:ide:1 hdd \
  -hard2 "${HARD2}" \
  -ramsize $RAMSIZE \
  -isa1 ${VGA} \
  -isa2 ${SND} \
  -board2:comat:serport0 null_modem \
  -bitb socket.${MODEM}:25231 \
  -board2:comat:serport1 null_modem \
  -bitb1 socket.${MODEM}:25232 \
  -board2:comat:serport1 null_modem \
  -bitb2 socket.${MODEM}:25233 \
  -isa3 comat \
  -isa3:comat:serport0 null_modem \
  -bitb3 socket.${MODEM}:25234 \
  -isa3:comat:serport1 null_modem \
  -bitb4 socket.${MODEM}:25235 \
  -isa4 ide \
  -isa4:ide:ide:0 cdrom \
  -cdrom "${CDROM}"

Serial Ports

Mame has a bitbanger than can be used in conjuction with a serial port to allow for bidirection traffic over the serial port. This opens up some interesting opportunities, In one case I had 2 instances of MAME on a single machine playing a DOOM Deathmatch over a null_modem serial connection.

There are multiple types you can assign to a serial port the most useful of which is probably the null_modem type.

To assign a null_modem type to a serial port on the ct486 machine start up MAME with the following argument

-board2:comat:serport0 null_modem

This will set a null_modem to be connected to the serial port slot which can be confirmed through either the Machine Configuration UI page and/or the Slot Devices screen. It wont actually do much with this as there is no means for getting data in and ou with a bitbanger device attached to it. The bitbanger device allows communication via a socket over tcp to a MAME defined serial port.

To attach a bitbanger device to a slot modify the previous argument like so

-board2:comat:serport0 null_modem -bitb socket.127.0.0.1:25231

The serial port must be defined first or the bitb object has nothing to attach too. In the above example 127.0.0.1 is the listening host and 25231 is the listening port for the device, you may customise these as you wish.

From this you should be able to communicate with your running MAME emulate machine

$ telnet 127.0.0.1 25231
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.

External Links

Project Homepage