Same thing but allows both GeckoCode and Code to be utilized directly
without predicates for equality/inequality in stardard algorithms
The size check for std::vectors is unnecessary, as this is built into std::vector's operator==
Because of the way this works, randomly overwriting the handler
when loading a savestate will break things because of the
self-modifying nature of the handler.
GeckoCodes require address hooks which don't correspond to any
symbol in the symbol table. The hooks get deleted when repatching
the game because they did not persist across calls to
HLE::PatchFunctions.
Dolphin emulates GeckoCodes by fiddling with the CPU state when a
VI Interrupt occurs. The problem with this is that we don't know
where the PC is so it's non-deterministic and not necessarily
suitable for use with the codehandler.
There are two options: Patch the game like Gecko OS either directly
or using HLE::Patch, or use a trampoline so we can branch from any
PC even if it would otherwise not be valid. The problem with Gecko OS
patches is there are 10 of them and they have to be configured
manually (i.e. Game INIs to would need to have a [Core]GeckoHookType
property).
HLE_Misc::GeckoReturnTrampoline enables the Code Handler to be
entered from anywhere, the trampoline restores all the registers that
had to be secretly saved to the stack.
If the installation fails because codehandler.bin is missing or
unusable then Dolphin will try again every single frame even though
it's highly unlikely a disk file will have changed. Better to just
fail once then only try again when the active code set is changed.
Suppresses generating 60 log messages per second.
Turns out one of the magic numbers was very magic. The gameid is
an ad-hoc comm protocol with HLE_Misc to control the number of times
the ICache is reset.
The code table builder cuts off the end of codes that won't fit
after already writing part of it. That seems quite unlikely to
work the way anyone would find useful since the codes can contain
actual PPC instructions.
The active codes vector cannot safely be used outside the mutex,
move the lock out into RunCodeHandler. s_code_handler_installed was
also racing against SetActiveCodes since it's being written both
inside and outside the lock.
General cleanup. Add s_ prefixes, use constexpr, remove C casts.
Executing PPC code inside an external events callback is a bad idea.
CoreTiming::Advance does not support recursion properly which will
cause timing glitches. The interpreter has a slice length hack that
counters this but without it this would cause a 20000 cycles time
skip. It isn't clear what this was supposed to accomplish that just
changing the current PC would not. Changing the PC works fine.
When standby mode is enabled, this causes games to ES_Launch the system
menu instead of directly asking IOS (the STM more precisely) to shut
down, which prevents graceful shutdown from working
(it'll appear to hang).
Dolphin never supported WC24 standby mode anyway, so this shouldn't
cause any issues. (This should be reverted if and when WC24 standby is
implemented…)
This adds support for triggering the power event (in the STM), so that
stopping emulation first triggers a shutdown event, which notably gives
emulated software time to save game data (issue 8979) and clean up
SYSCONF (to disconnect Wiimotes and update their state in the SYSCONF).
On the first press, the stop button/hotkey/whatever will trigger a STM
power event. On a second try, we will forcefully stop emulation, just
like how it was working before.
There was as far as I know no reason to put everything in the header.
Separating the declaration from the implementation reduces build
times in case the implementation is updated without changing
any declaration.
It looks like the debug output is also output as SJIS (similar to
OSReport text), so we need to convert it to UTF-8 to prevent it from
all showing up as �.
This doesn't fix all display issues, but fixes all SJIS/UTF-8 related
ones.
This changes GetSymbolFromName to not require the passed name to
completely match with the symbol name. Instead, we now match
against the stripped symbol name (i.e. only the function name).
This fixes a regression introduced by #4160, which prevented
HLE::PatchFunctions() from working properly.
Call Advance at the start of each timing slice instead of the end.
Possibly fixed a bug where a slice would randomly branch straight
back to Advance() because the flags were not set to the right
values before branching to the dispatcher entrypoint.
This fix a double break bug when hitting a memcheck and hitting play on the same instruction it broke to earlier. The state is put back to CPU_RUNNING after.
These are needed for the next commit. I had to modify the implementation of the DSP one too, but since it basically isn`t used, I don`t think it matters much. These options only matters when adding one.
It wouldn't impact performance until at least one memcheck is enabled. Because of this, it can be used in release builds without much impact, the only thing that woudl change is the use of HasAny method instead of preprocessor conditionals. Since the perforamnce decrease comes right when the first memcheck is added and restored when the last is removed, it basically is all beneficial and works the same way.
The min-heap provides no ordering when the key is the same on 2
nodes. Disambiguate identical times by tracking the order items
were added into the queue.
Now that our timings are much more accurate it doesn't look like we
need it anymore. And the instant ARAM DMA mode + scheduling fixes
ctually breaks ATV: Quad Power Racing 2 (causing all sorts of werid
bugs).
Fundamentally, all this does is enforce the invariant that we always
translate effective addresses based on the current BAT registers and
page table before we do anything else with them.
This change can be logically divided into three parts. The first part is
creating a table to represent the current BAT state, and keeping it up to
date (PowerPC::IBATUpdated, PowerPC::DBATUpdated, etc.). This does
nothing by itself, but it's necessary for the other parts.
The second part (mostly in MMU.cpp) is simply removing all the hardcoded
checks for specific untranslated addresses, and consistently translating
addresses using the current BAT configuration. Very straightforward, but a
lot of code changes because we hardcoded assumptions all over the place.
The third part (mostly in Memmap.cpp) is making the fastmem arena reflect
the current BAT configuration. We do this by redoing the mapping (calling
memmap()) based on the BAT table whenever it changes.
One additional minor change is that translation can fail in two ways:
either the segment is a direct store segment, or page table lookup failed.
The difference doesn't usually matter, but the difference affects cache
instructions, like dcbz.
For step over, it was updating twice which actually made the red display on the register view (when a register changes since) malfunction. Since it doesn't seem to be usefull to update before AND after the run, the one before the run was removed.
For step out, well, because there was no chances given for the thread to run as it is single stepping all the time, I only added a call to update after it was done.
Init cannot be called more than once because it registers the
CoreTiming callbacks, that trips the assertions and will cause
anyone with PanicAlerts disabled to crash.
CoreTiming gets restored before ExpansionInterface so CoreTiming
events need to already be registered before the save state loading
begins. This means that the callbacks must be registered
unconditionally instead of on-demand.
Replace adhoc linked list with a priority heap. Performance
characteristics are mostly the same, but is more cache friendly.
[Priority Queues have O(log n) push/pop compared to the linked
list's O(n) push/O(1) pop but the queue is not big enough for
that to matter, so linear is faster over linked. Very slight gains
when framelimit is unlimited (Wind Waker), 1900% -> 1950%]
When n was a multiple of 4, the old implementation would overwrite
the following register with 0.
This was causing Not64 to crash.
Thanks to Extrems for spotting this.
DVDInterface shouldn't need to know anything about
the DTM format's 40-character limitation.
Also replacing "filename" in variable names with "path"
to make it clearer which variables contain the whole path
and which ones only contain the filename.
This introduces speculative constants, allowing FIFO writes to be
optimized in more places.
It also clarifies the guarantees of the FIFO optimization, changing
the location of some of the checks and potentially avoiding redundant
checks.
I'm not sure this is the correct fix, but it looks like OSREPORT output
is Shift-JIS, so we need to convert it to UTF-8. Most characters work
fine without and with this conversion, but Japanese text completely
fails and results in outputting invalid UTF-8 (which gets shown as �).
When 5.0-211 updated wxWidgets to 3.1.0, some entries in the
wxLanguage enum were moved and added, changing the wxLanguage
values. Because we save Dolphin's interface language to disk
as a wxLanguage, the language you have set will mean something
different depending on whether you have the updated wx version
or not. For instance, setting the language to English with the
updated version and then using an older version will make
Dolphin use Dutch. Because we can't rely on the enum anymore,
I'm replacing the "Language" setting with a "LanguageCode"
setting that uses standard ISO 639 codes.
The gather pipe optimization postpones checking the FIFO until the end
of the current block (or 32 bytes have been written). This is usually
safe, but is not correct across EIEIO instructions.
This is inferred from a block in NBA2K11 which synchronizes the FIFO
by writing a byte to it, executing eieio, and checking if PI_FIFO_WPTR
has changed. This is not currently an issue, but will become an issue
if the gather pipe optimization is applied to more stores.
Let's stop pretending that we support Triforce emulation.
Keeping this code around just in case someone will make
major improvements in the future isn't really worth it.
I'm keeping the Triforce game INIs so users will know that
the compatibility rating for Triforce games is 1 star (broken).
OSD messages other than these one and a half aren't translated,
and OSD only supports ASCII. (Also, that "Wiimote %i %s" uses %s
like it does is bad for translation, but that's easy to fix.)
These operations should always take the same amount of time,
not the same amount of ticks. The number of ticks per second
is different for GameCube and Wii.
Replaces old and simple usages of std::atomic<bool> with Common::Flag
(which was introduced after the initial usage), so it's clear that
the variable is a flag and because Common::Flag is well tested.
This also replaces the ready logic in WiimoteReal with Common::Event
since it was basically just unnecessarily reimplementing Common::Event.
Specifically, don't make any assumptions about what effective addresses
are used for code, and correctly handle changes to MSR.DR/MSR.IR.
(Split off from dynamic-bat.)
Also fold the check in both functionss into 'slowmem' rather than having
a separate test. (jo.alwaysUseMemFuncs implies jo.memcheck anyway, as
makes sense.)
This adds RemoveDevice() to ControllerInterface, fixes ExpressionParser
and some other code to support device removals without crashing,
and adds an IsValid() method to Device, to prepare for hotplugging.
This adds RegisterHotplugCallback() to register a callback which will
be invoked by the input backends' hotplug threads when there is a new
device, so that Core (GCKeyboard, GCPad, Wiimote, Hotkey) can reload
the configuration without adding a dependency to Core from InputCommon.
Since we now support different scanner sources, g_wiimotes is not
guaranteed to only contain WiimoteLinux anymore.
This replaces the previous "already connected" check with one that
doesn't use g_wiimotes.
Instead of sleeping in NetPlayClient::GetNetPads and NetPlayClient::WiimoteUpdate,
now use std::condition_variable. This allows for finer control over these blocking
areas.
This makes WiimoteScanner support several scanner backends.
This adds a WiimoteScannerBackend base class, which scanner backends
derive from, and which allows backend-specific things to be moved out
of the common code.
Also removes IODummy which is not needed anymore.
* Focus "Hash Code" / "IP address" text box by default in "Connect"
* Focus game list in "Host" tab
* RETURN keypress now host/join depending on selected tab
* Remember last hosted game
* Remove PanicAlertT:
* Simply log message to netplay window
* Remove them when they are useless
* Show some netplay message in OSD
* Chat messages
* Pad buffer changes
* Desync alerts
* Stop the game consistently when another player disconnects / crashes
* Prettify chat textbox
* Log netplay ping to OSD
Join scenario:
* Copy netplay code
* Open netplay
* Paste code
* Press enter
Host scenario:
* Open netplay
* Go to host tab
* Press enter
UPNP_AddPortMapping needs our IP address, however enet_address_get_host
will return 0.0.0.0 or a host name in most cases.
This gets our IP address from the socket to the IGD.
5.0-56 broke reconnecting a Wiimote on button press; this is because
data reporting was now always stopped for real Wii remotes on
disconnect, making it impossible to know a button was pressed in the
first place (to reconnect the Wiimote).
This semi-reverts to the previous behaviour, where data reporting is
never stopped.
(Also, control channels now go through WiimoteEmu, just like before,
to make sure some things are reset on disconnection.)
Hopefully fixes issue 9711.
This fixes warnings in:
- Source/Core/InputCommon/ControllerEmu.h: avoid shadowing other
variables (my fault)
- Source/Core/Core/IPC_HLE/WII_IPC_HLE.h: made
SDIO_EventNotify_CPUThread static as it's not used anywhere else
POSIX specifies that inet_ntoa() is declared in arpa/inet.h, and that
POLLRDNORM, etc. are defined in poll.h.
gethostbyname() is not specified by POSIX, but the manpages in OpenBSD,
FreeBSD, OS X, and glibc all state that it is declared in netdb.h.
Without these headers, the build fails on OpenBSD and possibly other
systems.
The old implementation always polled the local 1st Wiimote and used that as input for the Wiimote that is mapped to the player. But the reporting mode for Wiimotes can be different, even when using the same extensions. So an input for Wiimote 1 with a data size 4 could be used for Wiimote 2, which actually requires data size 7 at that time for example.
The 2nd problem was that the code added a dummy input into the buffer, when the reporting mode changed. But when the data from the other player hasn't arrived yet, the data in the buffer is out of order. Well, i think this is the problem, i'm not 100% sure, because i don't fully understand how the buffer works. But on the other hand, i'm pretty sure this will just force sync the players on reporting mode changes, instead of allowing them to be apart.
Pros:
- No more desyncs caused by big bugs in the code.
- Can use different extensions for different players.
Cons:
- Higher latency, because instead of polling 1 controller per player at once, all controllers are polled in order, send to the other players, before the next is processed.
- Have to setup the Wiimote, which the player is going to use, instead of the 1st one.
Now, if the controller config could temporarily be overridden with the one from another slot, the 2nd problem could be fixed. But at the same time, we would lose the ability to use different extensions. (unless we hack around it somehow, or properly send the used extension to the other players)
Specifically, don't make any assumptions about what effective addresses
are used for code, and correctly handle changes to MSR.DR/MSR.IR.
(Split off from dynamic-bat.)
At first there weren't many enums in Volume.h, but the number has been
growing, and I'm planning to add one more for regions. To not make
Volume.h too large, and to avoid needing to include Volume.h in code
that doesn't use volume objects, I'm moving the enums to a new file.
I'm also turning them into enum classes while I'm at it.
