summaryrefslogtreecommitdiffstatshomepage
path: root/src/emu/validity.cpp
Commit message (Collapse)AuthorAgeFilesLines
* (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"
* 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.