| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mame_machine_manager::instance()->ui()
Dynamic casts are never one's first choice, but this is superior to
grabbing a global singleton. Upon merging more worker_ui changes, it
will be possible for machine().ui() to be an implementation of
ui_manager distinct from mame_ui_manager, so this code is being changed
to gracefully handle this scenario. Plus, global singletons like
mame_machine_manager::instance are just plain ugly.
Lastly, I would like someone familiar with the LUA integration to look
at this, not just for correctness, but to validate my approach of
keeping LUA's mame_machine_manager::ui() equivalent returning the
mame_ui_manager while changing how it is implemented. Even if getting
rid of mame_machine_manager::ui() is the right way to go, there is an
argument to be made that we should change the LUA integration even if it
breaks compatibility with existing scripts (though obviously I did not
take that approach).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
src/frontend/mame/ui/moptions.h (#5282)
* Changed the various usages of UI_*COLOR to be calls to
src/frontend/mame/ui/moptions.h
The various UI_*COLOR macros were implemented as calls to
decode_ui_color, which cached the values for the various options in a
static array, which was obviously a gross hack.
This refactoring is strategic because I am trying to confine awareness
of mame_ui_manager to code in src/frontend/mame/ui, and the
implementation of decode_ui_color() relied on the ability to access
mame_ui_manager as a singleton from outside this code.
* Created a ui_colors object, so that queries for UI RGB values would not
always require parsing strings
* Converted a few more options().zyx_color() to colors().zyx_color()
* A few more misses from earlier
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
emu.thread()
machine:popmessage()
watch/breakpoints
debugger presence note
val for write functions
input:seq_poll*
fix typo in memory_share library
emu.register_callback(callback, name) still TODO
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Any users of that need to change :targets()[ to .targets[
|
| |
|
|
|
|
| |
improve comment wording
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A standard memory handler has as a prototype (where uX = u8, u16, u32 or u64):
uX device::read(address_space &space, offs_t offset, uX mem_mask);
void device::write(address_space &space, offs_t offset, uX data, uX mem_mask);
We now allow simplified versions which are:
uX device::read(offs_t offset, uX mem_mask);
void device::write(offs_t offset, uX data, uX mem_mask);
uX device::read(offs_t offset);
void device::write(offs_t offset, uX data);
uX device::read();
void device::write(uX data);
Use them at will. Also consider
(DECLARE_)(READ|WRITE)(8|16|32|64)_MEMBER on the way out, use the
explicit prototypes.
Same for lambdas in the memory map, the parameters are now optional
following the same combinations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Eliminates the need for the horizontal/vertical/LCD/SVG layout files
* Screens can now have orientation and physical aspect ratio specified
* RASTER/VECTOR defaults to 4:3, LCD/SVG defaults to square pixels at config time
* System orientation is applied on top of screen orientation
Automatically generated single-screen views and orientation flags in XML
output now work correctly for systems with multiple screens in different
geometries/orientations, e.g. housemnq, rocnms, stepstag, or netmerc.
The "core rotation options" only interact with system orientation.
Allowing multi-screen systems to work well with one monitor per emulated
screen is a complex topic. System orientation also affects the GFX
viewer while screen orientation doesn't. The orientation displayed in
the system selection menu is from the system orientation.
Let me know if I've broken any systems or use cases.
Also, add save state support for std::array/C array nested to any depth.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* plugins/discord: discord presence plugin [Carl]
* plugins/discord: use domain sockets and pipes [Carl]
* winptty: fix connecting to existing socket (nw)
plugins/discord: show pause state (nw)
* plugins/discord: fix pause behavior (nw)
|
|
|
|
|
|
| |
does (nw)
pc9801: use correct video clock, fixes policenauts video speed (nw)
|
| |
|
|
|
|
|
|
| |
* Move around the debugger hooks to get a small but measurable performance increase
* Remove emucore from external tools
* Improve performance of DSP16 interpreter a little by generating six variants of execution loop
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
input port fields [Carl]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* direct_read_data is now a template which takes the address bus shift
as a parameter.
* address_space::direct<shift>() is now a template method that takes
the shift as a parameter and returns a pointer instead of a
reference
* the address to give to {read|write}_* on address_space or
direct_read_data is now the address one wants to access
Longer explanation:
Up until now, the {read|write}_* methods required the caller to give
the byte offset instead of the actual address. That's the same on
byte-addressing CPUs, e.g. the ones everyone knows, but it's different
on the word/long/quad addressing ones (tms, sharc, etc...) or the
bit-addressing one (tms340x0). Changing that required templatizing
the direct access interface on the bus addressing granularity,
historically called address bus shift. Also, since everybody was
taking the address of the reference returned by direct(), and
structurally didn't have much choice in the matter, it got changed to
return a pointer directly.
Longest historical explanation:
In a cpu core, the hottest memory access, by far, is the opcode
fetching. It's also an access with very good locality (doesn't move
much, tends to stay in the same rom/ram zone even when jumping around,
tends not to hit handlers), which makes efficient caching worthwhile
(as in, 30-50% faster core iirc on something like the 6502, but that
was 20 years ago and a number of things changed since then). In fact,
opcode fetching was, in the distant past, just an array lookup indexed
by pc on an offset pointer, which was updated on branches. It didn't
stay that way because more elaborate access is often needed (handlers,
banking with instructions crossing a bank...) but it still ends up with
a frontend of "if the address is still in the current range read from
pointer+address otherwise do the slowpath", e.g. two usually correctly
predicted branches plus the read most of the time.
Then the >8 bits cpus arrived. That was ok, it just required to do
the add to a u8 *, then convert to a u16/u32 * and do the read. At
the asm level, it was all identical except for the final read, and
read_byte/word/long being separate there was no test (and associated
overhead) added in the path.
Then the word-addressing CPUs arrived with, iirc, the tms cpus used in
atari games. They require, to read from the pointer, to shift the
address, either explicitely, or implicitely through indexing a u16 *.
There were three possibilities:
1- create a new read_* method for each size and granularity. That
amounts to a lot of copy/paste in the end, and functions with
identical prototypes so the compiler can't detect you're using the
wrong one.
2- put a variable shift in the read path. That was too expensive
especially since the most critical cpus are byte-addressing (68000 at
the time was the key). Having bit-adressing cpus which means the
shift can either be right or left depending on the variable makes
things even worse.
3- require the caller to do the shift himself when needed.
The last solution was chosen, and starting that day the address was a
byte offset and not the real address. Which is, actually, quite
surprising when writing a new cpu core or, worse, when using the
read/write methods from the driver code.
But since then, C++ happened. And, in particular, templates with
non-type parameters. Suddendly, solution 1 can be done without the
copy/paste and with different types allowing to detect (at runtime,
but systematically and at startup) if you got it wrong, while still
generating optimal code. So it was time to switch to that solution
and makes the address parameter sane again. Especially since it makes
mucking in the rest of the memory subsystem code a lot more
understandable.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Revert "Changes to debugger memory address translation"
This reverts commit bb0964f9a284b15851773f5428bd602ca01cc28b.
|
|
|
|
|
|
| |
- memory_translate now returns an address space number rather a boolean flag, permitting addresses in part of one space to map to an entirely different space. This is primarily intended to help MCUs which have blocks of internal memory that can be dynamically remapped, but may also allow for more accurate emulation of MMUs that drive multiple external address spaces, since the old limit of four address spaces per MAME device has been lifted.
- memory_translate has also been made a const method, in spite of a couple of badly behaved CPU cores that can't honestly treat it as one.
- The (read|write)_(byte|word|dword|qword|memory|opcode) accessors have been transferred from debugger_cpu to device_memory_interface, with somewhat modified arguments corresponding to the translate function it calls through to if requested.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
[Carl]
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|