Emulator Issues #2579
closedfifo changes in r4759 broke a few games
0%
Description
What steps will reproduce the problem?
1.load game
2.press start on title screen then choose new game
3.black screen and the music is playing
What is the expected output? What do you see instead?
on the black screen and the music is playing is the screen where you are
supposed to enter your name
What version of the product are you using? On what operating system?
using r5375
Win XP 32 bit
Please provide any additional information below.
this is correct on svn r4758 then on svn r4760 the game freezes up on the
very first loading screen,then on svn r4769 is when you get black screen
with the music playing
so it broke between svn r4758 and r4769 ( cannot find the others in between
only r4760)
Updated by nash679 over 14 years ago
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
Updated by nash679 over 14 years ago
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
Updated by Anonymous over 14 years ago
Issue 2563 has been merged into this issue.
Updated by Anonymous over 14 years ago
- Status changed from New to Accepted
note: r4759 is where the problems started...but other revisions changed the code soon after. r4762, for example.
p.s. it's a regular dev party!
Updated by Anonymous over 14 years ago
Issue 2242 has been merged into this issue.
Updated by Anonymous over 14 years ago
Issue 2123 has been merged into this issue.
Updated by Anonymous over 14 years ago
Issue 2482 has been merged into this issue.
Updated by Anonymous over 14 years ago
Issue 1898 has been merged into this issue.
Updated by mitjabamberger over 14 years ago
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.
Updated by wespipes69 over 14 years ago
So does this mean in single core mode the issue should not exist?
Updated by mitjabamberger over 14 years ago
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
Updated by mitjabamberger over 14 years ago
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.
Updated by wespipes69 over 14 years ago
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?
Updated by fjavier2k over 14 years ago
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
Updated by STLZ0001 over 14 years ago
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.
Updated by STLZ0001 over 14 years ago
Oh, and Super Robot Taisen GC hang was reported on issue 2563, check there for more
info.
Updated by nash679 over 14 years ago
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
Updated by nash679 over 14 years ago
Zatch Bell! Mamodo Battles (GC)
(freezes up on the very first screen (checking memory cards))
last worked on r4758 amd broke on r4759
Updated by nash679 over 14 years ago
issue 2235 and 1642 can be added to this aswell
Updated by Anonymous over 14 years ago
Issue 1642 has been merged into this issue.
Updated by Anonymous over 14 years ago
Issue 2235 has been merged into this issue.
Updated by Anonymous over 14 years ago
Issue 2430 has been merged into this issue.
Updated by fjavier2k over 14 years ago
Wii Play hang has been reported on Issue 2633
Updated by nash679 over 14 years ago
Timesplitters 2 (GC)can also be add to the list of broken games
Updated by Xtreme2damax over 14 years ago
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.
Updated by nash679 over 14 years ago
and also add The Incredibles : Rise of the Underminer (GC)
Updated by fjavier2k over 14 years ago
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.
Updated by mitjabamberger over 14 years ago
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.
Updated by mitjabamberger over 14 years ago
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 ;)
Updated by mitjabamberger over 14 years ago
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.
Updated by daco65 over 14 years ago
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...
Updated by daco65 over 14 years ago
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
Updated by nash679 over 14 years ago
ok all of the GC games that were broken by this are now running so i suppose this can be closed now
Updated by mitjabamberger over 14 years ago
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.
Updated by marcel.werner3 over 14 years ago
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.
Updated by skidau about 14 years ago
Issue 2368 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 2335 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 1904 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 2425 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 3284 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 2633 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 3318 has been merged into this issue.
Updated by skidau about 14 years ago
Issue 3355 has been merged into this issue.
Updated by skidau almost 14 years ago
Issue 1172 has been merged into this issue.
Updated by skidau almost 14 years ago
Issue 3183 has been merged into this issue.
Updated by skidau almost 14 years ago
Issue 3530 has been merged into this issue.
Updated by skidau almost 14 years ago
Issue 3569 has been merged into this issue.
Updated by hatarumoroboshi almost 14 years ago
Even with r6495 Wii Sports Resort still crashes randomly...
Updated by giaga7 almost 14 years ago
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!:)
Updated by fjavier2k almost 14 years ago
Same here: Wii Sports Resort still freezes with r6495.
Updated by skidau almost 14 years ago
Issue 3642 has been merged into this issue.
Updated by nakeee almost 14 years ago
CCing the person who seems to be doing an amazing work with the fifo lately :)
Updated by marcosvitali almost 14 years ago
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
Updated by hatarumoroboshi almost 14 years ago
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...
Updated by hatarumoroboshi almost 14 years ago
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...
Updated by marcosvitali almost 14 years ago
- Status changed from Accepted to Duplicate
Wii play, music, resort are fixed. The other issue maybe still valid, so merge this in fifo general issue.