Difference between revisions of "MAME Internals"
m |
|||
| Line 47: | Line 47: | ||
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. | 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. | 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).<ref>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.</ref> | ||
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. | 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. | ||
| Line 59: | Line 59: | ||
./mame64 ti99_4a -cart burgertm | ./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''). | 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. <ref>When the core finds out that there are multiple devices that support the same image type, the names are suffixed with a number ("cart1", "cart2", "flop1", "flop2").</ref> 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. | First, the parent class does some internal handling. | ||
| Line 66: | Line 66: | ||
If the argument behind ''cart'' contains a period, the name is considered a file name. | If the argument behind ''cart'' contains a period, the name is considered a file name. | ||
'''To be continued''' | |||
==== Program name argument ==== | ==== Program name argument ==== | ||
If the argument behind ''cart'' does not contain a period, the name is considered a software name from a software list. | If the argument behind ''cart'' does not contain a period, the name is considered a software name from a software list. | ||
load_internal -> load_software_part -> find_software_item -> virtual call_softlist_load -> load_software_part_region | |||
-> virtual call_load | |||
'''To be continued''' | '''To be continued''' | ||
== Notes == | |||
<references /> | |||
Revision as of 11:47, 31 May 2016
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. [1]
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).[2]
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. [3] 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.
To be continued
Program name argument
If the argument behind cart does not contain a period, the name is considered a software name from a software list.
load_internal -> load_software_part -> find_software_item -> virtual call_softlist_load -> load_software_part_region -> virtual call_load
To be continued
Notes
- ↑ 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".
- ↑ 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.
- ↑ When the core finds out that there are multiple devices that support the same image type, the names are suffixed with a number ("cart1", "cart2", "flop1", "flop2").