Banjo Tooie freezes when entering Unga Wunga's chamber in Mayahem Temple about mupen64plus HOT 17 CLOSED

[deleted comment]

[deleted comment]

Sorry, I didn't include all save files for the game. Attached are the savestate 
I use
to test plugins, the mpk and eep files as well.

I started a new game on Mupen 64 v0.5, with Rice Plugin 6.1.0, JttL's SDL Audio
Plugin 1.3, Blight's SDL v0.0.10 plugin (all included with Mupen 64 v0.5). The 
game
crashes randomly, but using save states I was able to get back to the same 
position
in the game, this time with doing as little as possible to get there. No other
Jiggy's obtained (except for the one you have to get in order to access Mayahem
Temple). I had no issues in the original Mupen64 until that point in the game as
well, and when I got there the issue was the same. 


I've also tried all three CPU core modes, and all three result in the same 
problem,
in both emulators.

Here's more information about the ROM from the console. . 

Compression: .zip
Imagetype: .z64 (native)
Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
MD5: 40E98FAA24AC3EBE1D25CB5E5DDF49E4
80 37 12 40
ClockRate = f
Version: 144a
CRC: c2e9aa9a 475d70aa
Name: BANJO TOOIE
Manufacturer: Nintendo
Cartridge_ID: 3742
Country: USA
PC = 80000400
EEPROM type: 1

I'd like to add that I'm having the exact same problem as divideoverflow. 

One more comment. . Under Wine 1.0-rc3, Project 64 1.6, using all Jabo Plugins
included (Jabo Direct3D 1.6 for Graphics) and setting the CPU to Interpreter 
instead
of Recompiler, I'm able to get a more or less stable game, with good 
performance, and
the ability to enter and exit Unga Wunga's cave repeatedly. As a result, I have
determined that the ROM itself is not bad. I'd much prefer that I were running 
BT
under an open source emulator without Wine adding another layer of abstraction 
and
emulation to an already demanding emulation load.

This issue still occurs with the release version of 1.4, with Rice Video 1.4, 
JttL
SDL Audio 1.4, and Blight's SDL Input Plugin 0.0.10. Please note that both with
versions 1.3 and 1.4, there is no console output concerning any error, and only 
the
game itself freezes. The Mupen64plus GUI remains responsive, does not freeze or 
lock
up. In fact, the saved state I posted can be reloaded without stopping and 
starting
the emulator. You can run into the door, the jiggy transition is shown, you can 
wait
as long as you like and then hit F7.. you're back outside the doorway. This may 
be of
no consequence of course, depending on what Mupen64plus is supposed to do when
loading a state, but I figured I'd mention it. 

I appear to be having this issue as well on Mac OS X.  Freezes also occur on 
other
occasions at random, but this issue is reproducible.

Unforunatley, the problem is STILL here in the 1.5 beta version for all systems
(including mac osx). I have looked it up, and it appears that turning off 
dynarec
solves the problem, but i have no idea on how to turn it off.

Is there a way to turn off dynarec and use the Rice video plugin? 

[deleted comment]

This will also not work with pure interpreter. I have uploaded a savegame right
before the command which propably gets interpreted wrong
http://www.mediafire.com/?nvgjntdgzq2

it is at 0x8001c360 mtc1 $a1, $f16

$a1 is 0xFFFFFFFF8034AFB0

[deleted comment]

Just as note for further investigation (with fix for bug 285):

normalised FGR Before execution:
start-----------FGR
00 0000001700000116
01 801c906c00000017
02 00000a8000000008
03 0000000000000005
04 0000000000000005
05 000000000000007f
06 000000000000012d
07 0000000000000001
08 000000008000e800
09 0000000080198323
10 0000000000000004
11 0000000000000004
12 0000000000000000
13 00000000ffffffff
14 0000000000000000
15 00000000ffffffff
16 00000000801976b0
17 0000000000000000
18 0000000000000c00
19 0000000000000081
20 0000000040ee823d
21 00000000ffffffff
22 00000000bd07e637
23 00000000ffffffff
24 00000000bd89b922
25 00000000ffffffff
26 000000003f7f6b9e
27 0000000000000000
28 0000000000000000
29 0000000000000000
30 0000000000000000
31 0000000000000000
end-------------FGR

After execution:
start-----------FGR
00 0000001700000116
01 801c906c00000017
02 00000a8000000008
03 0000000000000005
04 0000000000000005
05 000000000000007f
06 000000000000012d
07 0000000000000001
08 000000008000e800
09 0000000080198323
10 0000000000000004
11 0000000000000004
12 0000000000000000
13 00000000ffffffff
14 0000000000000000
15 00000000ffffffff
16 000000008034afb0
17 0000000000000000
18 0000000000000c00
19 0000000000000081
20 0000000040ee823d
21 00000000ffffffff
22 00000000bd07e637
23 00000000ffffffff
24 00000000bd89b922
25 00000000ffffffff
26 000000003f7f6b9e
27 0000000000000000
28 0000000000000000
29 0000000000000000
30 0000000000000000
31 0000000000000000
end-------------FGR

So this savegame is more related to bug 286, but doesn't help to resolve the 
real
issue. I will create a new savegame with more information later, but my current 
guess
that it is related to the Exception/Interrupt handling.

Updated savestate can be found at http://www.mediafire.com/?2o03zh2h10t

Interesting opcode add 80031ae4
sw $t2, 0x0010($t3)

$t2 is 0x000000001FC007C0
$t3 is 0xFFFFFFFFA4800000