Naruto Ultimate Ninja 3 Crash

[GoogleCodeExporter]

1) Did the game ever work correctly (i.e. not have this problem) on the
Official PCSX2 build or an earlier version of PCSX2 playground? 
(If so, please specify the latest pcsx2-playground or Official revision
that last worked.)
The game never worked fully but you could play VS battles and the story
intro was working on an earlier version (it crashed after the intro).

2) What steps will reproduce the problem?
1. Enter a VS battle or story mode
2. Emu crash at loading screen(sometimes it says has encountered a problem
and needs to close, sometimes it just hangs)

3) What version of the product are you using? On what operating system?
I'm using PCSX2 svn349 TLB build on Windows XP Professional SP3 and i have
NTSC version of the game.

4) Please provide any additional information below.
I give you my emulog.txt i logged the cpu with the logging options in PCSX

Original issue reported on code.google.com by andutrache@gmail.com on 22 Nov 2008 at 8:29

Attachments:

• emuLog.txt

[GoogleCodeExporter]

I confirm That naruto, narutimate acel 2 is doing the same thing . (it was not 
doing 
so before)

Original comment by Wagnar...@gmail.com on 23 Nov 2008 at 2:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Naruto Ultimate Ninja 2 has the same problem.

I dunno why all Naruto games have the same crash. Maybe they need a special fix 
of
some kind.

Original comment by andutrache@gmail.com on 23 Nov 2008 at 10:16

[GoogleCodeExporter]

I got in the console:  vmhack vmhack vmhackvmhack Eception: Write
Ive try the game with disabling dual core but the problem remains. so the bug 
is 
from a previous rev. Ill try to find out.

Original comment by Wagnar...@gmail.com on 23 Nov 2008 at 5:32

[GoogleCodeExporter]

OK Rev 268 is working and Rev 269 to lastest REV is not working.

Original comment by Wagnar...@gmail.com on 23 Nov 2008 at 6:07

[GoogleCodeExporter]

tested rev 353 same problem

the crash was present even before the playground project started.

Original comment by andutrache@gmail.com on 23 Nov 2008 at 10:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is a problem with the CP0, most likely.  The CP0 can change the PS2's 
memory
mappings, and it's not very well supported.  When the memory isn't remapped 
when it
should be, vmhacks start happening and then crashes start happening.  I'm also 
pretty
sure the same problem is to blame for Ecco the Dolphin crashing in Issue 49. 
Sometimes just calling the cpuTestTIMR/PERF functions more often can fix the 
CP0,
which is why some counters changes have fixed these games (usually because they 
were
bugged updates and were forcing many more branch tests than necessary).

The new major change we're going to merging in soon will deal mostly with how 
the PS2
maps memory, so I'll have to wait until that's done before I can target the CP0 
with
extra detail.

In the meantime I'm going to revisit some of the cpulogs so that they give some 
more
useful and detailed information about when cpu Branch Tests occur and such, 
since
execution of Branch Tests (or a lack there-of) can make or break many games.  
I'll
also post a special test build of Pcsx2 that runs the TIMR/PERF code very often 
to
see if it fixes these games.  If so it'll confirm my suspicion.  but that'll 
have to
wait until I get home in a day or two.

Original comment by Jake.Stine on 23 Nov 2008 at 11:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Cool thanks for the explanation Jake. Ill test with your special pcsx2 revision 
when 
you have time.

Original comment by Wagnar...@gmail.com on 23 Nov 2008 at 11:42

[GoogleCodeExporter]

#define EE_WAIT_CYCLE 32   instead of 2048 fix my problem.

Original comment by Wagnar...@gmail.com on 24 Nov 2008 at 2:00

[GoogleCodeExporter]

