MAME Internals

The ROM loader is an internal component of the MAME core. It is not directly called by the driver but in one of these occasions:

• by the ROM_LOAD declaration
• by a software list

ROM_LOAD

ROM dumps can be specified by ROM_LOAD declaration.

To be continued

Software list

Software lists are used for declaring the software dumps associated to some program or game. A software list is a XML document which contains one or more child nodes named <software>. Every <software> nodes describes a single program (or game).

A program, as found on systems like the TI-99/4A, was typically available as a cartridge, or as one or more files on a diskette or cassette. Within a cartridge there are one or more permanent memory chips containing the program code.

In order to run cartridge-based programs on an emulation, we need the contents of the memory chips inside the cartridge. The contents are saved as files on the host file system and are called (memory) dumps.

Example definition

For illustration purposes we have a look at the following entry from the TI-99 softlist in MAME.

<software name="burgertm">
   <description>Burgertime</description>
   <year>1983</year>
   <publisher>Data East USA</publisher>
   <info name="serial" value="PHM 3233"/>
   <part name="cart" interface="ti99_cart">
      <feature name="pcb" value="standard"/>
      <dataarea name="grom" size="0x4000">
          <rom name="phm3233g3.bin" size="0x1800" crc="4d55a729" sha1="523f57cd388b2a1d117737d40422b1ad7dd3dabc" offset="0x0000" />
          <rom name="phm3233g4.bin" size="0x1800" crc="d3637b23" sha1="d6bef21943169a154264633bacf62408ef0b479d" offset="0x2000" />
      </dataarea>
      <dataarea name="rom" size="0x2000">
          <rom name="phm3233c.bin" size="0x2000" crc="ed7ef022" sha1="8959a44c9ca8aaf15da5ba49d4d26656e8175554" offset="0x0000" />
      </dataarea>
   </part>
</software>

This <software> element contains, among further information, one child element <part>. Parts can be understood as different editions of a game or program, like "Part 1: First Encounter", "Part 2: The Hunt Continues", "Part 3: The Endgame". Each part would then declare its specific collection of dumps. We do not have such use cases in the TI emulation, so there is a single <part> element.

The name of the part is "cart", which is not really important; it could be given any name, since we do not distinguish parts here. The match to the value of the interface attribute "ti99_cart" is the value of ti99_cartridge_device::image_interface. This means we could set up another way to process cartridges by providing another device_image_interface. Indeed, we could also specify that a game be loaded from a disk drive, in which case the associated interface would be, for instance, "ti99_disk".

The <feature> element is a simple name/value information element, but it is nonetheless very important: In our case it determines the type of the cartridge.

The two <dataarea> elements are particularly interesting here. Each <dataarea> element contains a name attribute which associates the contained dumps to a region, and it specifies the size of this region. We have two regions: grom and rom, which are used to hold the contents of the GROMs and of the EPROM in the cartridge.

In the element for the grom region we have two <rom> elements, one for GROM 3 (at offset 0000), and one for GROM 4 (at offset 2000). Note that the grom region in a cartridge is associated to the GROMs with IDs 3 to 7. The GROMs 0 to 2 are contained in the console and have their own memory region.

The element for the rom region contains a single <rom> element for the dump of the EPROM. This region is accessed at address 6000, which is not obvious here, but which is determined by the cartridge type.

So we can see three files: phm3233g3.bin, phm3233g4.bin, phm3233c.bin, each containing a dump that must be loaded. For the MAME core it does not matter whether the contents are dumped from a GROM or from a ROM - the only job for the core is to load these files and to put them in the given locations in the respective regions. This is where the ROM loader is invoked.

Loading

Suppose we launch the emulation with the cartridge plugged in (see later discussion for cartridge swap):

 ./mame64 ti99_4a -cart burgertm

The action starts inside image.cpp where the loop over all instances of image devices causes a call to device_image_interface::load. The image type of ti99_cartridge_device is IO_CARTSLOT, the name registered for it is "cartridge", matching the short name "cart" in the command line. Accordingly, the instance is ti99_cartridge_device, and burgertm will be passed as argument (all in image.cpp).

First, the parent class does some internal handling.

File argument

If the argument behind cart contains a period, the name is considered a file name.

Program name argument

If the argument behind cart does not contain a period, the name is considered a software name from a software list.

To be continued