Emulator

Btw, those two lines were a fix for Sonic Unleashed, I think.

Sorry, I meant those two lines. Yeah, I know that, since I checked the rev almost one
by one. lol
Tried to change the code, but got an error instead.
Changing 0x3800000000000000ULL to 0x8000000000000000ULL, and the game crashed in the
opening movie. :P

Changing 0x8000000000000000ULL to 0x7ff0000000000000ULL solved the problem on
ToS:DotNW (at least it will pass the memory card loop screen)
Wondering how it is on Sonic Unleashed....

Edited wrong one :P

Hmm we need someone with Sonic Unleashed to test it out :P

all of those lines should be deleted - not only do they flush numbers to zero when
the original console doesn't, it flushes the arguments to zero - not the destination.
It's surprising that it works at all.

A better fix for sonic unleashed would be to look at the "non-IEEE" bit of the FPSCR
(FPSCR.NI). when that's enabled, dolphin should enable flush to zero (and
denormals-are-zero, if supported by the PC). Otherwise - dolphin should disable it.

I think there are traces of this being once done (incorrectly, maybe?), but anyway -
it is correct and if beyond good & evil has issues when the NI bit is emulated, then
this is the bug that should be figured out.

Agreed, itsnotmailmail.

I had this semi-done for a while. I should give it another shot and as you say,
investigate Beyond Good & Evil.

As a side note, I've been trying to get F-Zero to work by making the FPU emulation
more accurate but haven't gotten much closer. Removing these hacks doesn't help. I
can get the ship to stop falling through the floor by forcing division by 0 to 0
instead of inf (which I've verified is a wrong thing to do), but it still won't move.

Well one thing I noticed is that frsqrte isn't emulated correctly.

If the argument is strictly negative, it should return a QNAN (with a VXSQRT exception)
If it is a zero, it should return infinity or a clamped value (no idea which,
certainly not zero, though.) as well as set the VX exception.

Also, there's a bug in fdiv: FB may be the same as FD and then the wrong value is
checked for zero.

And the bug in fdiv(x) also exists in fres(x)

If FB == FD, surely it doesn't matter which one is checked for zero? it'll be a
zero/zero = NaN either way ..

You're completely right about the issues with frsqrte - I'll fix that tonight unless
you do it first.

of course it matters. if FA contains 0, FB contains 1 and FD == FB, then ZX will be
set even though no division by zero occured.

This bug also exists in ps_rsqrte and ps_div.

Eh oops. Mixed the regs together. Will fix.

I've improved all the div/sqrt-ish instructions.

No improvement in F-Zero...

To simulate GC denormals behaviour, I think DAZ is the one we need, not FTZ. But either
or both of those break Beyond Good & Evil and I can't figure out why...

1. Gekko uses both FTZ and DAZ when NI is on, says so in the manual (section 2.2.3)

2. The manual (same section) also seems to claim that when NI is on, convert to int
   instructions return 0x80000000 for all too-large floats (presumably instead of
   clamping). This looks a bit suspecious, though (at least to me). Has this been tested
   on the real hardware?

3. Beyond good and evil works when FTZ & DAZ are enabled for all instructions except
   load & store single-precision instructions. It is likely that those operate with
   FTZ/DAZ "off" regardless of the NI bit.

4. according to the comment after the little pseudo code in the same section,
   quantized load & store might zero denormals even if NI is off (Or it might just be a
   mistake)

5. according to section 2.3.4.3.12, NANs would be clamped the same as +Infs in
   quantized stores. (Dolphin doesn't seem to handle this)

4. actually, according to section 2.3.4.3.12, quantize loads denormals while quantize
   stores store a zero instead of a denormal.

Thank you, very nice observations, I'll try to implement them (and check that
suspicious one on real hw) later this week, unless you do it first (hint hint :)

Is it fixed now? Could someone check it?

no.. not fixed yet.. btw.. the rev im using is r4738

i tried with 4877, still no go, loops all the time ;) but interpreter works fine, i
just used that to bypass that problem ;)

Please respond if this issue is still valid, or it will be closed.