summaryrefslogtreecommitdiffstatshomepage
path: root/src/emu/validity.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Allow devices to specify a parent for the purpose of searching for ROMs. Vas Crabb2021-09-061-6/+21
|
* API cleanups and miscellaneous fixes. Vas Crabb2021-07-151-14/+15
| | | | | | | | | | | | | | | | emu/ioport.cpp: Allow controller files to override input sequences for inputs that don't use defaults, and to override the toggle setting for digital inputs. emu/config.cpp: Expose configuration level (mostly matters for controller files), improved verbose diagnostic messages, and moved a few things out of the global and preprocessor namespaces. docs: Added documentation for some controller configuration file features. The device mapping feature documentation will be merged in at some point. util/unicode.cpp, emu/input.cpp: API cleanups.
* Added helpers for 64-bit count leading zeroes/ones. Vas Crabb2021-06-131-4/+4
|
* Ensure validation of device tags in non-default slot options AJR2021-02-201-0/+1
|
* Eliminate ARRAY_LENGTH template in favor of C++17's std::size AJR2021-02-141-1/+1
| | | | | | | | | | * osdcomm.h: Move definition of EQUIVALENT_ARRAY to coretmpl.h * sharc.cpp, gt64xxx.cpp, ym2413.cpp, gb_lcd.cpp, snes_ppu.cpp: Use STRUCT_MEMBER for save state registration * gio/newport.cpp, megadrive/svp.cpp, nes_ctrl/bcbattle.cpp, arm7.cpp, tms9995.cpp, pckeybrd.cpp, sa1110.cpp, sa1111.cpp, jangou_blitter.cpp, vic4567.cpp: Use std::fill(_n) instead of memset * emucore.h: Remove obsolete typedef
* Much more core std::string_view modernization AJR2021-01-201-5/+6
| | | | | | | | | | | | | | | - Remove corestr.h from emu.h; update a few source files to not use it at all - Change strtrimspace, strtrimrightspace and core_filename_extract_* to be pure functions taking a std::string_view by value and returning the same type - Change strmakeupper and strmakelower to be pure functions taking a std::string_view and constructing a std::string - Remove the string-modifying version of zippath_parent - Change tag-based lookup functions in device_t to take std::string_view instead of const std::string & or const char * - Remove the subdevice tag cache from device_t (since device finders are now recommended) and replace it with a map covering directly owned subdevices only - Move the working directory setup method out of device_image_interface (only the UI seems to actually use the full version of this) - Change output_manager to use std::string_view for output name arguments - Change core_options to accept std::string_view for most name and value arguments (return values are still C strings for now) - Change miscellaneous other functions to accept std::string_view arguments - Remove a few string accessor macros from romload.h - Remove many unnecessary c_str() calls from logging/error messages
* -osd: Clean up inline maths utilities. Vas Crabb2021-01-181-2/+2
| | | | | | | | | | * Removed inline assembly for operations compilers handle well. * Added ARM and AArch64 implementation for a few operations. * Added unsigned integer add with carry out operations. -cpu/drccache.cpp: Detect whether RWX pages are supported. -dynax.cpp: Improved a few hanafuda DIP switch descriptions.
* unicode.h: Updates AJR2020-12-151-0/+1
| | | | | - Remove from emu.h (except for UTF8_xxx macros, which have been transplanted to emucore.h since a lot of drivers use them) and osdepend.h - Add std::string_view overrides for uchar_from_utf8 and normalize_unicode
* Fairly significant overhaul of Lua engine and some cleanup. Vas Crabb2020-11-251-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The things that were previously called device iterators are not iterators in the C++ sense of the word. This is confusing for newcomers. These have been renamed to be device enumerators. Several Lua methods and properties that previously returned tables now return lightweight wrappers for the underlying objects. This means creating them is a lot faster, but you can't modify them, and the performance characteristics of different operations varies. The render manager's target list uses 1-based indexing to be more like idiomatic Lua. It's now possible to create a device enumerator on any device, and then get subdevices (or sibling devices) using a relative tag. Much more render/layout functionality has been exposed to Lua. Layout scripts now have access to the layout file and can directly set the state of an item with no bindings, or register callbacks to obtain state. Some things that were previously methods are now read-only properties. Layout files are no longer required to supply a "name". This was problematic because the same layout file could be loaded for multiple instances of the same device, and each instance of the layout file should use the correct inputs (and in the future outputs) for the device instance it's associated with. This should also fix video output with MSVC builds by avoiding delegates that return things that don't fit in a register.
* validity.cpp, devfind.cpp: Catch missing required I/O ports in systems ↵ Vas Crabb2020-08-281-19/+31
| | | | (excluding slot cards)
* validity.cpp: Limit characters allowed in I/O port tags, and check ROMs and ↵ Vas Crabb2020-08-271-25/+41
| | | | I/O ports for devices individually.
* Clean up the preprocessor glue for selecting RGB utility implementation a little Vas Crabb2020-08-211-1/+1
|
* validity.cpp: Added checks for bilinear filter vector routines Ted Green2020-07-081-2/+56
|
* (nw) softlist_dev.cpp: validate ROM labels Vas Crabb2020-04-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The free-for-all on labels in software lists is not working. There's no consistency, labels are getting excessively long, people are starting to use non-ASCII characters in labels making it harder for others to type them when manipulating files on the command line, and there's too much markup being put in labels. The length limit is 127 characters, same as for labels in MAME itself. This should be long enough to be descriptive. Remember that the Win32 path limit is 260 characters, and many applications and frameworks have issues with longer paths, including Windows Explorer and the .NET framework. Labels are used as filenames, so concessions need to be made for this. I have not abbreviated excessively long labels myself - they're currently causing 135 validity errors. Someone else can fix them. Printable ASCII characters are allowed, with a few exceptions. The exceptions are limited to characters most likely to cause issues for interactive shells and scripts: * ! - csh event substitution (very difficult to escape properly) * $ - sh varibale expansion * % - csh job control, cmd variable expansion * / - UNIX directory separator * : - sh path separator, Windows drive qualifier * \ - sh escape, Windows directory separator Most of the labels that had to be edited were using ! for markup, or using ! and % for titles in labels. Strangely, titles in labels are often forced to lower case, despite this never being enforced for software lists. There are also various other edits to titles used for labels, such as moving articles to the end (with or without a comma), or replacing spaces with underscores. As I already said, there's no consistency at all. There is far too much markup in labels. They're even being used for notes in some cases (e.g. at least one case where a dumper's name is in the label). The XML schema supports metadata - use it. For example, you can use part_id for an unrestricted display name for a software part. You can also use XML comments for notes. And while on the topic of metadata, vgmplay.xml is putting the same thing in the part_id as well as the label. The part_id should have the actual title, not the title mangled to make it more suitable for use as a filename. Addressing this would be a lot of work, given how large the file is. For now, empty data areas in software lists cause a verbose message rather than a validation warning. There are thousands of software lists using empty data areas to indicate the size/width of cartridge RAM/EEPROM/etc.
* softlist_dev.cpp: start adding validation for data areas Vas Crabb2020-04-161-1/+1
| | | | | | | | | | romload.cpp: reduce copy-pasta (nw) (nw) I fixed the errors found by adding validation to software list data areas. Most of them seem to be simple copy-paste errors hidden by the fact that the default device_image_interface loader ignores the data area size (as opposed to the "ROM" loader). There was one C64 cartridge with a missing zero on the data area size that was pretty clearly wrong.
* fixed some clang-tidy warnings (nw) (#6229) Oliver Stöneberg2020-01-291-9/+9
| | | | | | | | | | | | | | | | * fixed some readability-static-accessed-through-instance clang-tidy warnings (nw) * fixed some readability-redundant-string-cstr clang-tidy warnings (nw) * fixed some readability-redundant-control-flow clang-tidy warnings (nw) * fixed some modernize-use-nullptr clang-tidy warnings (nw) * fixed some performance-faster-string-find clang-tidy warnings (nw) * fixed some performance-for-range-copy clang-tidy warnings (nw) * fixed some performance-unnecessary-value-param clang-tidy warnings (nw)
* use C++ library includes (nw) firewave2020-01-221-1/+1
|
* Spring cleaning: Vas Crabb2019-11-011-2/+2
| | | | | | | | | | | | * Changed emu_fatalerror to use util::string_format semantics * Fixed some incorrectly marked up stuff in build scripts * Make internal layout compression type a scoped enum (only zlib is supported still, but at least the values aren't magic numbers now) * Fixed memory leaks in Xbox USB * There can only be one "perfect quantum" device - enforce that only the root machine can set it, as allowing subdevices to will cause weird issues with slot cards overiding it * Allow multiple devices to set maximum quantum and use the most restrictive one (it's maximum quantum, it would be minimum interleave) * Got rid of device_slot_card_interface as it wasn't providing value * Added a helper template to reduce certain kinds of boilerplate in slots/buses * Cleaned up some particularly bad slot code (plenty more of that to do), and made some slots more idiomatic
* Make osd_printf_* use util/strformat semantics. Vas Crabb2019-09-261-60/+54
| | | | | | | | | | | | | | | | | (nw) This has been a long time coming but it's here at last. It should be easier now that logerror, popmessage and osd_printf_* behave like string_format and stream_format. Remember the differences from printf: * Any object with a stream out operator works with %s * %d, %i, %o, %x, %X, etc. work out the size by magic * No sign extending promotion to int for short/char * No widening/narrowing conversions for characters/strings * Same rules on all platforms, insulated from C runtime library * No format warnings from compiler * Assert in debug builds if number of arguments doesn't match format (nw) Also removed a pile of redundant c_str and string_format, and some workarounds for not being able to portably format 64-bit integers or long long.
* 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"