MAME Internals - Revision history

Stefan Haubenthal: Category

2016-06-03T13:44:42Z

Mizapf at 22:15, 2 June 2016

2016-06-02T22:15:50Z

@@ Line 3: / Line 3: @@
 * by the ROM_LOAD declaration
 * by a software list
 == ROM_LOAD ==
@@ Line 16: / Line 58: @@
 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.
 === Example definition ===

Mizapf at 21:27, 31 May 2016

2016-05-31T21:27:16Z

← Older revision		Revision as of 21:27, 31 May 2016
Line 78:		Line 78:
	* device_image_interface::load_software_part:		* device_image_interface::load_software_part:
	* device_image_interface::find_software_item: Searches the matching <software> element within the specified software list, and returns the part from it that was either specified explicitly, or that appears first in the <software> element.		* device_image_interface::find_software_item: Searches the matching <software> element within the specified software list, and returns the part from it that was either specified explicitly, or that appears first in the <software> element.
	* virtual device_image_interface::call_softlist_load: Implemented in ''gromport.cpp''. Calls ~~the ''ROM loader''~~, passing a pointer to the [[#rom_entry \| rom_entry]] list (starting with a region declaration)		* virtual device_image_interface::call_softlist_load: Implemented in ''gromport.cpp''. Calls rom_load_manager::load_software_part_region, passing a pointer to the [[#rom_entry \| rom_entry]] list, starting with a region declaration
			* rom_load_manager::load_software_part_region: Determine the ''locationtag'' (list%name(%parent)). Allocate memory, then process all rom entries starting from the given position.
			* rom_load_manager::process_rom_entries: The <rom> entries in the software list are processed as ROM_LOAD entries (ISFILE).
	* rom_load_manager::load_software_part_region:		* rom_load_manager::open_rom_file: Rom loader
			* virtual call_load


	-> virtual call_load

	'''To be continued'''		'''To be continued'''
Line 101:		Line 98:
	All rom_entry instances are collected in a list. ''rom_next_region'' proceeds to the next rom_entry in the list that declares a region.		All rom_entry instances are collected in a list. ''rom_next_region'' proceeds to the next rom_entry in the list that declares a region.

			=== ROM loader ===

			The ROM loader is implemented in rom_load_manager::open_rom_file and rom_load_manager::read_rom_data.

			rom_fread -> emu_file::read

			open -> open_next -> attempt_zipped

	== Notes ==		== Notes ==
	<references />		<references />

Mizapf at 20:58, 31 May 2016

2016-05-31T20:58:52Z

@@ Line 71: / Line 71: @@
 ==== 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. Next, within ''load_software_part'',
 -> virtual call_load
 '''To be continued'''
 == Notes ==
 <references />

Mizapf at 11:47, 31 May 2016

2016-05-31T11:47:37Z

← Older revision		Revision as of 11:47, 31 May 2016
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 />

Mizapf at 11:02, 31 May 2016

2016-05-31T11:02:42Z

← Older revision		Revision as of 11:02, 31 May 2016
Line 41:		Line 41:
	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.		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 ''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''. <ref name="otherif">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".</ref>

	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 '''<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.

Mizapf: /* Example definition */

2016-05-31T10:12:48Z

Example definition

← Older revision		Revision as of 10:12, 31 May 2016
Line 39:		Line 39:
	</software>		</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.		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 '''<feature>''' element is a simple name/value information element, but it is nonetheless very important: it determines the type of the cartridge.		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.		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.

Mizapf at 23:14, 30 May 2016

2016-05-30T23:14:31Z

@@ Line 20: / Line 20: @@
 === Example definition ===
-Consider the following entry from the TI-99 softlist in MAME.
+For illustration purposes we have a look at the following entry from the TI-99 softlist in MAME.
   <software name="burgertm">
@@ Line 52: / Line 52: @@
 === Loading ===
 '''To be continued'''

Mizapf at 21:10, 30 May 2016

2016-05-30T21:10:10Z

@@ Line 1: / Line 1: @@
-== ROM Loader ==
+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_LOAD ==
-=== Software list ===
+== 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).
+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'''.

Mizapf: Created page with "== ROM Loader == 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 declarati..."

2016-05-30T20:22:26Z

Created page with "== ROM Loader == 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 declarati..."

New page

== ROM Loader ==

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 ===

=== 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'''.

← Older revision		Revision as of 13:44, 3 June 2016
Line 149:		Line 149:
	== Notes ==		== Notes ==
	<references />		<references />

			[[Category:MESS\|Internals]]