Thanks for the update.  That confirms my suspicion.
Can you fold back the EE_WAIT_CYCLES value until you find one higher where it 
still
works?  Like 1024, 768, 512, 384, and 256.  I want to know how low I have to go 
to
put a temp fix onto the SVN.  I don't want to use 32 because it could really 
slow
down certain games way too much.  But if one of those top three works then we 
can use
that for now until I figure out the ideal "hot spots" in the code to trigger 
more
branches.

(that way games that need the extra branching will branch, but without slowing 
down
games that don't need it)

Original comment by Jake.Stine on 24 Nov 2008 at 3:07

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ok me and my brother were testing some things with some games.
Naruto seem ok at 512. while HackGU Volume1 . crash.
Hack gu work at 200 and crash at 256.
So for now in my "personal code" I set it to 128

Original comment by Wagnar...@gmail.com on 24 Nov 2008 at 6:32

[GoogleCodeExporter]

Nice, I'm glad you figured it out.
Maybe this will fix other games that are crashing too.
You should add a temporary fix in the Gamefixes menu of PCSX2 until you take a 
look
on the CP0.

Original comment by andutrache@gmail.com on 24 Nov 2008 at 11:54

[GoogleCodeExporter]

Yes it probably will fix some other games.  The trouble as Wagnard found is 
that it
can often require very small and seemingly arbitrary values for wait cycles to 
fix
the problem.  And sometimes some values will fix one game and break another, 
because
they cause the branch points during code execution to shift.  I had the same 
problem
when troubleshooting games that tended to crash after BIOS calls.  I ended up 
with
this chart of compatibility:

Wait Cycles    Game A   Game B
1024             X        0
768              0        X
512              X        X
384              X        0
256              X        X
192              0        X

... So at 512 they both worked, but at 384 one of them broke again while the 
other
continued to run.  Then they both worked again at 256 and the *other* one broke 
at
192.  I figure this COP0 thing is similar, and hopefully I'll be able to find 
the
points in the code where branches need to be issued, so that the games will 
pretty
much work regardless of wait cycle settings.

Original comment by Jake.Stine on 25 Nov 2008 at 6:40

[GoogleCodeExporter]

Possibly good news!  I inadvertently found some sections of the COP0 code that 
call
the EE's *interpreter* branching code.  Most of the time this works, but in a 
couple
places it signals for a branch ASAP and.. well.. the EErec doesn't listen to the
interpreter's branching variables so it just keeps on chugging along 
indefinitely.

.. now I just have to figure the best way to fix it, and then hope it solves 
this
Issue. :)

Original comment by Jake.Stine on 25 Nov 2008 at 12:44

[GoogleCodeExporter]

Excellent. Glad you found it this fast.
Ill wait and try your change when you have time to do it.

Original comment by Wagnar...@gmail.com on 25 Nov 2008 at 6:14

[GoogleCodeExporter]

The new 367 revision kinda fixed naruto a little it now crashes where it 
'should'
You're getting close.

Original comment by andutrache@gmail.com on 30 Nov 2008 at 12:25

[GoogleCodeExporter]

That's thanks to the EE_WAIT_CYCLE set to 512 instead of 2048.  But yeah, 
hopefully
I'll be able to solve it properly in the near future (which should in turn help
several games, I think).

Original comment by Jake.Stine on 30 Nov 2008 at 2:36

[GoogleCodeExporter]

If you could put an option to set the EE_WAIT_CYCLE in the Advanced options in 
PCSX2
people could experiment with different settings at least until the CP0 is fixed 
properly.

Just an idea, i don't know if this is possible or not I'm not really into
programming(though i wish i were).

Original comment by andutrache@gmail.com on 1 Dec 2008 at 8:44

[GoogleCodeExporter]

Fixed this bug as of r393.  NUN2 works for me and NUN3 was tested by someone 
else and
seemed fixed too.  I'll wait for a third confirmation from Andutra or Wagnard 
before
closing the issue

Original comment by Jake.Stine on 5 Dec 2008 at 5:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Nice now NUN3 works but NUN2 still crashes the same maybe its because its PAL.
What version have you tested PAL or NTSC?

