Indiana Jones gfx issues in CPU core about project64

Does mtc0 opcode revert to 1964 0.8.5, the GFX seem to be fixed anyway?

[cxd4]

You suppose it may be an interpreter bug with MTC0 on the main CPU then?
Or I am simply not following.

[LegendOfDragoon]

Could be. 1964 0.85's code looks a lot different for that instruction. I'm very intrigued.

Yes I suppose a bug is in the MTC0 on main CPU.
I don't understand technical thing , but it seems there is a bug in The status register.

[project64]

why do you think it might be in MTC0?

[LegendOfDragoon]

@exhalatio probably studied emulator core code well. @project64 , you should take a look at 1964 0.85's source. You'll see that it implements that instruction quite differently.

[project64]

in what way did they handle it differently?

[AmbientMalice]

Filed a MTC0 error report for Supercross 2000 in LLE mode that might be relevant.

#104

FixFpuLocations have two Routines, if forced as 1st routine work well.
This game does not seem to hit the (STATUS_REGISTER & STATUS_FR) of == 0 conditions.

[AmbientMalice]

What about Battle for Naboo? Since both games seem to share the same bugs.

Yeah, Battle for Naboo also seems to work well.

[AmbientMalice]

The radar and skybox are broken. (Yes, I'm pointing out the obvious, but they work on other emus.)

Good work, anyway.

[LegendOfDragoon]

Pretty sure he's using Jabo 1.7.0.57 though :P .

@exhalatio , is that picture with default source or did you modify the source code? I never really played this game, other than checking to see if it boots with my RSP version.

[AmbientMalice]

Ah. Jabo. Its existence had momentarily slipped my mind.

I'm curious whether the environments flicker, and whether the game is stable in dynarec. (Since m64p has flickering problems and issues with dynarec.)

How soon can/will these changes be added to the source?

@LegendOfDragoon.@AmbientMalice It's little modify (cheats) the source code.
You will confirm in project64\Source\Project64\N64 System\Mips\Register Class.cpp

void CRegisters::FixFpuLocations ( void ) {
// if ((STATUS_REGISTER & STATUS_FR) == 0) {
for (int count = 0; count < 32; count ++) {
m_FPR_S[count] = &m_FPR[count >> 1].F[count & 1];
m_FPR_D[count] = &m_FPR[count >> 1].D;
}
// } else {
// for (int count = 0; count < 32; count ++) {
// m_FPR_S[count] = &m_FPR[count].F[1];
// m_FPR_D[count] = &m_FPR[count].D;
// }
// }
}

[LegendOfDragoon]

Nice. Thanks a lot! @exhalatio How did you figure this out?

Calling the FixFpuLocations from Status of mtc0.
The FixFpuLocations, There are two different methods.
I was forcibly how to handle in anticipation that there is a bug in one.
Surprisingly it has been fixed GFX.

[LegendOfDragoon]

Nice! That was very creative.

[cxd4]

So does this mean (STATUS_REGISTER & STATUS_FR) bit wasn't set when it was supposed to be?
Or it just means the } else { part (handling when STATUS_FR not set) just has a bug.

Because it appears most likely the former. STATUS_FR should have been set in this game but missed?

[AmbientMalice]

To everyone involved with this fix and fixes to come. To you, personally.

[AmbientMalice]

@exhalatio what's the plan when it comes to adding this fix to the source? In its current form, will it break anything? I've noticed some strange behavior in games where textures disappear when running in LLE mode using Ziggy's, but I haven't done enough testing using clean builds.

[project64]

when it comes to fixing this .. I want to write a test rom for the n64 and see if I can work out how it actually works on a real n64

I'll be send a Pull Request.
Thank you for waiting.

[cxd4]

That is a temporary fix, maybe for the short term. Commenting out the broken code doesn't fix the broken code, but it gets around it. Not saying this because as if the pull request is bad at all, just emphasizing this to folks that's all.

The actual behavior at that stage of the operation is still unknown. Maybe it's documented somewhere, but I'm really not a R4300 person, more a RSP person so don't know.

[project64]

until I know how the real n64 works I am not sure about the pull request, but keep it there is reminds me that it needs to get done and I am less likely to forget about it.

Yeah, that is a temporary fix too inaccurate, but seemed to be waiting for the fixed...

In mupen64 plus, it seems to switch the 32bit-64bit mode into Fpu before modifying the Fpu Locations. Maybe need it.

[Frank-74]

Shadow Man (U) doesn't boot with this fix.

[AmbientMalice]

Shadow Man doesn't boot for me, either.

[AmbientMalice]

Interestingly, it also seems to have broken the Turok games, (different dev despite being published by Acclaim) and also Hydro Thunder in HLE, but not LLE.

[LegendOfDragoon]

@project64 The key difference between Project64 and 1964 is the way each emulator handles mtc0 when the FR bit changes.

In here

project64/Source/Project64-core/N64System/Mips/RegisterClass.cpp

Line 376 in aea724b

m_FPR_S[count] = &m_FPR[count].F[1];

it writes to m_FPR[count].F[1] where as 1964 would write to m_FPR[count].F[0]. Aside from that, the shuffling is different. In 1964, when it switches between the modes, the upper half of the 64bit register is preserved, so when it switches to 32bit mode from 64, then switches back to 64 the upper half will be restored to what it was before it switched to 32 bit mode. When switching from 32bit mode to 64bit, it moves the upper half of the 16 64-bit FPR registers into the lower half of the odd number 64-bit FPR registers.

Doing these changes may "fix" Star Wars Battle for Naboo, but I'm not 100% this is how it should be done. I'd personally go with how 1964 did it for now, since that is what makes the most sense to me, after reading the VR4300 manual. One problem I've encountered in 1964 and Mupen, is that Rogue Squadron appears to be buggier. I noticed both have this issue where the lighting in some parts of the game look buggy. It could be an unrelated issue, such as timing, but who knows.

One other thing I like about 1964's floating point code, is the fact that it doesn't use pointers for the floating point registers in 1964 1.1. It just assumes that the FR bit will never change for that specific portion of code. It may be questionable to do for games that switch modes a lot, but I think most games do not. It would be a nice option to implement for the recompiler, if floating point instructions significantly impact the performance. I'd even consider doing it, just to see if it gives a noticeable speed improvement.

[project64]

I been wanting to write to write some tests on a real n64 to see what happens, but it just not has happened yet and I been focused on trying to get an android version of project64.

but yes something like that is liikely wrong in how it is done in pj64

[cxd4]

That, and whatever recompiler trick is deserved here for this FP thing, would be deserved even more for the ARM recompiler on Android which actually would have a higher chance of needing a recompiler. And the two recompilers would have to be separate code bases. And working on x86 won't help that.

[oddMLan]

Is this still a milestone for Project64 2.2... which, already was released? :P

[theboy181]

I cant seem to get Indy to boot - what settings and plugins are needed?

[Frank-74]

@theboy181
Default settings with latest master. I used z64gl and the (E) region carrot unreleased version of Indy.

[AmbientMalice]

@theboy181 The US version can be a little fickle about booting. PAL version tends to boot more consistently. You need either z64gl or GLideN64.

[theboy181]

AL RDP is a no go?

[AmbientMalice]

Angrylion's will work fine, but expect it to be slow. Especially in high resolution mode.

[project64]

AL is good for testing, but nice to see the core more fixed

[theboy181]

Got it booting now, and tested against several RSPs and RDPs. Seems to have different crashes if you let the demo roll. unsure if its RSP or emulator related..