MAME Device Basics: Difference between revisions

From MAMEDEV Wiki
Line 11: Line 11:
Every device in the project is built up out of two classes: a device-specific ''configuration class'' (derived from the '''device_config''' class) and a device-specific ''runtime class'' (derived from the '''device_t''' class).  
Every device in the project is built up out of two classes: a device-specific ''configuration class'' (derived from the '''device_config''' class) and a device-specific ''runtime class'' (derived from the '''device_t''' class).  


The configuration class is responsible for encapsulating the device's configuration. The base '''device_config''' class automatically supports several core configuration properties, such as a short string '''tag''' to identify the device instance, and a '''clock''' value which represents the input clock to the device. All device-specific configuration classes must be derived from the '''device_config''' class at their root.
The configuration class is responsible for encapsulating the device's configuration. The base '''device_config''' class automatically supports several core configuration properties, such as a short string ''tag'' to identify the device instance, a ''clock'' value which represents the input clock to the device, and an ''owner'' who serves as the device's parent. All device-specific configuration classes must be derived from the '''device_config''' class at their root.


Of course, most devices require more configuration than this, and so there are mechanisms for the device-specific configuration class to accept further configuration information, both inline in the MACHINE_CONFIG description, as well as externally in a static structure. More details on how this works come later in this article.
Of course, most devices require more configuration than this, and so there are mechanisms for the device-specific configuration class to accept further configuration information, both inline in the MACHINE_CONFIG description, as well as externally in a static structure. This additional configuration data is stored in the device-specific class. More details on how this works come later in this article.


In addition to holding the configuration of a device, the device-specific configuration class also serves as a "factory" class that provides a mechanism for the MAME core to instantiate both new configuration objects, via a static method, and new runtime objects, via a required virtual method. (It is worth noting that the pointer to the static method that constructs configuration objects also serves as the device "type", which is a unique single entry point into the device.)
In addition to holding the configuration of a device, the device-specific configuration class also serves as a "factory" class that provides a mechanism for the MAME core to instantiate both new configuration objects, via a static method, and new runtime objects, via a required virtual method. (It is worth noting that the pointer to the static method that constructs configuration objects also serves as the device "type", which is a unique single entry point into the device.)


The runtime class, as its name implies, holds the runtime state of a device. (More later)
The runtime class, as its name implies, holds the runtime state of a device. The base '''device_t''' class provides a number of basic device concepts, including device initialization, reset, hooks into the save state system, clock scaling. It also holds a reference back to the corresponding '''device_config''' that begat the device.
 
The device-specific runtime class, which is required to derive from '''device_t''', then contains all the runtime state of the device, along with methods to operate upon the live device. It can also override several internal methods of its parent class to gain access to hooks that are called during specific events in the machine's lifecycle.


=Lifecycle of a Device=
=Lifecycle of a Device=

Revision as of 19:13, 18 May 2010

Overview

In MAME, a device is a mechanism for encapsulating behavior. While it is common to associate a device (in the MAME sense) with a physical device (in the real world), there does not necessarily need to be a 1:1 correspondance between the two.

Devices are important because they provide clean hooks into the MAME system. They are notified when key things in the system change, they encode their own configuration information, keep their own state, and can be instantiated multiple times within a given machine. They are easily located via a simple string tag, and are first-class citizens in memory maps, so they are easily read from and written to.

As of MAME 0.139, devices are implemented using a collection of C++ classes. In order to provide the flexibility necessary to describe the sorts of devices in MAME, the device model relies heavily on the multiple inheritance feature of C++ to extend devices with one or more device interfaces.

Basic Concepts

Every device in the project is built up out of two classes: a device-specific configuration class (derived from the device_config class) and a device-specific runtime class (derived from the device_t class).

The configuration class is responsible for encapsulating the device's configuration. The base device_config class automatically supports several core configuration properties, such as a short string tag to identify the device instance, a clock value which represents the input clock to the device, and an owner who serves as the device's parent. All device-specific configuration classes must be derived from the device_config class at their root.

Of course, most devices require more configuration than this, and so there are mechanisms for the device-specific configuration class to accept further configuration information, both inline in the MACHINE_CONFIG description, as well as externally in a static structure. This additional configuration data is stored in the device-specific class. More details on how this works come later in this article.

In addition to holding the configuration of a device, the device-specific configuration class also serves as a "factory" class that provides a mechanism for the MAME core to instantiate both new configuration objects, via a static method, and new runtime objects, via a required virtual method. (It is worth noting that the pointer to the static method that constructs configuration objects also serves as the device "type", which is a unique single entry point into the device.)

The runtime class, as its name implies, holds the runtime state of a device. The base device_t class provides a number of basic device concepts, including device initialization, reset, hooks into the save state system, clock scaling. It also holds a reference back to the corresponding device_config that begat the device.

The device-specific runtime class, which is required to derive from device_t, then contains all the runtime state of the device, along with methods to operate upon the live device. It can also override several internal methods of its parent class to gain access to hooks that are called during specific events in the machine's lifecycle.

Lifecycle of a Device

  • Configuration
  • Runtime

Configuring Devices

  • Static configs
  • Inline configs

Interfaces in Detail

Best Practices