If the input is a signaling NaN, then we need to signal that via setting
the FPSCR.VXSNAN bit. We also shouldn't update the FPRF flags if
FPSCR.VE is set.
If the FPSCR.VE bit is set and an invalid operand is passed in, then the FPRF
shouldn't be updated. Similarly this is also the case when the FPSCR.ZE bit
is set and negative or positive zero is passed in as the operand.
If FPSCR.ZE is set and a divide by zero exception is signaled, then the
FPRF shouldn't be updated with a result. Similarly, if the input is an
SNaN and FPSCR.VE is set, then the FPRF shouldn't be updated.
The VX bit is intended to be a summary bit indicating the occurrence of
any kind of invalid operation. Therefore, whenever an invalid operation
exception is set, also set VX.
This corrects our CR flag setting for multiple instructions in certain
scenarios. This corrects flag setting cases in fadd, fadds, fctiw, fctiwz, fdiv,
frsp, frsqrte, fsub, and fsubs (and technically every floating-point
instruction that we make more accurate in the future with regards to
flag setting).
This ports the Wii filesystem root, Wii SD card path and dump path
settings to the new config system (OnionConfig).
My initial plan was to wait until DolphinWX was removed before porting
most of the Main (Core, DSP, General) settings to onion config, but
I've decided to submit a small part of those changes to fix
[issue 10566](https://bugs.dolphin-emu.org/issues/10566).
Removes the need to manually set the FileUtil path in the UI frontends
and gets rid of some more members that don't really belong in SConfig.
Also fixes a bug which would cause the dump path not to get created
after change.
Only invoke config changed callbacks from Config::Save, not
Layer::Save. The latter results in callbacks being called
once per layer, up to 7 times per save.
These disc images are only used on dev units and not retail units.
There are two important differences compared to normal Wii disc images:
- The data starts 0x8000 bytes into each partition instead of 0x20000
- The data of a partition is stored unencrypted and contains no hashes
Our old implementation was just guesswork and doesn't work at all.
According to testing by GerbilSoft, this commit's implementation
is able to read and extract files in the filesystem correctly,
but the tested game still isn't able to boot. (It's thanks to their
info about unencrypted disc images that I was able to make this commit.)
Initialising Wii filesystem contents should be done after Boot and
not in HW to ensure that we operate with the correct title context
and to make sure required title directories exist (so that Movie and
Netplay code can copy data from and to the temporary NAND).
Previously, given cases such as 0x80000000 / 0xFFFFFFFF we'd incorrectly
set the destination register value to zero. If the dividend is negative,
then the destination should be set to -1 (0xFFFFFFFF), however if the
dividend is positive, then the destination should be set to 0.
Note that the 750CL documents state that:
"If an attempt is made to perform either of the divisions --
0x80000000 / -1 or <anything> / 0, then the contents of rD are
undefined, as are the contents of the LT, GT, and EQ bits of the CR0
field (if Rc = 1). In this case, if OE = 1 then OV is set."
So this is a particular behavior of the hardware itself.
D3D11 cannot handle block compressed textures where the first mip level
is not a multiple of the block size. The simple fix for texture pack
authors: leave these textures uncompressed. You can still use a .dds
container.
Executing a supervisor-level instruction in user mode is supposed to
cause a program exception to occur.
The following supervisor instructions are present:
- dcbi
- mfmsr
- mfspr
- mfsr
- mfsrin
- mtmsr
- mtspr
- mtsr
- mtsrin
- rfi
- tlbie
- tlbsync
In 0337ca116a checks within mfspr and
mtspr were added. This change adds the trivial checks to the other
instructions.
Using 8-bit integer math here lead to precision loss for depth copies,
which broke various effects in games, e.g. lens flare in MK:DD.
It's unlikely the console implements this as a floating-point multiply
(fixed-point perhaps), but since we have the float round trip in our
EFB2RAM shaders anyway, it's not going to make things any worse. If we
do rewrite our shaders to use integer math completely, then it might be
worth switching this conversion back to integers.
However, the range of the values (format) should be known, or we should
expand all values out to 24-bits first.
Lioncash