| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
error on bootup.
|
|
|
|
| |
lines, nw
|
| |
|
|
|
|
| |
HC705. nw
|
| |
|
|
|
|
| |
eliminated MACHINE_RESET_OVERRIDE use in the driver, nw
|
| |
|
|
|
|
| |
emu\memarray.h cause I didn't want to cause a full recompile for this (nw)
|
|
|
|
| |
internal maps. [Ryan Holtz]
|
| |
|
|
|
|
| |
converted SCC68070 to use logmacro. [Ryan Holtz]
|
|
|
|
| |
machine reset time. This removes the need for many drivers to reset the CPU an extra time to load the correct vector.
|
| |
|
|
|
|
|
|
| |
- Remove spurious second interrupt output (was already dummied out)
- Take ownership of shared pointers to video RAM
- Improve device name
|
| |
|
| |
|
|
|
|
|
| |
- Add internal clock divider
- Add a few crude hacks to force status bits in unemulated UART and I2C
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively reverts b380514764cf857469bae61c11143a19f79a74c5 and
c24473ddff715ecec2e258a6eb38960cf8c8e98e, restoring the state at
598cd5227223c3b04ca31f0dbc1981256d9ea3ff.
Before pushing, please check that what you're about to push is sane.
Check your local commit log and ensure there isn't anything out-of-place
before pushing to mainline. When things like this happen, it wastes
everyone's time. I really don't need this in a week when real work™ is
busting my balls and I'm behind where I want to be with preparing for
MAME release.
|
|
|
|
|
| |
This reverts commit c24473ddff715ecec2e258a6eb38960cf8c8e98e, reversing
changes made to 009cba4fb8102102168ef32870892438327f3705.
|
|
|
|
|
|
|
| |
* divideo.h : Remove MCFG_VIDEO_SET_SCREEN usage
attckufo.cpp, bw2.cpp, cdi.cpp, gambl186.cpp, gamtor.cpp, ibmpcjr.cpp, intv.cpp, photoply.cpp, pntnpuzl.cpp, tandy1t.cpp : Remove MCFGs
* ibmpcjr.cpp : Partially revert this
|
|
|
|
| |
also removed MCFG_DEVICE_REMOVE, MCFG_QUANTUM_TIME and MCFG_QUANTUM_PERFECT_CPU (nw)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Input and screen tags are now resolved relative to a layout's owner
device.
Easy way to demonstrate is with: mame64 intlc440 -tty ie15
Previously you'd only get the IE15 terminal's layout and you'd be unable
to use the INTELLEC 4/40 front panel. Now you'll get the choice of
layouts from both the system and the terminal device in video options.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
c352: Eliminated customized MCFG_DEVICE_ADD macros. (nw)
|
| |
|
|
|
|
| |
cleanup. Could be improved further. (nw)
|
|
|
|
|
|
|
|
|
|
|
|
| |
side effect of making machine-config overrides of these much"
This reverts commit c83e2a853d4e1643fcc85b68ada3c6f7f33adea4.
Revert "fix compile. (nw)"
This reverts commit a259ba3e366f442a22a9341755ff58163869860c.
GCC is being bad and allowing invalid C++ that other compilers reject.
|
|
|
|
|
|
| |
of making machine-config overrides of these much
uglier, but this is intended to discourage ongoing use, and will be gradually eliminated.
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit. (#3565)
* -Removed DRIVER_INIT macros in favor of explicitly-named member functions, nw
* -Removed DRIVER_INIT_related macros. Made init_ prefix on driver initializers explicit. Renamed init_0 to empty_init. Fixed up GAME/COMP/CONS macro spacing. [Ryan Holtz]
* Missed some files, nw
* Fix compile, (nw)
|
|
|
|
| |
(nw) remove more MCFG macros and make speaker config more explicit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Start replacing special device macros with additional constructors,
starting with ISA, INTELLEC 4 and RS-232 buses.
Allow an object finder to take on the target of another object finder.
(For a combination of the previous two things in action, see either the
INTELLEC 4 driver, or the Apple 2 PC Exporter card. Also check out
looping over a device finder array to instantiate devices in some
places. Lots of things no longer need to pass tags around.)
Start supplying default clocks for things that have a standard clock or
have all clocks internal.
Eliminate the separate DEV versions of the DEVCB_ macros. Previously,
the plain versions were a shortcut for DEVICE_SELF as the target. You
can now supply a string tag (relative to current device being
configured), an object finder (takes on the base and relative tag), or
a reference to a device/interface (only do this if you know the device
won't be replaced out from under it, but that's a safe assumption for
your subdevices). In almost all cases, you can get the effect you want
by supplying *this as the target.
Eliminate sound and CPU versions of macros. They serve no useful
purpose, provide no extra checks, make error messages longer, add
indirection, and mislead newbies into thinking there's a difference.
Remove a lot of now-unnecessary ":" prefixes binding things relative to
machine root.
Clean up some miscellaneous rot.
Examples of new functionality in use in (some more subtle than others):
* src/mame/drivers/intellec4.cpp
* src/mame/drivers/tranz330.cpp
* src/mame/drivers/osboren1.cpp
* src/mame/drivers/zorba.cpp
* src/mame/devices/smioc.cpp
* src/devices/bus/a2bus/pc_xporter.cpp
* src/devices/bus/isa/isa.h
* src/devices/bus/isa/isa.h
* src/devices/bus/intellec4/intellec4.h
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
There's no voodoo involved in derived machine configurations and
fragments any more. The macros were just obfuscating things at this
point.
|
| |
|
|
|
|
|
| |
Also, a lot more freedom happened, that's going to be more visible
soon.
|
|
|
|
|
|
|
| |
This allows for the much more natural "import another map and patch
it" structure, or "cover a whole region then punch holes in it". Our
previous first-entry-wins rule was always a surprise to newcomers, and
oldcomers too.
|
| |
|