Emulator Issues #3165
closed
Crash with Zelda : Twilight Princess (Korean)
Added by comwiz.k about 14 years ago.
Relates to performance:
No
Relates to maintainability:
No
Description
What steps will reproduce the problem?
- Enable MMU Speed Hack (otherwise, it will crash or freeze(depend on Dolphin rev.) after game title and cannot progress)
- No matter GPU plugin.(DX9/DX11/OGL) I tested 3 of them.
- Enable EFB copy (no matter other options)
What is the expected output? What do you see instead?
- ZTP runs pretty well for some minutes(1~3 minute?), but Dolphin close itself(includes main window and process of itself) randomly without any error messages nor any logs.
Dolphin version with the problem? Other Dolphin version without the
problem?
- r4838 and 4830 can play ZTP-kor very well, except speed on Hyrul Field or some other places.(They don't have ZTP Speed Hack feature.) but r4839 or later Rev have same problem.
32-bit or 64-bit and any other build parameters?
- Both x64 or x86 have that problem
OS version and versions of tools/libraries used?
Please provide any additional information below.
- Many other Korean users experience this problem.
So, some Korean Bloggers recommend r4830
http://blog.naver.com/hypercd/80106206061 (in Korean Language)
They guess the reason is some bugs in clearing code cache and
they think that ZTP needs Unlimited JIT cache option.
But I think new MMU codes are the reason.
r4838 also plays ZTP normally and r4839 got MMU codes newly.
Would you please turn on Panic Handlers, turn off "MMU speed hack" and turn off "Enable MMU" and then copy and paste the error that Dolphin shows?
No error occur on r6189 though the Panic Handler option was enabled.
Game screen's just black and no response and 0 fps on titlebar.
There's no exceptioninfo.txt
Here's all records on Dolphin.log¶
16:11:641 .\Src\NANDContentLoader.cpp:207 E[DIO]: CreateFromDirectory: error opening ./User/Wii/title/00000001/00000002/content/title.tmd
16:11:938 .\Src\VolumeCreator.cpp:111 N[DIO]: SCBW_SYK0.iso does not have the Magic word for a gcm, wiidisc or wad file
Set Log Verbosity to Warning and attempt to load the game again to view the values
16:15:588 .\Src\Boot\Boot.cpp:164 N[BOOT]: Booting H:\Discs - Games/sqr-tloztp.iso
16:15:602 .\Src\Hle\HLE_OS.cpp:52 N[OSREPORT]: 812003d8->81300000|
Apploader Initialized.
16:15:602 .\Src\Hle\HLE_OS.cpp:52 N[OSREPORT]: 812003f4->81300000| This Apploader built Oct 2 2008 17:35:24 for RVL
16:15:895 .\Src\D3DBase.cpp:85 N[Video]: Successfully loaded d3dx11_42.dll.
16:15:990 .\Src\PowerPC\Interpreter\Interpreter_SystemRegisters.cpp:353 N[PowerPC]: Flush Instruction Cache! ICE=0
16:16:014 .\Src\PowerPC\Interpreter\Interpreter_SystemRegisters.cpp:344 N[PowerPC]: Instruction Cache Enable (HID0.ICE) = 1
16:20:342 .\Src\FileMonitor.cpp:109 N[FileMon]: 3,831 kB Audiores/Stream/title_back.ast
But on r5xxx, 3 error message occur :
WRITE: Invalid address: 4c000074
WRITE: Invalid address: 7cba03ba
WRITE: Invalid address: 7c6802b6
There are little improvements on r6194.
r6189 does crash at first Town scene(or before that)
But r6194 crash on beginning of the scene after first gamesave.
(r6194 stands longer!)
But MMU Speed Hack is still needed.
Are you able to compile your own builds? Can you try updating to r6199 and uncomment these lines in Source\Core\Core\Src\HW\MemmapFunctions.cpp
if ((_Flag == FLAG_OPCODE) && !(MSR & (1 << (31 - 26)))) return _Address;
if (((_Flag == FLAG_READ) || (_Flag == FLAG_WRITE)) && !(MSR & (1 << (31 - 27)))) return _Address;
Then test the game again.
Issue 3813 which is a similar report for the Japanese version of this game was found to be caused by a bad dump. Are you sure your ISO is not a bad dump?
- Status changed from New to Invalid
I tested again.
I did uncomment the 'if ~~' codes on r6553 (MemmapFuction.cpp) and build it (on vs2010sp1) But there's nothing changed.
It crashed down on the screen transition (when it get inside/outside a house).
According to the debugger, that was a memory execution violation
I also tested the game with r6115 built on DebugFast profile.
The error message "Self Modifying Code detected" has appeared on playing and then crashed down.
I have no idea whether the ISO image is correct or not.
But I think there's no problem on the image.
It can be run correctly with r4838. (or does r4838 have god's code?)
r6115 (and some previous builds with the ZTP hack) is fastest on Hyrul Field. (about 60~70% of speed)
r6116 ~ r6553 are slightly slower. (55~65%)
r6554 ~ current are slower than above (45~55%)
- Status changed from Invalid to Accepted
The RZDL01(ZTP Korean) have another problem on r4839 ~ r6003.
They can't get into Load data screen. (just after intro)
I tested many builds of Dolphin, and I realized that r6004 (and later ones) does not have the problem.
So I applied the diff of r6004 to r5115, then now it can play the game very well
(Also It doesn't crash at all!)
Now I continue to find out rest one of the problem (crash on playing)
RZDK01 try to run some instructions located on the memory address 0x4******* and 0x7c****** (so, the FakeVMEM(MMU Hack) option has to be enabled.)
It may be caused by broken ISO image.
By the way, the instruction would be swapped to other one by GetOriginalFirstOp(inst) on r5840. And then 'Cleared Code Cache' would be occured at that moment.
But r5841 and laters doesn't use Unlimited JIT cache anymore.
They can't handle the instructions.
Isn't there any solution?
I solve this problem.
The game tries to modify 0x80000500 (maybe External Interrupt Exception handler? ) using Write_Opcode_JIT().
But FAST_ICACHE can't recognize that modification at that time.
To solve the problem, add Read_Opcode_JIT(u32 _Address) function of old Unlimited JIT version to Memmap.cpp, and modify new Read_Opcode_JIT(u32 _Address) as below.
u32 Read_Opcode_JIT(u32 _Address)
{
static u32 Prevaddr = 0;
static u32 Previnst = 0;
#ifdef FAST_ICACHE
if (bMMU && !bFakeVMEM && (_Address & ADDR_MASK_MEM1))
{
_Address = Memory::TranslateAddress(_Address, FLAG_OPCODE);
if (_Address == 0)
{
return 0;
}
}
u32 inst = 0;
if ( (_Address & 0xFFFFFF00) == 0x80000500 )
inst = Read_Opcode_JIT_OC(_Address); //Old Funciton
else
inst = PowerPC::ppcState.iCache.ReadInstruction(_Address); //FAST_ICACHE
#else
u32 inst = Memory::ReadUnchecked_U32(_Address);
#endif
return inst;
}
That works very well. :)
But I don't know why the operand of the AND (&) is 0x0FFFFF00.
I don't have ever seen the PowerPC stuff or emulators of any computer system before.....:)
I guess.....Exception Handlers seems to be located on the other segments.
Thanks.
Yes, it is safer to not specify 0x80000000 because it is mirrored at 0x00000000 and 0xC0000000. The game can reference the same location from any of those addresses.
comwiz.k, I have made a change to the ICache code which will invalidate the JIT cache appropriately. Would you please test rc0498ca8314e?
I built the r18d9a275e70c and tested it.
It crashes down when I select saved data to load. (after the title)
It's so bad for ZTP-korean.
Have committed some changes here: re03fd9a942e9
Please test if this game works. Let me know if there are any problems.
- Status changed from Accepted to Fixed
Also available in: Atom
PDF