Not initializing until the filesystem is used is good when
a filesystem is constructed and then never used, but nobody does that.
This simplifies the code a little and lets all methods be const.
Instead of using lots of small scattered reads to read the FST,
only one big read is used, which is more efficient.
This also means that the FST only allocates memory once and stores all
strings close to each other - good for the CPU cache. The file info
objects use pointers to this FST memory of containing data themselves.
Keeping around the big m_FileInfoVector containing objects with only
pointers is a bit unnecessary, but that will be fixed soon.
Instead of calling GetPathFromFSTOffset for every file info, FindFileInfo
now only looks at names in directories that are included in the path.
For the common case of searching for "opening.bnr", this means that
only root-level files and directories have to be searched through.
Some callers already have the file info, making the relatively slow
FindFileInfo calls unnecessary. Callers that didn't have the file info
will now need to call FindFileInfo on their own.
Some callers (i.e. ISOProperties) don't want the full path, so giving them
it is unnecessary. Those that do want it can use GetPathFromFSTOffset.
Not storing full paths everywhere also saves a small bit of RAM and is
necessary for a later commit. The code isn't especially pretty right now
(callers need to use FST offsets...) but it'll become better later.
GC/Wii filesystem internals shouldn't be exposed to other classes.
This change isn't especially useful by itself, but it opens up the
way for some neat stuff in the following commits.
Too much boilerplate that is duplicated if we use curl directly.
Let's add a simple wrapper class that hides the implementation details
and just allows to simply make HTTP requests and get responses.
Makes it slightly less likely to forget a check and end up doing an
out-of-bounds access. Also makes it obvious that we *are* indeed
checking whether the handle is valid, instead of hiding it in
HasOwnership (which won't handle the root key handle case properly).
This code hadn't been touched since 2010. Nowadays, the panic alert
setting is loaded by ConfigManager and applied in UICommon.
VideoConfig has no business messing with it.
I don't see why we need to call ShutdownWiiRoot on InitializeWiiRoot.
Also, atexit? Really? Not only is this unnecessary, it will also cause
ShutdownWiiRoot to be called twice in rapid succession for no reason.
The config must only be restored after the HW has shut down, not while
it is still running, because the HW can still query the config, which
can lead to inconsistent states.
This fixes WiiRoot not being able to copy back saves on shutdown.
This ioctlv is used to get an IOSC decrypt handle for a title.
It is known to be used internally by the WFS modules, but it can also
be used from the PPC under some conditions.
Brings us down to 2 essentially unimplementable ioctlvs (syscalls which
seem to return kernel thread priorities...), and 1 known but
unimplemented ioctlv (VerifySign).
In the future, NAND filesystem access will be limited to one IOS
instance, for safety reasons and to make it possible to consider
supporting NAND images. This means that any code accessing the NAND
filesystem must go through the FS device, both for code that is
external to IOS and internal.
Because we don't want to introduce any singleton, this requires
internal IOS code that needs NAND access to be part of an IOS device
class, so they can access the FS device easily.
Making some of the internal ES implementation functions member
functions also prevents them from being (mis)used outside of IOS,
since they cannot be called everywhere anymore.
OpenALStream was querying the backend for AL_EXT_float32 support (which
suceeds), but AL_FORMAT_STEREO_FLOAT32 was defined incorrectly.
Also changes OpenALStream to query for AL_EXT_MCFORMATS (multichannel
support) rather than hard-coding that it doesn't work on macOS.
They have been broken since 2 years and no one has noticed,
which shows that no one really cares.
And it's arguable whether showing the CPU info is really useful.
I don't see any reason to disable loading the IPL if bHLE_BS2 is
disabled. bHLE_BS2 should only cause us not to run the IPL, but not
skip loading it in the first place. More importantly, without always
loading it, this causes issues when trying to launch only the GC IPL
while having bHLE_BS2 = false.
They're essentially the same. To achieve this, this commit unifies
DolReader and ElfReader into a common interface for boot executable
readers, so the only remaining difference between ELF and DOL is
how which volume is inserted.
* 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.
- Moves all test code from DSPTool into UnitTests/Core/DSPAssemblyTest.
- Converts test files (which could only be loaded if they were in the
shell's working directory, so basically never) into C++ values.
- Enables most of the commented-out tests.
- Removes non-deterministic random code test.
Disassemble code without the additional text for humans, like the
current PC and opcode hex values, so that it can be reassembled.
I'm not updating any commented-out tests here.
You may want to read the PR #2047 comments before reading this.
Dolphin attempts to support an unencrypted type of Wii discs
that apparently is identified by a 4-byte integer at 0x60
being non-zero. I don't know what discs (if any) would be
using that format, so I haven't been able to test Dolphin's
support for it, but it has probably been broken for a while.
The old implementation is very short but also strange.
In CreateVolumeFromFilename, we read a 4-byte integer from
0x60, and if it's non-zero, we create a CVolumeGC object
instead of a CVolumeWiiCrypted object. This might seem like
it makes no sense, but it presumably worked in the past
because IsVolumeWiiDisc used to check the volume type by
reading the magic word for Wii straight from the disc,
meaning that CVolumeGC objects representing unencrypted Wii
discs would be treated as Wii discs by pretty much all of
Dolphin's code except for the volume implementation code.
(It wasn't possible to simply use CVolumeWiiCrypted, because
that class only handled encrypted discs, like the name says.)
However, that stopped working as intended because of ace0607.
And furthermore, bb93336 made it even more broken by making
parts of Dolphin expect that data read from Wii discs needed
to be decrypted (rather than the volume implementation
implicitly deciding whether to decrypt when Read was called).
Disclaimer: Like I said before, I haven't been able to test
any of this because I don't have any discs that use this
unencrypted Wii disc format, so this is all theoretical.
Later, PR #2047 tried to remove Dolphin's support for
the unencrypted Wii disc format because seemingly no
discs used it, but the PR got closed without being merged.
At the end of that PR, I said that I would make a new PR
with a better implementation for the format after PR #2353
was merged. Now that PR #2353 is merged (two years later...)
and PR #5521 is merged, the new implementation was easy to
make, and here it is!
Untested.
Normal users don't care about it. In fact, people care so
little about it that the Wii implementation of it was broken
starting from when it was implemented (eb65601) to 7 years
later (e0a47c1), apparently without anyone reporting it.
- coef: Explicitly set 23 different values that are used by GBA UCode,
and tweaked overall parameters to more closely match those 23 values.
- irom: Moved a few functions to their proper places, updated BootUCode
to configure DMA transfers using AX registers as well as IX registers
(the GBA UCode uses this to do two sequential transfers in one call),
and added partial functions used by GBA UCode.
All functions were reverse-engineered solely based off of observed
effects on the virtual machine: register states before-and-after, dmem
interactions, and DMA transfers. The specific coefficients were observed
being read from dmem, and must be exactly those values to function
properly. I have no knowledge of how the official ROM implements these
functions, or how it is implemented overall.
Tested with The Legend of Zelda: Four Swords Adventures, Final Fantasy
Crystal Chronicles, and Billy Hatcher and the Giant Egg (to download
ChuChu Rocket!).
`P_REG1C` had the same value as `P_ACCL`, so was causing spurious errors
when used with ACCM registers. Gcdsptool (which calls this `P_ACCLM`)
gives it the value `P_REG | 0x1c10` instead, and handles errors in the
same block as other REG## enums.
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.
Starsam80