out of whatsnew: I also hooked up the list to the driver, even if I have no idea to which degree the system works these days (I don't know much about this machine).
out of whatsnew: the disk dumps do not come from original media, but given that no more program disks ever appeared in the past two years and that even the website which originally hosted these disks disappeared, it is definitely worth documenting them before they get lost forever...
* Marked quizkof MVS AND AES VERSION
* Cleaned up all labels (consistent for all protos now) for prototype sets (in 99.9% of the cases the correct labels are not known) to: proto_ID-XX.XX
* Identified product codes for viewpoint, savager and blazstar
* kotm2p m1/s1 parent/clone fix
* Documentation update
* Reflected changes in internal db to xml (except /* Plane x */ )
multislot support [David Haywood]
Please note: launching convention for Neo-Geo games is now the same as
MESS software lists "mame neogeo gamename" or "mame neogeo -cart
gamename".
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.
Comment: There are still a few issues with some games where the data might need refining. The following sets do not work, even as a 1 slot game but work as normal sets; (mt_tetri, mt_gng, mt_fwld, mt_srbb)
- SoftList is incompelte, I hate working with the XML, if somebody wants to add the remaining titles, be my guest
- SMS games have issues, the CPU isn't being properly reset (or something) when moving between games, so stick to only a single SMS game for now or the z80 will crash.
It used to work, but the code has been out of use for a while.
- syntax is MAME megatech -cart1 mt_beast -cart2 mt_soni2 -cart8 mt_shar2
