summaryrefslogtreecommitdiffstatshomepage
path: root/src/emu/validity.cpp
Commit message (Collapse)AuthorAgeFilesLines
* validity.cpp: Be more verbose when validating device types (nw) AJR2019-06-171-0/+3
|
* -keyboard/a1200, changela, goldnpkr, m68705prg, mexico86, pipeline, pitnrun, ↵ mooglyguy2018-12-141-1/+1
| | | | | | | | | | 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]
* (nw) fix lots of inadverently mutable static pointers Vas Crabb2018-09-201-1/+1
|
* devcb3 Vas Crabb2018-07-071-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Move ROM loading macros to romentry.h and remove romload.h from emu.h (nw) AJR2018-06-241-0/+1
|
* as if millions of this pointers suddenly cried out in terror, and were ↵ Vas Crabb2018-06-081-4/+2
| | | | | | | 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
* Move the +1 to the proper place in the ROM BIOS macros - that's been Vas Crabb2018-05-291-3/+8
| | | | | | | | | 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.
* Make MCFG_DEVICE_ADD and callable device types more flexible: Vas Crabb2018-05-041-1/+2
| | | | | | | | | | | | | | | | | | | | | * 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 devopt menu localisable. Vas Crabb2018-04-281-17/+24
| | | | Make machine_config aware of device being configured so owner doesn't need to be passed everywhere.
* Standardise on IPT_CUSTOM for hooking up custom code in PORT_BIT, leaving ↵ smf-2018-04-031-0/+3
| | | | IPT_SPECIAL for the UI. [smf]
* Allow machine configuration to specify BIOS easily, move default BIOS ↵ Vas Crabb2018-03-261-0/+2
| | | | selection into device configuration complete
* validity check: test all 32 results from count_leading_zeros() & ↵ smf-2018-03-211-10/+12
| | | | count_leading_ones() [smf]
* Restrict ROM labels to a filesystem- and shell-safe subset of printable Vas Crabb2018-03-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Cycle-accurate DSP16 core (disabled in QSound for performance reasons) Vas Crabb2018-03-151-1/+1
|
* destaticify initializations (nw) (#3289) wilbertpol2018-03-041-2/+2
| | | | | | * destaticify initializations (nw) * fix this->set_screen (nw)
* Register device callbacks and add some basic validation for them AJR2018-02-201-0/+6
|
* Fixes (nw) Olivier Galibert2018-02-131-2/+4
|
* API Change: Machine configs are now a method of the owner class, and the ↵ Olivier Galibert2018-01-171-4/+4
| | | | | | | | | | 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.
* Revert "Revert "Merge branch 'master' of https://github.com/mamedev/mame"" Firehawke2017-12-131-0/+4
| | | | This reverts commit 54155441e9ba9941e85d80c4834a66376a11e791.
* Revert "Merge branch 'master' of https://github.com/mamedev/mame" Firehawke2017-12-131-4/+0
| | | | | This reverts commit f537428e5a40ba6dde8ca9bf0fe9ae6b1f189ac4, reversing changes made to 0d70d798107d4e4e8fb9f230410aeb1e888d65c5.
* allow compiler a little more optimisation leeway in x86 count_leading_* (nw) Vas Crabb2017-12-021-0/+4
|
* validity.cpp: Prevent insane recursion when multiple slot devices have the ↵ AJR2017-11-301-2/+3
| | | | same tag (nw)
* Merge pull request #2672 from npwoods/multiple_natural_keyboard_bindings R. Belmont2017-10-101-6/+9
|\ | | | | Added support for multiple PORT_CHAR() bindings, and adopted in the CoCo driver (addresses MT#2618)
| * Added support for multiple PORT_CHAR() bindings, and adopted in the CoCo ↵ Nathan Woods2017-09-241-6/+9
| | | | | | | | driver (addresses MT#2618)
* | rgbsse: Optimize some sse routines. (nw) (#2700) tedgreen992017-10-091-0/+32
| | | | | | | | | | | | * 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)
* | rgbsse: Rather simple performance optimization. (nw) Ted Green2017-09-291-0/+8
|/
* Start adding stuff for iterating ROM entries in a more C++ way without ↵ Vas Crabb2017-09-221-11/+11
| | | | needing to allocate everywhere, improve performance of -listxml by another 10% or so
* Added a natural keyboard validation to check for valid natural keyboard ↵ npwoods2017-09-051-0/+13
| | | | (uni)codes (#2618)
* fix exit status (nw) Vas Crabb2017-09-051-1/+1
|
* -validate will now report an error if no matches occur Nathan Woods2017-09-041-0/+10
|
* Validate BIOS names and fix most errors found: Vas Crabb2017-08-251-18/+46
| | | | | | | | | | | | | * 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"
* fix -valid with MSVC (nw) Vas Crabb2017-08-241-1/+1
|
* Move unemulated/imperfect flags from machines into devices. Vas Crabb2017-07-271-10/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* remove this check - it causes MSVC release builds to crash, and the things ↵ Vas Crabb2017-07-151-65/+56
| | | | it flags usually get detected elsewhere (nw)
* Should be slightly more efficient this way (nw) AJR2017-06-101-4/+7
|
* Further improvements to slot option validation (nw) AJR2017-06-101-36/+33
| | | | | - 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.
* fix the missing default subslot devices on slot card validation Vas Crabb2017-06-111-2/+21
|
* Fix region validation for slot devices (nw) AJR2017-06-101-3/+4
|
* improve code for instantiating slot devices for validation - still doesn't ↵ Vas Crabb2017-06-111-2/+14
| | | | find regions properly, need to work out why
* Attempt basic validation of slot cards Vas Crabb2017-06-101-0/+21
| | | | | | | | | | | 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
* Add validation check for contradictory flags, fix things it caught (nw) Vas Crabb2017-05-311-1/+9
|
* More auxiliary verb stuff: Vas Crabb2017-05-181-0/+4
| | | | | * -validate complains if device shortnames exceed 32 characters * -listroms and -verifyroms accept multiple names/patterns
* Misc. validation fixes (nw) AJR2017-05-181-34/+1
| | | | | | - 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)
* Move static data out of devices into the device types. This is a ↵ Vas Crabb2017-05-141-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Changed validity_checker to keep a fresh emu_options for validation purposes ↵ npwoods2017-04-151-2/+1
| | | | | | | | | | (#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...
* Changed the validity checks to have its own emu_options Nathan Woods2017-04-091-1/+2
| | | | | | | | | | | | | | 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.
* clean up a few more device issues, add basic device validation Vas Crabb2017-03-031-10/+130
|
* Introduce u8/u16/u32/u64/s8/s16/s32/s64 Vas Crabb2016-11-191-252/+252
| | | | | | | | | | | | * 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
* NOTICE (TYPE NAME CONSOLIDATION) Miodrag Milanovic2016-10-221-252/+252
| | | | | 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
* use standard types uintptr_t, char16_t and char32_t instead of FPTR, ↵ Miodrag Milanovic2016-10-221-1/+1
| | | | utf16_char, unicode_char (nw)