| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
| |
qix, quizpun2, stfight, tigeroad: Removed MACHINE_CONFIG. [Ryan Holtz]
-m68705, m68hc05: Removed MCFG. [Ryan Holtz]
-qix: First-pass cleanup. [Ryan Holtz]
-core: Fixed spelling of "nonexistent". [Ryan Holtz]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are multiple issues with the current device callbacks:
* They always dispatch through a pointer-to-member
* Chained callbacks are a linked list so the branch unit can't predict the early
* There's a runtime decision made on the left/right shift direction
* There are runtime NULL checks on various objects
* Binding a lambda isn't practical
* Arbitrary transformations are not supported
* When chaining callbacks it isn't clear what the MCFG_DEVCB_ modifiers apply to
* It isn't possible to just append to a callback in derived configuration
* The macros need a magic, hidden local called devcb
* Moving code that uses the magic locals around is error-prone
* Writing the MCFG_ macros to make a device usable is a pain
* You can't discover applicable MCFG_ macros with intellisense
* Macros are not scoped
* Using an inappropriate macro isn't detected at compile time
* Lots of other things
This changeset overcomes the biggest obstacle to remving MCFG_ macros
altogether. Essentially, to allow a devcb to be configured, call
.bind() and expose the result (a bind target for the callback). Bind
target methods starting with "set" repace the current callbacks; methods
starting with "append" append to them. You can't reconfigure a callback
after resolving it. There's no need to use a macro matching the
handler signatures - use FUNC for everything. Current device is implied
if no tag/finder is supplied (no need for explicit this).
Lambdas are supported, and the memory space and offset are optional.
These kinds of things work:
* .read_cb().set([this] () { return something; });
* .read_cb().set([this] (offs_t offset) { return ~offset; });
* .write_cb().set([this] (offs_t offset, u8 data) { m_array[offset] = data; });
* .write_cb().set([this] (int state) { some_var = state; });
Arbitrary transforms are allowed, and they can modify offset/mask for example:
* .read_cb().set(FUNC(my_state::handler)).transform([] (u8 data) { return bitswap<4>(data, 1, 3, 0, 2); });
* .read_cb().set(m_dev, FUNC(some_device::member)).transform([] (offs_t &offset, u8 data) { offset ^= 3; return data; });
It's possible to stack arbitrary transforms, at the cost of compile
time (the whole transform stack gets inlined at compile time). Shifts
count as an arbitrary transform, but mask/exor does not.
Order of mask/shift/exor now matters. Modifications are applied in the
specified order. These are NOT EQUIVALENT:
* .read_cb().set(FUNC(my_state::handler)).mask(0x06).lshift(2);
* .read_cb().set(FUNC(my_state::handler)).lshift(2).mask(0x06);
The bit helper no longer reverses its behaviour for read callbacks, and
I/O ports are no longer aware of the field mask. Binding a read
callback to no-op is not supported - specify a constant. The GND and
VCC aliases have been removed intentionally - they're TTL-centric, and
were already being abused.
Other quirks have been preserved, including write logger only logging
when the data is non-zero (quite unhelpful in many of the cases where
it's used). Legacy syntax is still supported for simple cases, but will
be phased out. New devices should not have MCFG_ macros.
I don't think I've missed any fundamental issues, but if I've broken
something, let me know.
|
| | |
|
| |
|
|
|
|
|
| |
suddenly silenced
* streamline templates in addrmap.h
* get rid of overloads on read/write member names - this will become even more important in the near future
|
| |
|
|
|
|
|
|
|
| |
confusing people for far too long. Yes, this is a change in behaviour.
Add a valdiation check for ROMs with BIOS flag set that are
unselectable, fix the things it uncovers.
(nw) Fix other random stuff.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allows defaulted clocks (see subtle example with vboy)
* Allows additional constructors (see RS232 port in tranz330)
* Allows use of device finder in place of tag in MCFG_DEVICE_ADD
* Requires out-of-line destructor for devices using incomplete types
* Requires XTAL or explicit u32 for clocks for devices with private types
Devices must still define the standard constructor. When writing
additional constructors, be aware that the constructor runs before
device_add_mconfig in the context of the existing device, not the new
device. See osborne1, zorba, tranz330, and vboy for examples of this in
use. Compilation is a bit slower, but this is temporary while
refactoring is in progress.
Eliminated the need for MCFG_SOUND_ROUTE_EX.
Removed macros from slot option configuration - they just obfuscated
code and slowed it down with needless dynamic casts, but didn't actually
simplify it.
|
| |
|
|
| |
Make machine_config aware of device being configured so owner doesn't need to be passed everywhere.
|
| |
|
|
| |
IPT_SPECIAL for the UI. [smf]
|
| |
|
|
| |
selection into device configuration complete
|
| |
|
|
| |
count_leading_ones() [smf]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASCII.
This has not been done unilaterally - I have the support of @galibert,
@Tafoid, and @rb6502 to do something about the current free-for-all.
The trouble with the ROM label field in MAME is that it serves multiple
competing purposes: it's supposed to identify the device in the original
system, and also act as a filename when searching for media image files
to load. It also has to appear in listings of needed/missing files
(e.g. in cases where the image _isn't_ found).
To identify the original device, the ROM label field in MAME often
contains text derived from some combination of one or more of the text
on a label if present, the silkscreen on an IC package, the location on
the circuit board, and the device designation. There's no standard for
the order in which these appear and how they're separated. Some people
add arbitrary filename extensions and other annotations.
There are practical limitations on what can appear in the string, given
it's used as a filename:
* Path/name length limits.
* Restrictions on characters that can appear in a filename.
* Practicality of using the filename in a command-line environment.
* Ambiguity when describing a filename.
Filesystems themselves typically restrict characters in filenames:
* Windows defines MAX_PATH as 260 characters - longer paths are
difficult to use with Win32 APIs and don't work properly in Windows
Explorer
* Most filesystems don't allow ^@ or the path separator in names.
* Windows doesn't allow C0 control characters or <>:"/\|?* characters in
filenames.
* Filesystems may have collation, e.g. FAT16 is case-folding, NTFS and
HFS+ are case-preserving but case-insensitive, while EXT and XFS are
case-sensitive.
* Filesystems may perform Unicode normalisation, e.g. NTFS forces NFC,
HFS+ forces NFD, while ZFS stores filenames as supplied at creation,
but may be configured to apply normalisation when testing equality.
Shells use various ASCII characters for special purposes:
* C0 control characters for line editing and control (e.g. ^C to cancel
a line, ^V for control charecter escape, ^R for history search).
* The "'\ chracaters for quoting/escaping.
* The ><| characters for redirection.
* The *?[] characters for pattern matching.
* The ${}~ characters for variable substitution/sequence expansion.
* The ! or ^ characters for history substitution.
* The ()` characters for controlling subshells.
* The %& characters for job control.
* The ; character as a command separator.
* The # character for comments.
There's also the issue of whether users across a range of locales will
be able to type/display characters. We still don't have good support
for Unicode console output on Windows (std::wcout doesn't seem to work
properly), many users don't install C/J/K fonts, and many users aren't
comfortable entering text in unfamiliar languages. This means we're
limited to printable ASCII for practical purposes.
The practical limitations mean the subset of "safe" characters is
limited to ASCII digits, either uppercase or lowercase English Latin
(but not both due to collation behaving differently across systems), and
the +,-.=_ punctuation chracters. We've decided on lowercase, digits,
and safe punctuation. In addition to this, spaces are allowed, as they
can be quoted/escaped easily enough if no other special characters are
used.
There have been some arguments that allowing uppercase is "more
accurate", but in practical terms it doesn't add much value. A string
in a C++ program can't represent layout, relative size of text, colour
and shape of the label, text font, graphics, and many other details. It
also does nothing to address labels with text outside the English Latin
alphabet (e.g. labels with Chinese ideographs). Besides missing
information, the lack of hard and fast rules means you need to intuit
what a label string in MAME is trying to represent. There is simply no
substitute for photographs. There wasn't even any consistency in case
within individual machine sets. For example, several games in
vigilant.cpp had inconsistent case for "ic" vs "IC" in designation
suffixes, and ibm6850.cpp had inconsistent case for filename extensions
withing a set. There were sets that used uppercase for text from the
label but not from the part number/PCB location, and vice versa. It was
a huge mess.
There's some merit to the idea of allowing a wider variety of characters
in the label strings in the source, and mapping to a more restricted set
when searching for files. However it creates more issues than it
solves. It would require a change to the XML output to provide both the
label and filename, and a corresponding change to external ROM
management tools. It would be impractical to do for software lists,
because it would require ROM management tools to implement the exact
same mapping algorithm as MAME.
But that aside, actually doing useful mapping would be impractical.
What would you do with C/J/K ideographs, like the chip labelled
東方不敗 (Dongfang Bubai)? There's no intuitive way to do the mapping
wtihout incluing something like Unihan data, which would add a lot of
bloat. Even the, without a language hint the Romanisation would be less
than ideal in many cases (using Chinese reading for Japanese text and
vice versa). There's still the messy issue of filesystem collation to
deal with.
We do allow full Unicode in comments in the source. If you want to
provide a more detailed description of a ROM label, that's the place for
it. You've got more characters available, and the possibility of using
mulitple lines. There are too many other competing requirements on the
label field in the ROM definitions.
|
| | |
|
| |
|
|
|
|
| |
* destaticify initializations (nw)
* fix this->set_screen (nw)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
prototype is simplified [O. Galibert]
Beware, the device context does not follow in MCFG_FRAGMENT_ADD
anymore due to the prototype change. So creating a device then
configuring through a fragment doesn't work as-is. The simplest
solution is just to add a MCFG_DEVICE_MODIFY at the start of the
fragment with the correct tag.
|
| |
|
|
| |
This reverts commit 54155441e9ba9941e85d80c4834a66376a11e791.
|
| |
|
|
|
| |
This reverts commit f537428e5a40ba6dde8ca9bf0fe9ae6b1f189ac4, reversing
changes made to 0d70d798107d4e4e8fb9f230410aeb1e888d65c5.
|
| | |
|
| |
|
|
| |
same tag (nw)
|
| |\
| |
| | |
Added support for multiple PORT_CHAR() bindings, and adopted in the CoCo driver (addresses MT#2618)
|
| | |
| |
| |
| | |
driver (addresses MT#2618)
|
| | |
| |
| |
| |
| |
| | |
* rgbsse: Optimize some sse routines. (nw)
* rgbsse: Create a generic getter instead of having individual color operation. (nw)
* rgbsse: Allow up to 12 bits for scaling factors. (nw)
|
| |/ |
|
| |
|
|
| |
needing to allocate everywhere, improve performance of -listxml by another 10% or so
|
| |
|
|
| |
(uni)codes (#2618)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Error on characters other than [a-z0-9.-_] in name
* Error on duplicate name or description
* Error on non-existent default BIOS
Still errors for duplicate BIOS descriptions in AdamNet FDC and mc1502 -
I dont' know enough about these systems to make useful descrptions.
Could someone who knows what these things are please disambiguate the
descriptions?
* Adam FDC descripes 320ta, dbl24 and dsdd as "320KB DSDD"
* mc1502 describes v531 and v531_92 as "v5.31 12/10/92"
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, flags for unemulated/imperfect features apply at system
level. This falls over quickly with systems that have slot devices.
For example you can plug in a broken sound card or keyboard on a PC or
Amiga driver and get no warnings. There's also no way to propagate
these flags from a device to all systems using it.
This changeset addresses these issues. It's now possible to report
unemulated/imperfect features on a device level with static
unemulated_feeatures() and imperfect_features() member functions. So
far the only thing using this is the votrax device.
To support front-ends, this is exposed in -listxml output as a new
"feature" element that can appear in system/device descriptions. It has
a "type" attribute indicating which feature it is, potentially a
"status" attribute if the device itself declares that the feature is
unemulated/imperfect, and potentially an "overall" attribute if the
device inherits a more severe indication from a subdevice. The embedded
DTD describes possible values.
Example: device/machine declares imperfect sound:
<feature type="sound" status="imperfect"/>
Example: device/machine declares unemulated keyboard:
<feature type="keyboard" status="unemulated"/>
Example: device declares imperfect controls but inherits unemulated
controls from a subdevice:
<feature type="controls" status="imperfect" overall="unemulated"/>
Example: device doesn't declare imperfect LAN but inherits it from a
subdevice:
<feature type="lan" overall="imperfect"/>
It's still possible to add these flags to machines in the GAME/COMP/CONS
macro. If the state class declares them with static member functions,
the two sources will be combined.
If you subclass a device, you inherit its flags if you don't redefine
the relevant static member functions (no override qualifier is necessary
since they're static).
The UI has been updated to display appropriate warnings for the overall
machine configuration, including selected slot devices, at launch time.
The menus don't display overall status, only status for the machine
itself. We can make it scan subdevices if we decide that's desirable,
it just needs caching to enure we don't take a huge performance hit.
|
| |
|
|
| |
it flags usually get detected elsewhere (nw)
|
| | |
|
| |
|
|
|
| |
- All slot options are now validated whether or not they are user-selectable. This has already exposed a bug in one MSX-Audio device.
- Slots within slots, however, get added for validation only if they are declared fixed. Various Commodore floppy drives have been affected by this, since it doesn't look as if the current FDC emulation allows for detachability.
|
| | |
|
| | |
|
| |
|
|
| |
find regions properly, need to work out why
|
| |
|
|
|
|
|
|
|
|
|
| |
Note that this currently segfaults on anything ISA, and probably other
stuff. For example, any of the following will crash:
* mame -valid c386sx16
* mame -valid 386i
* mame -valid b128
Pushing before dinner so others can take a look
|
| | |
|
| |
|
|
|
| |
* -validate complains if device shortnames exceed 32 characters
* -listroms and -verifyroms accept multiple names/patterns
|
| |
|
|
|
|
| |
- Make single-driver command-line validation work again
- Correct some fruit machine driver classes
- Remove some now-redundant checks related to device name validity (including the slot test, which also made assumptions that some ti99 bus devices now break)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
significant change, so please pay attention.
The core changes are:
* Short name, full name and source file are no longer members of device_t, they are part of the device type
* MACHINE_COFIG_START no longer needs a driver class
* MACHINE_CONFIG_DERIVED_CLASS is no longer necessary
* Specify the state class you want in the GAME/COMP/CONS line
* The compiler will work out the base class where the driver init member is declared
* There is one static device type object per driver rather than one per machine configuration
Use DECLARE_DEVICE_TYPE or DECLARE_DEVICE_TYPE_NS to declare device type.
* DECLARE_DEVICE_TYPE forward-declares teh device type and class, and declares extern object finders.
* DECLARE_DEVICE_TYPE_NS is for devices classes in namespaces - it doesn't forward-declare the device type.
Use DEFINE_DEVICE_TYPE or DEFINE_DEVICE_TYPE_NS to define device types.
* These macros declare storage for the static data, and instantiate the device type and device finder templates.
The rest of the changes are mostly just moving stuff out of headers that shouldn't be there, renaming stuff for consistency, and scoping stuff down where appropriate.
Things I've actually messed with substantially:
* More descriptive names for a lot of devices
* Untangled the fantasy sound from the driver state, which necessitates breaking up sound/flip writes
* Changed DECO BSMT2000 ready callback into a device delegate
* Untangled Microprose 3D noise from driver state
* Used object finders for CoCo multipak, KC85 D002, and Irem sound subdevices
* Started to get TI-99 stuff out of the TI-990 directory and arrange bus devices properly
* Started to break out common parts of Samsung ARM SoC devices
* Turned some of FM, SID, SCSP DSP, EPIC12 and Voodoo cores into something resmbling C++
* Tried to make Z180 table allocation/setup a bit safer
* Converted generic keyboard/terminal to not use WRITE8 - space/offset aren't relevant
* Dynamically allocate generic terminal buffer so derived devices (e.g. teleprinter) can specify size
* Imporved encapsulation of Z80DART channels
* Refactored the SPC7110 bit table generator loop to make it more readable
* Added wrappers for SNES PPU operations so members can be made protected
* Factored out some boilerplate for YM chips with PSG
* toaplan2 gfx
* stic/intv resolution
* Video System video
* Out Run/Y-board sprite alignment
* GIC video hookup
* Amstrad CPC ROM box members
* IQ151 ROM cart region
* MSX cart IRQ callback resolution time
* SMS passthrough control devices starting subslots
I've smoke-tested several drivers, but I've probably missed something. Things I've missed will likely blow up spectacularly with failure to bind errors and the like. Let me know if there's more subtle breakage (could have happened in FM or Voodoo).
And can everyone please, please try to keep stuff clean. In particular, please stop polluting the global namespace. Keep things out of headers that don't need to be there, and use things that can be scoped down rather than macros.
It feels like an uphill battle trying to get this stuff under control while more of it's added.
|
| |
|
|
|
|
|
|
|
|
| |
(#2232)
* Changed validity_checker to keep a fresh emu_options for validation purposes
This seems to solve the performance problems introduced by PR#2221 while keeping with that PR's goals of not using the "runtime" emu_options for purposes of validation.
* Sorry, I can't spell apparently...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comes from a regression reported by Tafoid whereby the following command line:
mame coco wildcat
Would report the following error (which was not really fatal because it happened within validation):
Driver t4426 (file coco12.cpp): 1 errors, 0 warnings
Errors:
Fatal error Unknown slot option 'pak' in slot 'ext'
My changes to option processing changed emu_options to put image and slot options in their own arrays, and I expect those image/slot options to be pertinent to the active driver. However, driver validation was passing the emu_options associated with the main emulation to validation specific maching_config for other drivers. This changes validate_one() to always use a fresh emu_options with each individual validation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* New abbreviated types are in osd and util namespaces, and also in global namespace for things that #include "emu.h"
* Get rid of import of cstdint types to global namespace (C99 does this anyway)
* Remove the cstdint types from everything in emu
* Get rid of U64/S64 macros
* Fix a bug in dps16 caused by incorrect use of macro
* Fix debugcon not checking for "do " prefix case-insensitively
* Fix a lot of messed up tabulation
* More constexpr
* Fix up many __names
|
| |
|
|
|
| |
Use standard uint64_t, uint32_t, uint16_t or uint8_t instead of UINT64, UINT32, UINT16 or UINT8
also use standard int64_t, int32_t, int16_t or int8_t instead of INT64, INT32, INT16 or INT8
|
| |
|
|
| |
utf16_char, unicode_char (nw)
|