The recent IOS initialization changes caused the Bluetooth device to
no longer exist before "starting" IOS (as it should be…), which meant
that Core could not activate Wii remotes during the boot process
anymore.
But that is actually completely useless, because we can just have the
emulated Bluetooth code itself activate Wii remotes as appropriate,
at the right moment.
This implements MIOS's PPC bootstrapping functionality, which enables
users to start a GameCube game from the Wii System Menu.
Because we aren't doing Starlet LLE (and don't have a boot1), we can
just jump to MIOS when the emulated software does an ES_LAUNCH or uses
ioctlv 0x25 to launch BC.
Note that the process is more complex on a real Wii and goes through
several more steps before getting to MIOS:
* The System Menu detects a GameCube disc and launches BC (1-100)
instead of the game. [Dolphin does this too.]
* BC, which is reportedly very similar to boot1, lowers the Hollywood
clock speed to the Flipper's and then launches boot2.
* boot2 sees the lowered clock speed and launches MIOS (1-101) instead
of the System Menu.
MIOS runs instead of IOS in GC mode and has an embedded GC IPL (which
is the code actually responsible for loading the disc game) and a PPC
bootstrap code. To get things working properly, we simply need to load
both to memory, then jump to the bootstrap code at 0x3400.
Obviously, because of the way this works, a real MIOS is required.
It held a raw pointer to a IOS::HLE::Device::BluetoothEmu that is not
guaranteed to exist (and of course, nothing checked that it wasn't
nullptr), but what is more, it's totally unnecessary because we have
IOS::HLE::GetDeviceByName().
Since we cannot always inform the host that Wii remotes are
disconnected from ES, that is now done in BluetoothEmu's destructor.
IPC_HLE is actually IOS HLE. The actual IPC emulation is not in
IPC_HLE, but in HW/WII_IPC.cpp. So calling IPC_HLE IOS is more
accurate. (If IOS LLE gets ever implemented, it'll likely be at
a lower level -- Starlet LLE.)
This also totally gets rid of the IPC_HLE prefix in file names, and
moves some source files to their own subdirectories to make the file
hierarchy cleaner.
We're going to get ~14 additional source files with the USB PR,
and this is really needed to keep things from becoming a total pain.
Dolphin is able to generate one with all correct default settings, so
we don't need to ship with a pre-generated SYSCONF and worry about
syncing default settings.
Additionally, this commit changes SysConf to work with session SYSCONFs
so that Dolphin is able to generate a default one even for Movie/TAS.
Which SYSCONF needs to be touched is explicitly specified to avoid
confusion about which file SysConf is managing.
(Another notable change is that the Wii root functions are moved into
Core to prevent Common from depending on Core.)
Makes for a cleaner separation of functionality, as well as removing
multiple includes from the main header file. It also gets a bunch of
structs and enums out of the global namespace.
Coincidentally, this also gets rid of an indirect include cycle that
could have broken compilation of Core.cpp in the future, since it was
relying on IPC network includes to resolve functions in Common/NandPaths.h.
This makes it easier to separate out the individual net classes in a
follow-up. Separating these out would also make it less of a pain to
figure out what's going on, since you wouldn't need to sift through 1000+
lines of code.i
Currently, `g_controller_interface` is initialized and shut down by each
of `GCKeyboard`, `GCPad`, `Wiimote`, and `HotkeyManager`.
This 1) is weird conceptually, because it necessitates passing a pointer
to the native window to each of those classes, which don't need it, and
2) can cause issues when controller backends are initialized or shutdown
multiple times in succession.
Instead of directly reading/storing settings from/to the SYSCONF, we
now store Wii settings to Dolphin's own configuration, and apply them
on boot. This prevents issues with settings not being saved, being
overridden and lost (if the user opens a dialog that writes to the
SYSCONF while a game is running).
This also fixes restoring settings from the config cache after a
graceful shutdown; for some reason, settings were only restored
after a normal shutdown.
Fixes issue 9825 and 9826
Some OSD messages were displayed in RenderBase.cpp using global variables and some code duplicated
in OnScreeDisplay.cpp.
Now all messages are displayed using functions in the OSD namepace.
* OSDChoice and OSDTime global variables are gone
* All OSD logic is kept at the same place
* All messages are properly aligned
* Clean characters for all OSD messages
Original commit:
commit f0ec61c057
Author: Aestek <thib.gilles@gmail.com>
Date: Sun Aug 7 16:08:41 2016 +0200
This adds the ability to passthrough a whole Bluetooth adapter and skip
the majority of the Bluetooth emulation code. We use libusb to send HCI
commands, receive HCI events and transfer ACL data directly to the
first adapter that is found or to a specific adapter (if configured to)
This is possible because the Wii's Bluetooth module is actually just
a pretty standard Bluetooth adapter…
…except for two vendor-specific commands, for which replies are faked,
and also for the sync button. This adds a hotkey that works in the
exact same way as the sync button would on a Wii: it triggers an HCI
event, which emulated software interpret as a command to perform
a BT inquiry.
This commit also changes the UI code to expose passthrough mode
and WII_IPC_HLE to be a bit more thread safe (for the device map).
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.
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.
This changes Refresh() to use the existing scanning thread to scan for
devices, instead of running the scan on the UI thread and blocking it.
Also makes the UI thread not block when Continuous Scanning is disabled
and removes duplicated code.
Should fix issue 8992.
Under the hood:
* The scanning thread is now always active, even when continuous
scanning is disabled.
* The initialize code which waits for Wiimotes to be connected also
uses the scanning thread instead of scanning on yet another thread.
* The scanning thread now always checks for disconnected devices, to
avoid Dolphin thinking a Wiimote is still connected when it isn't. So
we now check if we need new Wiimotes or a Balance Board at scan time.
Fully opt-in, reports to analytics.dolphin-emu.org over SSL. Collects system
information and settings at Dolphin start time and game start time.
UI not implemented yet, so users are required to opt in through config editing.
EndPlayInput runs on the CPU thread so it can't directly call
UpdateWantDeterminism. PlayController also tries to ChangeDisc
from the CPU Thread which is also invalid. It now just pauses
execution and posts a request to the Host to fix it instead.
The Core itself also did dodgy things like PauseAndLock-ing
from the CPU Thread and SetState from EmuThread which have been
removed.
Fix Frame Advance and FifoPlayer pause/unpause/stop.
CPU::EnableStepping is not atomic but is called from multiple threads
which races and leaves the system in a random state; also instruction
stepping was unstable, m_StepEvent had an almost random value because
of the dual purpose it served which could cause races where CPU::Run
would SingleStep when it was supposed to be sleeping.
FifoPlayer never FinishStateMove()d which was causing it to deadlock.
Rather than partially reimplementing CPU::Run, just use CPUCoreBase
and then call CPU::Run(). More DRY and less likely to have weird bugs
specific to the player (i.e the previous freezing on pause/stop).
Refactor PowerPC::state into CPU since it manages the state of the
CPU Thread which is controlled by CPU, not PowerPC. This simplifies
the architecture somewhat and eliminates races that can be caused by
calling PowerPC state functions directly instead of using CPU's
(because they bypassed the EnableStepping lock).
CBoot::BootUp() did call CoreTiming::Advance which itself blocks on the GPU,
but the GPU thread wasn't started already. This commit moves the SyncGPU
initialization into the Fifo.cpp file and call it after BootUp().
