to private member variables with accessors:
machine->m_respool ==> machine->respool()
machine->config ==> machine->config()
machine->gamedrv ==> machine->system()
machine->m_regionlist ==> machine->first_region()
machine->sample_rate ==> machine->sample_rate()
Also converted internal lists to use simple_list.
As I wrote to the list a couple of months ago, there are many console protos which have been compiled from sources and have been released with odd sizes. This allows to load them in MESS from softlist (they are not bad dumps, strictly speaking, given they have never been burned on a cart...)
I hope there are no objections (a clear message is still written to the console, but the loading proceeds instead of stopping)
space by index. Update functions and methods that accepted an
address space index to take an address_spacenum instead. Note that
this means you can't use a raw integer in ADDRESS_SPACE macros, so
instead of 0 use the enumerated AS_0.
Standardized the project on the shortened constants AS_* over the
older ADDRESS_SPACE_*. Removed the latter to prevent confusion.
Also centralized the location of these definitions to memory.h.
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.
to driver_device. [Atari Ace]
Last commit should have been:
Removed globals from a number of device-like shared systems and made them
either statics or actual device variables. [Atari Ace]
