* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
I didn't know better back then, but the boot type is only supposed to
be used for the actual boot params. It shouldn't be used or changed
after booting.
This makes the interface slightly cleaner and a bit more consistent
with the other getters. Still not fully the same, since the others
don't really handle failures with std::optional; but at least the
value is returned by value now, as opposed to having the function
take a pointer to a u64.
This gets rid of some assumptions that non-DiscIO code was making about
volume types. It's better to encapsulate as many of the volume type
differences as possible in DiscIO.
Made possible by PR #2353.
Fixes https://bugs.dolphin-emu.org/issues/10265 (Star Wars: The Clone
Wars hangs on loading screen with DSP-HLE and JIT Recompiler).
The Clone Wars hangs upon initial boot if this interrupt happens too
quickly after submitting a command list. When played in DSP-LLE, the
interrupt lags by about 160,000 cycles, though any value greater than or
equal to 814 will work. In other games, the lag can be as small as 50,000
cycles (in Metroid Prime) and as large as 718,092 cycles (in Tales of
Symphonia!).
All credit to @hthh, who put in a heroic(!) amount of detective work and
discovered that The Clone Wars tracks a "AXCommandListCycles" variable
which matches the aforementioned 160,000 cycles. It's initialized to ~2500
cycles for a minimal, empty command list, so that should be a safe number
for pretty much anything a game does (*crosses fingers*).
This file is pretty small now that it doesn't handle Wii
partitions anymore, so let's move its contents to Volume.cpp.
This is also more consistent with how blob creation works.
By removing mutable state in VolumeWiiCrypted, this change makes
partition-related code simpler. It also gets rid of other ugly things,
like ISOProperties's "over 9000" loop that creates a list of
partitions by trying possible combinations, and DiscScrubber's
volume swapping that recreates the entire volume when it needs to
change partition.
- Makes DSP-LLE code checksums the same as those from DSP-HLE. I'm
assuming DSP-HLE was doing it correctly, since there are numerous
references to these pre-endian-swapped checksums (including in
DSPHost.cpp itself).
- Fixes disassembly when dumping code from DSP-LLE, which was using the
wrong endianness and giving totally bogus output.
- Reveals error messages of the format, "Bah! ReadAnnotatedAssembly
couldn't find the file ../../docs/DSP/DSP_UC_AX_07F88145.txt," which
seems to be intended behavior that was previously hidden.
This change centralizes all of the path handling and file writing logic
in DumpDSPCode. DSP-HLE also gains the feature of DSP-LLE to
automatically disassemble dumped code and write it to an accompanying
text file.
With the relocation of DumpDSPCode to DSPCodeUtils, the only remaining
function in DSPLLETools is DumpCWCode. This function 1) is not used
anywhere (not even in DSPTool), 2) doesn't seem to really do anything,
and 3) has a single comment saying "TODO make this useful :p"
For thread safety reasons, the currently inserted volume must
only be accessed by the DVD thread (or by the CPU thread if it
calls DVDThread::WaitUntilIdle() first). After this commit,
only DVDThread.cpp can access the volume, which prevents code in
other files from accessing the volume in a non-threadsafe way.
It's better to just let the calling code provide a volume
object instead of needing one SetVolume for each way of
creating a volume. This simplifies InsertDiscCallback and
is needed for the following commits.
This enables constructing an IOS instance that is not tied to emulation
and that can be simply used for internal purposes (ES, FS).
NAND root initialisation was moved to IOS since we cannot rely on HW
doing that for us anymore, and technically the NAND is entirely managed
by IOS anyway.
Since these button names are printed on all real controllers,
we should show them in the same way as they are printed on
the controllers, regardless of the user's language. It seems
like this was intended all along (except for "Start"), but the
_ markers in TASInputDlg.cpp (accidentally?) led to the button
names in the controller configs also becoming translatable.
I'm making exceptions for "L" and "R" because translators
may want to mark them in some way (for instance "L-Digital")
to clarify the difference from "L-Analog" and "R-Analog".
I'm also making an exception for START/PAUSE because it's
referred to as スタート in Japanese games.
I'm changing "Home" and "Start" to uppercase for consistency
with how Nintendo refers to those buttons, and because someone
who isn't familiar with the Latin script might not know the
connection between the lowercase and uppercase letters (most
users likely do know the connection, but we shouldn't assume it),
and because leaving "Start" as "Start" makes it "collide" with
unrelated strings, such as the string for the button that starts
a netplay session.
To rename "Start" and "Home" without breaking INI
compatibility, I added a ui_name variable like in f5c82ad.
This changes the main IOS code (roughly the equivalent of the kernel)
to a class instead of being a set of free functions + tons of static
variables.
The reason for this change is that keeping tons of static variables
like that prevents us from making an IOS instance and reusing IOS
code easily.
Converting the IOS code to a class also allows us to mostly decouple
IOS from the PPC emulation.
The more interesting changes are in Core/IOS/IOS. Everything else is
mostly just boring stuff required by this change...
* Because the devices themselves call back to the main IOS code
for various things (getting the current version, replying to a
request, and other syscall-like functions), just like processes in
IOS call kernel syscalls, we have to pass a reference to the kernel
to anything that uses IOS syscalls.
* Change DoState to save device names instead of device IDs to simplify
AddDevice() and get rid of an ugly static count.
* Change ES_Launch's ack to be sent at IOS boot, now that we can do
this properly.
Some strings were marked with _trans in some places but not
others. This commit adds extra _trans markers so that the
usage of _trans is consistent.
This shouldn't have any effect on which strings actually get
translated. (Note that _trans doesn't do anything at runtime.)
I also added a few new i18n comments.
