GCMemcard.h has quite a bit of different classes implemented within it
that could likely be split up into other files to make it a little
easier to read. However, they should be moved into their own folder
first so that they don't clutter up the base HW directory.
ES.cpp was becoming pretty huge. This commit splits the ES code into
several files:
* Main ES (launch, UID, current title directory and title ID, etc.)
* Device identity and encryption (ID and cert, keys, encrypt/decrypt)
* Title management (imports, exports, deletions)
* Title contents (open/close/read/seek)
* Title information (titles, stored contents, TMDs)
* Views (for tickets and TMDs)
instruction tables
Previously, all of the internals that handled how the instruction tables
are initialized were exposed externally. However, this can all be made
private to each CPU backend.
If each backend has an Init() function, then this is where the instruction
tables should be initialized, it shouldn't be the responsibility of
external code to ensure internal validity.
This allows for getting rid of all the table initialization shenanigans
within JitInterface and PPCTables.
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.
This reimplements the USB HID v4 IOS device using the new common
USB code (to reuse more code and allow emulated HIDs to be added
more easily in the future).
The main difference is that HIDs now have to be whitelisted, like
every other USB device for OH0 and VEN.
The Host class will be used by the OH0, VEN and HID implementations
as the base class for the IOS HLE device. It handles scanning devices,
detecting device changes and everything that will be needed for OH0,
VEN and HID to be implemented, while mostly abstracting libusb away.
The Device class is for actual USB devices. This commit adds a
LibusbDevice which interacts with a real USB device and enables
USB passthrough.
Some structures will be reused and shared between several IOS USB
device implementations. This prepares for the upcoming USB PR.
I've also removed GetPointer calls in the trivial case (BT passthrough)
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.
The current implementations do many things wrong but work well enough to
run the Dragon Quest X installer until the very end. The game itself
crashes when being launched from its System Menu channel unfortunately
so it is hard to verify whether the install properly worked or not.
There are plenty of "TODO(wfs)" sprinkled around this codebase with
things that are knowingly done wrong. The most important one right now
is that content extraction is done by buffering everything into memory
instead of properly streaming the data to disk (and processing
asynchronously), which causes freezes. It is likely to not cause any
practical issues since only the installer and the updater should use
this anyway.
This library implements basic parsing support for some of the IOS ES
formats we need to extract data from. Currently only implements TMD
functions, but some ticket handling functions from DiscIO should likely
be moved here in the future.
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.)
This is actually used as the DSP JIT, so this should be with the other JIT
source files.
This commit also makes it so changes to the JIT emitter don't require
recompiling all of the DSP core (i.e. changing the JIT won't require the
interpreter to be rebuilt).
Much of Jit64Util consists of essentials, not utilities. Breaking these
out into their own files also prevents unrelated includes from being
present near other classes.
This also makes it easier to find and change certain components of the
x86-64 JIT, should it be necessary.
I know there is already #3521, but it currently needs a rebase and I
needed to add something to IPC_HLE_Device properly, that is, without
putting everything in the header, so this commit cleans up
IPC_HLE_Device first. (And only IPC_HLE_Device: the rest will still
be handled by #3521.)
Also fixes a few indirect includes (removing unused header includes
from IPC_HLE_Device.h broke building)
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
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).
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.
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).
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.
The Wii U Gamecube controller adapter setup has always been a bit weird. It tries to be as automatic as possible to make the user experience as easy
as possible.
The problem with this approach is that it brings a large disconnect in the user experience because you have the Gamecube controller setup with regular
gamepads and then for some reason below that you have a "direct connect" option which will cause the Gamecube Adapter to overwrite the regular inputs
if something was connected.
While this works and allows the user to only click one checkbox to get the device working, it breaks the user's experience because they don't really
know what "direct connect" means and won't look it up to figure out what it is. Just expecting the device to work (At least one occurence of this in
the IRC channel in the last week).
This way around also had the terrible nature of making the code more filthy than it needed to be. The GCAdapter namespace was parasitic and hooked in
to the regular GC Controller SI class to overwrite the data that it was getting from the default configuration.
Now instead we have a specific SIDevice class for the Wii U Gamecube adapter. This class is fairly simple and is a child of the regular SI Gamecube
Pad device and only reimplements what it needs to.
This also gives the ability to configure controllers individually, which allows the user to configure rumble individually per pad input.
Overall the code is cleaner, and it fits more in line with how the rest of Dolphin works.
