Emulator

Aquaman Battle for Atlantis (GC) (freezes up at the start of mission 1)
this worked up to svn r4758 then stopped working on svn r4769
so it broke somewhere in between these two
cannot find the other svn's so this is the closest i can get

this might be the same svn that broke both games

Battalion Wars (GC) (after you start a new game you have to watch through the intro
then just after that when Commander Betty starts talking the emulator freezes up)
this worked up to svn r4758 then stopped working on svn r4769
so it broke somewhere in between these two
cannot find the other svn's so this is the closest i can get

looks like r4759 broke all these games but don't have it to confirm it

Issue 2563 has been merged into this issue.

Issue 2242 has been merged into this issue.

Issue 2123 has been merged into this issue.

Issue 2482 has been merged into this issue.

issue 1898 can be merged into this aswell

Issue 1898 has been merged into this issue.

appearantly fifo breakpoints don't always get deleted in dual core mode. this causes
an infinite loop in the gpu thread.

debugging and manually resetting _fifo.bFF_BPEnable and _fifo.bFF_Breakpoint causes
the values to be set again immediately. in all cases i tested the breakpoint is
successfully removed thereafter and the game continues execution.

i guess this might be some timing/syncing issue.

So does this mean in single core mode the issue should not exist?

i am not sure, but atleast wii sports does not seem to have any issues when running
in sc mode wheras it has them in dc. it's hard to tell though as this occurs randomly
and thus is bitchy to debug.

furthermore i started investigating this today and still dont quite know how bp's
should be handled thoretically which makes things harder for me :P

if i am right, the bp is cleared after interrupt processing. what might cause the
resetting of them is a race condition in the command processor due to a lack of
synchronisation.

i noticed that in the command processor write16 with case CTRL_REGISTER and
tmpCtrl.BPEnable set is sometimes called after the interrupt processing. my guess is
that this happens if there are bps within a close range, so one gets written into the
fifo as the other is read and handled. the second one then might overwrite the flags
of the first one, causing it to loop infinetely.

as i said, this is just a guess, but this might also explain why it only happens in
some games.

Lamin here: How were some of these games then able to work fine before (in both core
modes)? It "was" being handled gracefully in the past wasn't it?

This issue is also affecting Wii Music. Game worked fine with no freezes before r4759
with dual core enabled. Now it freezes after a while. Here is my report about this game
with more information: Issue 2105

Well dual core mode has nothing to do with the Super Robot Taisen GC hang though, I
tried with both modes, both hanged at the exact same point.

Oh, and Super Robot Taisen GC hang was reported on issue 2563, check there for more
info.

you can add Reign of Fire (GC)and Starsky and Hutch (GC) to the list as these worked
up to svn r4758 then stopped working on svn r4769

Zatch Bell! Mamodo Battles (GC)
(freezes up on the very first screen (checking memory cards))
last worked on r4758 amd broke on r4759

issue 2430 can be added to this

issue 2235 and 1642 can be added to this aswell

Issue 1642 has been merged into this issue.

Issue 2235 has been merged into this issue.

Issue 2430 has been merged into this issue.

Wii Play hang has been reported on Issue 2633

Timesplitters 2 (GC)can also be add to the list of broken games

In response to what mitjabam said in comment 10, I think that is part of the reason
for the slowdown issue in Hyrule Field in Zelda Twilight Princess. Kiesel-Steins
patch fixes the slowdowns in the short term but developers might want to start
working on a proper fix for this issue now that there is more information behind what
is causing these issues.

and also add The Incredibles : Rise of the Underminer (GC)

Also Red Steel 2 is affected . When "dual core" is enabled game freezes after a few
minutes during the introductory video. No issues/freezes when "dual core" is unchecked.

today i finally found some time to experiment a little more. changing in CommandProcessor.cpp

Common::AtomicStore(fifo.bFF_BPEnable, tmpCtrl.BPEnable);
if (tmpCtrl.BPInit && tmpCtrl.BPEnable && tmpCtrl.GPReadEnable)
{
// Clear old BP and initiate new BP
Common::AtomicStore(fifo.bFF_Breakpoint, 0);
// The following is a hack of Synchronized Breakpoint for dual core mode
// Some games only waits a finite N cycles for FIFO interrupts, then hangs up on time out
// e.g. Metriod Prime 2
if (g_VideoInitialize.bOnThread && g_ActiveConfig.bFIFOBPhack)
UpdateInterrupts(true);
}

back to:

