Blast Corps doesn't boot up

[GoogleCodeExporter]

Describe your system:
 - Linux distribution: Debian sid
 - Machine type: 64-bit
 - Mupen64Plus version: svn1416
 - Plugins used: glide64, jttl_audio, blight_input

Blast Corps 889D4D337AD11CE94357511C725EAB6A

Doesn't boot up and looks a little bit like the donkey kong 64 bootup
problem in bug 273. Happens in every mode.

Original issue reported on code.google.com by sven@narfation.org on 3 Oct 2009 at 11:48

[GoogleCodeExporter]

0x80273478 seems to be interesting. Savegame right before the instruction can be
found at http://www.mediafire.com/?ytdgmcyjlz5 -  it is the 84114617. 
instruction
without delay slots.

0x80273478 lw $t1, 0x0008($t0)

$t0 is 0x0000000000000000
$t1 is 0x000000000000029C

After that instruction we jump (exception) to 0x80000000 which seems not to be 
real
useful

Original comment by sven@narfation.org on 4 Oct 2009 at 4:19

[GoogleCodeExporter]

Instruction is handled by (pure_interp.c) LW -> (memory/memory.c) 
read_word_in_memory
[returns because virtual_to_physical_address says that it physical address 0]. 
LW
does the sign extend even if the previous read failed.... could maybe lead to a 
wrong
behavior.

virtual_to_physical_address in memory/tlb.c checks tlb_LUT_r[addresse>>12] 
which is
NULL for that address and TLB_refill_exception is called because of that.

TLB_refill_exception in r4300/exception.c sets cause to "Cause = (2 << 2)", 
BadVAddr
is set to 8, Context is set from 0x7FFFF0 to 0, EntryHi is set to 0 was 0, EPC 
is set
to 0x0x8027347C was 0x0x802D72E8, Status is changed to 0x0xFF03 was 0x0xFF01. 
Then
some search in TLB is done, but not usual_handler is set and thus interp_addr 
is set
to 0x80000000. It is not called from delay slot so it is tried to change Cause 
"Cause
&= 0x7FFFFFFF;" (which doesnt change anything it this case), but EPC is changed 
back
to our real "problematic" address 0x0x80273478. last_addr is then changed to
0x80000000 was 0x8027347C. "if (!dynacore || dyna_interp)" is true as we are 
using
pure_interpreter and dyna_interp is set to 0, but was 0.

Original comment by sven@narfation.org on 4 Oct 2009 at 5:37

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 13 Jan 2010 at 1:19

• Added labels: Component-Core, Type-Defect

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 22 May 2011 at 3:53

• Added labels: Milestone-2.0

[GoogleCodeExporter]

Removed 2.0 blocker.  This one will need a good gui debugger to solve I think.

Original comment by richard...@gmail.com on 5 Mar 2012 at 12:16

• Removed labels: Milestone-2.0

[GoogleCodeExporter]

10:45am » <casualjames> so much google account verification bs for just a 
post, can someone post the link?

As sven pointed out, the suspicious instruction is the load from memory address 
0x00000008 (and others in the same zone which come later).

Mapping the memory range 00000000 to 00001000 to the beginning of RDRAM fixes 
the crash problem (but not the fast intro problem), e.g. add:

In file memory/memory.c, start of function read_nomem():
        if (address < 0x00001000) { read_rdram(); return; }
In file memory/memory.c, start of function write_nomem():
        if (address < 0x00001000) { write_rdram(); return; }

However, I suspect that this is just a workaround and memory addresses 
00000000-00001000 are not supposed to be mapped to RDRAM. Note that however 
pretty much all games TLB map addresses C0000000-C00001000 to RDRAM, and that 
might be related to the problem. I don't really know much more about it, tough.

Original comment by TheDaFox on 24 Jul 2012 at 4:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Some notes from casualjames (IRC)

[02:11:38] <casualjames> about the blast corps crash bug (the memory reads from 
0x0000XXXX)
[02:12:52] <casualjames> after reading some documentation, RDRAM is supposed to 
be mapped at 0x00000000
[02:14:08] <casualjames> memory accesses from addresses 80000000-A0000000 and 
A0000000-C0000000 are just "mirrors" of 00000000-20000000 with different 
caching behaviour and no TLB mapping
[02:15:04] <casualjames> this is well documented in the mips manual, i guess it 
turns out nobody bothered implementing it
[02:19:31] <casualjames> i'm still confused about it tough... since virtual 
address 0000XXXX is in a mapped memory area, shouldn't a TLB miss happen 
anyway, even tough physical 0000XXXX is RDRAM?

