mame/hash/softwarelist.dtd
Fabio Priuli f25b3a9b88 softlist.c: split the <info> field (added some time ago to handle compatibility requirements) into <info> and <sharedfeat>.
the former stays tied to the whole software entry, the latter gets inherited by each part. 

out of whatsnew 1: Arbee, this change finalizes the xml format once for all. feel free to create an apple II or ||gs list, if you are interested

out of whatsnew 2: 
A bunch of comments about this change: with the latest code, each software entry can store three different kind of 'extrainfo' strings. They are thought to be used in specific cases, so let me briefly explain the big picture behind them.

1. <feature> fields: these are well established in current lists. they belong to a <part> element (i.e. a specific cart or cd disc or floppy disk) and they can be used to store hardware details that belongs to that specific <part>. typically, we have used these to describe the pcb_type of a cart (e.g. the board type in NES carts or in AES carts, to remove the need of specific mappers), so that at loading time they can be checked and the emulation can be setup accordingly. However, some lists (e.g. snes.xml and, in a few months, nes.xml as well) use these more creatively, to e.g. document the exact chip locations on the pcb

examples
<feature name="pcb_type" value="MMC3C"/>
<feature name="u3" value="SRAM-64M"/>

----------
2. <sharedfeat> fields: these are listed in the main <software> entry, but get stored together with the <feature> of each part of this software. E.g. if your software entry consists of 9 floppies, these shared features will be inherited by *all* the disks. The typical usage for this is to list the compatibility requirements of the software entry, e.g. a PAL system, or the presence of an expansion card, or the presence of additional RAM. These compatibility settings have to be manually parsed in the loading code by the driver author, but it makes more sense to define them only once for each software entry than to copy and paste it for each <part> (and believe me, it makes a difference both in terms of avoiding redundant lines and in terms of time necessary to create the xml list itself, when you deal with hundreds of multidisk entries like in the forthcoming pc8801 floppy list). consider this as a shortcut for 1. when you have multidisk software.

examples
<sharedfeat name="compatibility" value="EUR-JPN"/>  (the value can be freely chosen by the driver author as long as he also add the correct values in the loading routine ;) )
<sharedfeat name="addon" value="DVC"/> (this can be of use in cdi titles which won't work without the DigitalVideoCard expansion)

----------
3. <info> fields: these belongs directly to the main <software> entry, like the <sharedfeat>, but they do get stored in the main software entry, not with the <part>. They should be used to store additional info which might be of use for frontends, but that are not strictly necessary for emulation (if you have to describe some fundamental hardware characteristic that has to be checked during emulation, then you should use <sharedfeat> not <info>). Possible examples include the name of the development team, or the serial number of the cart, etc but it's up to the list creator to decide what to use this for and if to use it at all

examples
<info name="developer" value="Treasure"/>
<info name="serial" value="NUS-NSMJ-JPN"/>

As already said, imho the format can now be considered finalized. I cannot really think of anything else that we might want to include in the format, without getting redundant. 

p.s. In fact, some small change is still required in the core to fully support the new fields (e.g. at the moment <info> are not loaded by the core), but the xml format won't be touched.
2011-03-27 00:11:42 +00:00

54 lines
2.4 KiB
DTD

<!ELEMENT softwarelist (software+)>
<!ATTLIST softwarelist name CDATA #REQUIRED>
<!ATTLIST softwarelist description CDATA #IMPLIED>
<!ELEMENT software (description, year?, publisher, info*, sharedfeat*, part*)>
<!ATTLIST software name CDATA #REQUIRED>
<!ATTLIST software cloneof CDATA #IMPLIED>
<!ATTLIST software supported (yes|partial|no) "yes">
<!ELEMENT description (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT publisher (#PCDATA)>
<!ELEMENT info EMPTY>
<!ATTLIST info name CDATA #REQUIRED>
<!ATTLIST info value CDATA #IMPLIED>
<!ELEMENT sharedfeat EMPTY>
<!ATTLIST sharedfeat name CDATA #REQUIRED>
<!ATTLIST sharedfeat value CDATA #IMPLIED>
<!ELEMENT part (feature*, dataarea*, diskarea*, dipswitch*)>
<!ATTLIST part name CDATA #REQUIRED>
<!ATTLIST part interface CDATA #REQUIRED>
<!-- feature is used to store things like pcb-type, mapper type, etc. Specific values depend on the system. -->
<!ELEMENT feature EMPTY>
<!ATTLIST feature name CDATA #REQUIRED>
<!ATTLIST feature value CDATA #IMPLIED>
<!ELEMENT dataarea (rom*)>
<!ATTLIST dataarea name CDATA #REQUIRED>
<!ATTLIST dataarea size CDATA #REQUIRED>
<!ATTLIST dataarea databits (8|16|32|64) "8">
<!ATTLIST dataarea endian (big|little) "little">
<!ELEMENT rom EMPTY>
<!ATTLIST rom name CDATA #REQUIRED>
<!ATTLIST rom size CDATA #REQUIRED>
<!ATTLIST rom crc CDATA #IMPLIED>
<!ATTLIST rom md5 CDATA #IMPLIED>
<!ATTLIST rom sha1 CDATA #IMPLIED>
<!ATTLIST rom offset CDATA #IMPLIED>
<!ATTLIST rom value CDATA #IMPLIED>
<!ATTLIST rom status (baddump|nodump|good) "good">
<!ATTLIST rom loadflag (load16_byte|load16_word|load16_word_swap|load32_byte|load32_word|load32_word_swap|load32_dword|load64_word|load64_word_swap|reload|fill|continue) #IMPLIED>
<!ELEMENT diskarea (disk*)>
<!ATTLIST diskarea name CDATA #REQUIRED>
<!ELEMENT disk EMPTY>
<!ATTLIST disk name CDATA #REQUIRED>
<!ATTLIST disk md5 CDATA #IMPLIED>
<!ATTLIST disk sha1 CDATA #IMPLIED>
<!ATTLIST disk status (baddump|nodump|good) "good">
<!ATTLIST disk writeable (yes|no) "no">
<!ELEMENT dipswitch (dipvalue*)>
<!ATTLIST dipswitch name CDATA #REQUIRED>
<!ATTLIST dipswitch tag CDATA #REQUIRED>
<!ATTLIST dipswitch mask CDATA #REQUIRED>
<!ELEMENT dipvalue EMPTY>
<!ATTLIST dipvalue name CDATA #REQUIRED>
<!ATTLIST dipvalue value CDATA #REQUIRED>
<!ATTLIST dipvalue default (yes|no) "no">