if (g_VideoInitialize.bOnThread)
{
// Instant Breakpoint and Interrupt, since we haven't implemented accurate BP on dual core
// Most likely the Read thread has already exceeded BP here, but it seems we are still cool
if (tmpCtrl.BPInit && tmpCtrl.BPEnable && tmpCtrl.GPReadEnable && tmpCtrl.GPLinkEnable)
{
Common::AtomicStore(fifo.bFF_Breakpoint, 1);
UpdateInterrupts(true);
}
else
{
Common::AtomicStore(fifo.bFF_Breakpoint, 0);
}
}
else
{
// fifo.bFF_BPEnable is only used in single core
Common::AtomicStore(fifo.bFF_BPEnable, tmpCtrl.BPInit && tmpCtrl.BPEnable && tmpCtrl.GPReadEnable && tmpCtrl.GPLinkEnable);
if (!tmpCtrl.BPInit || !tmpCtrl.BPEnable || !tmpCtrl.GPReadEnable || !tmpCtrl.GPLinkEnable)
Common::AtomicStore(fifo.bFF_Breakpoint, 0);
}

and in Fifo.cpp

while (_fifo.bFF_GPReadEnable && ((!_fifo.bFF_BPEnable && _fifo.CPReadWriteDistance) || (_fifo.bFF_BPEnable && !_fifo.bFF_Breakpoint)))

back to:

while (_fifo.bFF_GPReadEnable && _fifo.CPReadWriteDistance && !_fifo.bFF_Breakpoint)

actually fixes this problem although this is just a hack, as it removes accurate breakpoints in dualcore mode.

i still believe the cause why some games freeze is that there are several breakpoints set within nanoseconds. i have verified this on wii sports.

i have done some further experiments concerning possible race conditions by forcing the fifo loop to exit temporarily on any control register write. this didnt help, which brings me to the conclusion that the error probably lies within the interrupt scheduling from the video thread, which has not been executed when following breakpoints are hit.

i will do some further investigation when my time allows it.

ok, i added some more logging and changed the level to notice as breakpoints wouldnt occur on debug due to heavy slowdowns and came up with the following log:

20:27:188 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0014
20:27:188 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD OFF | LINK ON | BP OFF || Init OFF | OvF ON | UndF OFF
20:27:188 .\Src\CommandProcessor.cpp:541 N[CP]: write to FIFO_BP_LO : 7de0
20:27:188 .\Src\CommandProcessor.cpp:545 N[CP]: write to FIFO_BP_HI : 0053
20:27:188 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0014
20:27:188 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD OFF | LINK ON | BP OFF || Init OFF | OvF ON | UndF OFF
20:27:188 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0036
20:27:188 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD OFF | LINK ON | BP ON || Init ON | OvF ON | UndF OFF
20:27:188 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0037
20:27:188 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD ON | LINK ON | BP ON || Init ON | OvF ON | UndF OFF
20:27:188 .\Src\Fifo.cpp:179 N[FIFO]: fifo breakpoint hit: 00537de0, readPtr: 00537de0
20:27:188 .\Src\CommandProcessor.cpp:758 N[CP]: Fifo Breakpoint Interrupt: Asserted
20:27:188 .\Src\CommandProcessor.cpp:758 N[CP]: Fifo Breakpoint Interrupt: Deasserted
20:27:188 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0017
20:27:188 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD ON | LINK ON | BP ON || Init OFF | OvF ON | UndF OFF
20:27:192 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0016
20:27:192 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD OFF | LINK ON | BP ON || Init OFF | OvF ON | UndF OFF
20:27:192 .\Src\CommandProcessor.cpp:541 N[CP]: write to FIFO_BP_LO : 3460
20:27:192 .\Src\CommandProcessor.cpp:545 N[CP]: write to FIFO_BP_HI : 0054
20:27:192 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0014
20:27:192 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD OFF | LINK ON | BP OFF || Init OFF | OvF ON | UndF OFF
20:27:192 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0036
20:27:192 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD OFF | LINK ON | BP ON || Init ON | OvF ON | UndF OFF
20:27:192 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0037
20:27:192 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD ON | LINK ON | BP ON || Init ON | OvF ON | UndF OFF
20:27:195 .\Src\Fifo.cpp:179 N[FIFO]: fifo breakpoint hit: 00543460, readPtr: 00543460
20:27:195 .\Src\CommandProcessor.cpp:758 N[CP]: Fifo Breakpoint Interrupt: Asserted
20:27:195 .\Src\CommandProcessor.cpp:758 N[CP]: Fifo Breakpoint Interrupt: Deasserted
20:27:195 .\Src\CommandProcessor.cpp:445 N[CP]: write to CTRL_REGISTER : 0017
20:27:195 .\Src\CommandProcessor.cpp:453 N[CP]: GPREAD ON | LINK ON | BP ON || Init OFF | OvF ON | UndF OFF

after that the freeze occured. i used wii sports and waited about 2 minutes in the main menu. notice that the actual row numbers dont match the current revision, as i did some changes for logging, but the executed code is the same.

so it seems, the interrupts get handled properly aswell. maybe it's just that the fifo doesnt get filled anymore because of the overflow flag, which cant go away since there is a breakpoint active and the command for breakpoint deletion cant get issued. as you see i can just do wild guesses as i don't really have the big picture here :) maybe one of the devs could enlighten me ;)