[18:04:20] <casualjames> hmm, forget what i said last night. 00000000-20000000 
should always go through TLB
[18:05:12] <casualjames> so a read of 00000000 is supposed to cause a TLB miss
[18:05:36] <casualjames> the only exception is if a certain bit in Status is 
set, but doesn't seem to be the case
[20:17:02] <casualjames> hmmm
[20:17:07] <casualjames> i think i hit jackpot
[20:17:42] <casualjames> in update_SP
[20:18:23] <casualjames> after the call to the rsp plugin, there's code to add 
SP_INT and DP_INT with a delay of 1000
[20:19:23] <casualjames> change that to 1000000, and the blast corps and dk 
intro are almost synchronized and almost no polygon glitches
[20:19:55] <casualjames> i think the polygons only glitched 2 times during the 
whole intro
[20:20:16] <casualjames> the audio at some times seemes to lag by less than a 
second but that could be because of slow CPU
[20:21:36] <casualjames> the most interesting part about it is that if you 
change that to some other value like 2.000.000 or 500.000, it doesn't play 
correctly anymore
[20:21:45] <casualjames> it plays too fast or too slow
[20:21:59] <casualjames> interesting that such a "nice" number happened to 
work... not likely it's just luck

Original comment by s...@narfation.org on 30 Jul 2012 at 6:22

[GoogleCodeExporter]

Issue 326 has been merged into this issue.

Original comment by s...@narfation.org on 12 Sep 2012 at 7:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Was fixed in casualjames branch and is now merged

Original comment by s...@narfation.org on 30 Oct 2012 at 9:51

[GoogleCodeExporter]

Original comment by s...@narfation.org on 30 Oct 2012 at 9:51

• Changed state: Fixed

[GoogleCodeExporter]

This doesn't work for me in v1.99.5, is this a regression or do I need some 
specific configs?

Original comment by glowacz@gmail.com on 13 Jan 2013 at 6:13

[GoogleCodeExporter]

Your need the version from Hg. See

http://code.google.com/p/mupen64plus/wiki/CompilingFromHg
http://code.google.com/p/mupen64plus/wiki/CrossCompilingOnLinux
http://code.google.com/p/mupen64plus/wiki/CompilingOnWindows
http://code.google.com/p/mupen64plus/wiki/MacOSXInstructions

Original comment by s...@narfation.org on 13 Jan 2013 at 8:58

[GoogleCodeExporter]

Okay great. Does that mean it should be fixed in the next release?

Original comment by glowacz@gmail.com on 13 Jan 2013 at 3:49

[GoogleCodeExporter]

Maybe. It is unknown when Richard will release and it is unknown what he will 
release. But the signs look good. You can also test a snapshot in the meantime 
http://rapidshare.com/users/ecsv/9187

Original comment by s...@narfation.org on 13 Jan 2013 at 5:52

[GoogleCodeExporter]

Thanks! I'm getting some build errors on osx mountain lion with that snapshot. 
Maybe hg tip will build.

For example:
In file included from ../../src/memory/dma.c:37:
../../src/memory/../r4300/new_dynarec/new_dynarec.h:33: error: expected ‘)’ 
before ‘block’

Original comment by glowacz@gmail.com on 13 Jan 2013 at 6:34

[GoogleCodeExporter]

Please get in contact with  n.pepinpe@gmail.com . He is currently the one 
interested in porting it to OSX. He also submitted some patches to fix the 
build at the end of last year.

And yes, these snapshots were meant for Windows or Linux.

But you can just try to change u_int to "unsigned int" in 
src/r4300/new_dynarec/new_dynarec.h

Original comment by s...@narfation.org on 13 Jan 2013 at 7:45

[GoogleCodeExporter]

Yeah, I added typedef unsigned int u_int; but that would have worked too. I'm 
currently playing around with OpenEmu a bit seeing if I can get tip to build in 
their proces. They seem to have a fairly good port.

Original comment by glowacz@gmail.com on 13 Jan 2013 at 7:50