existing modern devices and the legacy wrappers to work in this
environment. This in general greatly simplifies writing a modern
device. [Aaron Giles]
General notes:
* some more cleanup probably needs to happen behind this change,
but I needed to get it in before the next device modernization
or import from MESS :)
* new template function device_creator which automatically defines
the static function that creates the device; use this instead of
creating a static_alloc_device_config function
* added device_stop() method which is called at around the time
the previous device_t's destructor was called; if you auto_free
anything, do it here because the machine is gone when the
destructor is called
* changed the static_set_* calls to pass a device_t & instead of
a device_config *
* for many devices, the static config structure member names over-
lapped the device's names for devcb_* functions; in these cases
the members in the interface were renamed to have a _cb suffix
* changed the driver_enumerator to only cache 100 machine_configs
because caching them all took a ton of memory; fortunately this
implementation detail is completely hidden behind the
driver_enumerator interface
* got rid of the macros for creating derived classes; doing it
manually is now clean enough that it isn't worth hiding the
details in a macro
this (and the previous commit) adds some duplicate code among file selector menu and softlist menu. I hope to find a clean way to unify the common functions at a later stage.
Remove redundant machine items from address_space and device_t.
Neither machine nor m_machine are directly accessible anymore.
Instead a new getter machine() is available which returns a
machine reference. So:
space->machine->xxx ==> space->machine().xxx
device->machine->yyy ==> device->machine().yyy
Globally changed all running_machine pointers to running_machine
references. Any function/method that takes a running_machine takes
it as a required parameter (1 or 2 exceptions). Being consistent
here gets rid of a lot of odd &machine or *machine, but it does
mean a very large bulk change across the project.
Structs which have a running_machine * now have that variable
renamed to m_machine, and now have a shiny new machine() method
that works like the space and device methods above. Since most of
these are things that should eventually be devices anyway, consider
this a step in that direction.
98% of the update was done with regex searches. The changes are
architected such that the compiler will catch the remaining
errors:
// find things that use an embedded machine directly and replace
// with a machine() getter call
S: ->machine->
R: ->machine\(\)\.
// do the same if via a reference
S: \.machine->
R: \.machine\(\)\.
// convert function parameters to running_machine &
S: running_machine \*machine([^;])
R: running_machine \&machine\1
// replace machine-> with machine.
S: machine->
R: machine\.
// replace &machine() with machine()
S: \&([()->a-z0-9_]+machine\(\))
R: \1
// sanity check: look for this used as a cast
(running_machine &)
// and change to this:
*(running_machine *)
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.
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.
functionality in favor of alternate mechanisms. Errors are
now reported via an astring rather than via callbacks. Every
option must now specify a type (command, integer, float, string,
boolean, etc). Command behavior has changed so that only one
command is permitted. [Aaron Giles]
Changed fileio system to accept just a raw searchpath instead of
an options/option name combination. [Aaron Giles]
Created emu_options class dervied from core_options which wraps
core emulator options. Added mechanisms to cleanly change the
system name and add/remove system-specific options, versus the
old way using callbacks. Also added read accessors for all the
options, to ensure consistency in how parameters are handled.
Changed most core systems to access emu_options instead of
core_options. Also changed machine->options() to return emu_options.
[Aaron Giles]
Created cli_options class derived from emu_options which adds the
command-line specific options. Updated clifront code to leverage
the new class and the new core behaviors. cli_execute() now accepts
a cli_options object when called. [Aaron Giles]
Updated both SDL and Windows to have their own options classes,
derived from cli_options, which add the OSD-specific options on
top of everything else. Added accessors for all the options so
that queries are strongly typed and simplified. [Aaron Giles]
Out of whatsnew: I've surely screwed up some stuff, though I have
smoke tested a bunch of things. Let me know if you hit anything odd.
Also I know this change will impact the WINUI stuff, please let me
know if there are issues. All the functionality necessary should
still be present. If it's not obvious, please talk to me before
adding stuff to the core_options class.
and manages a collection of hashes, and can be built from an internal
format string which is stored with each ROM. All core instances are
cleaned up to use the new interfaces, but it's likely that hashfile
code in MESS will need an update.
Also compacted the form of the hash strings used for ROMs, and fixed
verification/hashing of non-ZIPped files.
to pass a core_options object to the constructor, along with
a search path. This required pushing either a running_machine
or a core_options through some code that wasn't previously
ready to handle it. emu_files can be reused over multiple
open/close sessions, and a lot of core code cleaned up
nicely as things were converted to them.
Also created a file_enumerator class for iterating over files
in a searchpath. This replaces the old mame_openpath functions.
Changed machine->options() to return a reference.
Removed public nvram_open() and fixed jchan/kaneko16 to
stop directly saving NVRAM.
Removed most of the mame_options() calls; this will soon go
away entirely, so don't add any more.
Added core_options to device_validity_check() so they can be
used to validate things.
out of whatsnew: I also have modified best match for softlists to return 10 results, like in MAME, given that now only the correct list is parsed (thanks to Micko's change)
out of whatsnew: I also added a couple of helpers which count softlist elements and scan a list up to the n-th element. these are very unoptimized (for large lists) but I found them useful for debugging a few quirks in my first implementation and therefore I'd like to have them in the source.
- listsoftware option now return only original software lists
- UI is updated to enable mounting software items per device, it will display only items from list that are for specific device
- Separate compatible software lists in UI
- Software list xml files are now read in full such that information for clone and parent sets is available.
- Added validity check to check for existence of parent sets.
running_machine definition and implementation.
Moved global machine-level operations and accessors into methods on the
running_machine class. For the most part, this doesn't affect drivers
except for a few occasional bits:
mame_get_phase() == machine->phase()
add_reset_callback() == machine->add_notifier(MACHINE_NOTIFY_RESET, ...)
add_exit_callback() == machine->add_notifier(MACHINE_NOTIFY_EXIT, ...)
mame_get_base_datetime() == machine->base_datetime()
mame_get_current_datetime() == machine->current_datetime()
Cleaned up the region_info class, removing most global region accessors
except for memory_region() and memory_region_length(). Again, this doesn't
generally affect drivers.
this object which can be called multiple times to append new devices
after the initial machine configuration is set up. Updated member
variables to match new naming convention.
Changed the running_machine to take a constructed machine_config
object in the constructor, instead of creating one itself, for
consistency. Also added machine->total_colors() as a shortcut to
machine->config->m_total_colors.