to be more precise, the following small patch fixes the issue for wii sports.

in CommandProcess.cpp change:

Common::AtomicStore(fifo.bFF_BPEnable, tmpCtrl.BPEnable);

to:

if (tmpCtrl.BPInit && tmpCtrl.BPEnable){
Common::AtomicStore(fifo.bFF_BPEnable, 1);
}
else{
Common::AtomicStore(fifo.bFF_BPEnable, 0);
}

this is the only place where the semantic of ayuanx' accurate bps differs from the previous version (apart from the enhancements, of course ;)
probably this is still a hack as i don't know how real hw handles this. i will test if this change breaks any games i own.

sadly i have no games with me that work after the fifo patch of ayuanx(my brother has a few games that would work after the change like ssx3) so i can't really tell if it works for both parties involved in the fifo change but it seems to work fine on old games at first sight...

every game i have works with and without that patch

...except 1

ssx 3 "works" on both with the patch as without it

however, with the patch it goes to no FPS (or anything actually) after loading mem card which should at that point load a video. im guessing you are at the right track but now completely :P

ok all of the GC games that were broken by this are now running so i suppose this can be closed now

ayuanx did a good job on the fifo recently, but random freezes are still as bad as before in many games (i.e. wii sports), and as many issues were merged into this i don't think it should be closed.

the folowing hack against freezes still works in the most current version, but stops ssx3, tales of grace and probably a few more titles from running:

in Fifo.cpp change

if ((readPtr <= _fifo.CPBreakpoint) && (readPtr + 32 > _fifo.CPBreakpoint))

to

if ((readPtr <= _fifo.CPBreakpoint) && (readPtr + 32 > _fifo.CPBreakpoint) && _fifo.bFF_BPInt)

the following if-statement can optinally be deleted thereafter as it has no effect anymore.

not only are the games already mentioned here crashing randomly, but also others, since the FIFO got its changes...SMG2 for example...seems this applies for many games, though...so Dolphin is in a rather unstable state atm.

Issue 2368 has been merged into this issue.

Issue 2335 has been merged into this issue.

Issue 1904 has been merged into this issue.

Issue 2425 has been merged into this issue.

Issue 3284 has been merged into this issue.

Issue 2633 has been merged into this issue.

Issue 3318 has been merged into this issue.

Issue 3355 has been merged into this issue.

Issue 1172 has been merged into this issue.

Issue 3183 has been merged into this issue.

Issue 3530 has been merged into this issue.

Issue 3569 has been merged into this issue.

Solved or not??

Even with r6495 Wii Sports Resort still crashes randomly...

In r6495 Wii party freeze randomly (tested one time and it freeze), DKC freeze, Wii Sport resort freeze, in Smg I lost about 9-10 fps, (r4680 52-53 fps, r6495 42-44 fps) Anyway an improvement for wii party (first I can't play footbal minigame), obiouvsly probably I didn't tested other games and this last rev may have fixed other issues with other games! Maybe reverting r6483 as skidau said, I will regain that 9-10 fps! There's still a bit to work on this issue, but r6495 is a big step!:)

Same here: Wii Sports Resort still freezes with r6495.

Issue 3642 has been merged into this issue.

CCing the person who seems to be doing an amazing work with the fifo lately :)

Im sure of 4 Things. 1) Common::AtomicStore(_fifo.bFF_GPReadEnable, false) in the FIFO is a HACK The VideoPlugin dont use this and SMG works. 2) The actual manage of HI & Lo watemark is wrong. 3) CLEAR_REGISTER is for wait until the FIFO is empty (TRUE, TRUE) is for empty FIFO and TRUE FALSE is for empty yo HI watemark. 4) The events for interrupts need to excuting in the tight time. IS ONLY QUESTION TIME TO FIX ALL FIFO

Wii Party mybe is a little different, because it freezes (both in SC and DC mode) very often when you finish a mini-game and the icon for choosing to replay or go back to menu should appear, instead they don't appear and you get a freeze with 0 fps...

Just a little recap of what's happening at the moment with the "Wii X" games on my system (e8400, HD4850, WinXP SP3 32-bit) with r6554:

• Wii Sports (fully playable even in Dual Core mode - till now I haven't yet experienced a single crash and I keep my finger crossed:-));

• Wii Play (freezes in Dual Core mode, but it's not a problem since Single Core mode works ok with full speed and no crashes);

• Wii Sports Resort (freezes in Dual Core mode and it's playable with Single Core mode, although a bit too slow 40/60 fps);

• Wii Party (during different games I've not yet experienced any freeze in both Single and Dual Core mode, unfortunately the game freezes randomly with every configuration after finishing the mini-games, when the pink icons for choosing to replay or go back to menu should appear - sometimes, very often, they don't appear and so you're stuck with 0 fps).

Hope this helps...