I found something that may be interesting (or not!)
In the ppc603e floating point division instructions fdivx and fdivsx, there are enormous amount of division by zero (second operand register fpr(b) = 0) in many games
I don't know why we have so many call to fdivx and fdivsx with operand ((a or b) or (a and b)) set to 0
bad dissassembling ?
so I introduce a little test for that
In magtruck we have in the attract demo cycle :
demo (ok) -> ranking screen (black screen for the scene actually) -> demo ocean (polygon bug actually) -> ranking screen ....
and with the detection of div by zero
demo (ok) -> ranking screen (depending of the result in register see code fdivsx) -> demo ocean (ok) -> ranking screen ....
- Code: Select all
static void ppc_fdivx(UINT32 op)
{
UINT32 b = RB;
UINT32 a = RA;
UINT32 t = RT;
CHECK_FPU_AVAILABLE();
SET_VXSNAN(FPR(a), FPR(b));
if (FPR(b).fd == 0.0)
{
FPR(t).fd = 0.0; // force result to zero
}
else
{
FPR(t).fd = FPR(a).fd / FPR(b).fd;
}
set_fprf(FPR(t));
if (RCBIT) {
SET_CR1();
}
}
- Code: Select all
static void ppc_fdivsx(UINT32 op)
{
UINT32 b = RB;
UINT32 a = RA;
UINT32 t = RT;
CHECK_FPU_AVAILABLE();
SET_VXSNAN(FPR(a), FPR(b));
if (FPR(b).fd == 0.0)
{
// if I force result fpr(t)=0 -> black screen on the ranking screen in magtruck
// if I don't put any result in register fpr(t) -> screen is blinking on the ranking screen magtruck
// if I force result fpr(t)=0.08 or 1 (or other value) -> we see the scene but deformed/zoomed (magtruck)
FPR(t).fd = 0.08;
}
else
{
FPR(t).fd = (float)(FPR(a).fd / FPR(b).fd);
}
set_fprf(FPR(t));
if( RCBIT ) {
SET_CR1();
}
}
May be someone can investigate more and better than I can do myself...
++