Original comment by andutrache@gmail.com on 5 Dec 2008 at 3:41

[GoogleCodeExporter]

Yep Naruto Accel 2 is now working at 1024 wait state. But there still seem to 
be a
problem with hackGU (worked at 200 EE wait state).

Original comment by Wagnar...@gmail.com on 5 Dec 2008 at 4:37

[GoogleCodeExporter]

Naruto Accel 2 worked fine even before the fix, it crashed sometimes but it was 
playable.

Original comment by andutrache@gmail.com on 5 Dec 2008 at 5:30

[GoogleCodeExporter]

yes and no. One some revision jake set back the EE wait state to 512. On this 
value
naruto is working. But on high value like 1024 or 2048 it wasn't working.

Original comment by Wagnar...@gmail.com on 5 Dec 2008 at 8:38

[GoogleCodeExporter]

ok tested both Naruto Ultimate Ninja 2 NTSC and PAL and they both crash when 
trying
to go to another area.

Original comment by andutrache@gmail.com on 6 Dec 2008 at 5:05

[GoogleCodeExporter]

Hmm NUN2 NTSC is what I have here.  I had no trouble starting a match but 
didn't try
to play to completion of a match.. is that when the crash is now happening?  
I'll try
and test it a little deeper.

There ares till a handful of COP0 functions that are not run properly.  I have 
them
logged and will look for games that use them, so that I have a testbed to use 
for
making sure they're implemented properly. :)

Original comment by Jake.Stine on 7 Dec 2008 at 4:15

[GoogleCodeExporter]

Ok I found the second crash in NUN2, and it looks like it might well be a bug 
in the
VM-based EErec.  Egad.  That code is almost untouchable.  >_<

Original comment by Jake.Stine on 8 Dec 2008 at 8:32

[GoogleCodeExporter]

I do not understand naruto ultimate 2,3,4 always worked in the emulator 0.9.2 
because never in 0.9.5 (except the ultimate 3:) Jake.Stine? I asked for 
ramapcsx2, 
he said he did not know.

Original comment by gesielon...@gtempaccount.com on 8 Dec 2008 at 10:57

[GoogleCodeExporter]

The trouble with recompiler bugs is that subtle changes to the way the emulator
processes branches, interrupts, or DMAs can change what code gets run and in 
what
order.  So sometimes bad opcodes don't cause a crash, but then other times the 
code
is bypassed or run during a harmless state of the emu so it's ok.  So more or 
less
it's by chance more than anything.

Original comment by Jake.Stine on 8 Dec 2008 at 1:40

[GoogleCodeExporter]

Hum...! Tanks

Original comment by gesielon...@gtempaccount.com on 8 Dec 2008 at 6:36

[GoogleCodeExporter]

sorry, i have naruto ultimate ninja 2 NTSC-J and it crashes in rev 426 after i 
enter
the first battle , i choose the first item in the menu, press start, it loads, 
then i
can see a scene with grass and trees , the camera move forward for a second and 
then
it crashes.

Is it only me?

Original comment by andreabo...@gmail.com on 16 Dec 2008 at 1:29

[GoogleCodeExporter]

Test rev441.
http://www.4shared.com/file/76216405/1a4f3562/PCSX2_095_rev_396_PP_rev_441.html?
dirPwdVerified=ea5d0754 .

Original comment by gesielon...@gtempaccount.com on 16 Dec 2008 at 1:35

[GoogleCodeExporter]

Tested REV 441 with both Naruto Ultimate Ninja 2 PAL and NTSC version.
The crash has been fixed it now works.

YOU ARE THE BEST !!!! 1mil thnx.

Original comment by andutrache@gmail.com on 17 Dec 2008 at 11:15

[GoogleCodeExporter]

Resolved by VU0 sync fix in r441.  Issue Closed!

Original comment by Jake.Stine on 17 Dec 2008 at 11:20

• Changed state: Verified