Emulator Issues #3165


Crash with Zelda : Twilight Princess (Korean)

Added by comwiz.k over 12 years ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


What steps will reproduce the problem?

  1. Enable MMU Speed Hack (otherwise, it will crash or freeze(depend on Dolphin rev.) after game title and cannot progress)
  2. No matter GPU plugin.(DX9/DX11/OGL) I tested 3 of them.
  3. 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

  • 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?

  • Windows 7 and Windows XP

Please provide any additional information below.

  • Many other Korean users experience this problem. So, some Korean Bloggers recommend r4830 (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.
Actions #1

Updated by skidau over 12 years ago

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?

Actions #2

Updated by comwiz.k about 12 years ago

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

Actions #3

Updated by comwiz.k about 12 years ago

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.

Actions #4

Updated by skidau about 12 years ago

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.

Actions #5

Updated by skidau almost 12 years ago

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?

Actions #6

Updated by Anonymous over 11 years ago

  • Status changed from New to Invalid
Actions #7

Updated by comwiz.k about 11 years ago

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%)

Actions #8

Updated by skidau about 11 years ago

  • Status changed from Invalid to Accepted
Actions #9

Updated by comwiz.k about 11 years ago

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)

Actions #10

Updated by comwiz.k about 11 years ago

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?

Actions #11

Updated by comwiz.k about 11 years ago

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;

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
    inst = PowerPC::ppcState.iCache.ReadInstruction(_Address); //FAST_ICACHE

u32 inst = Memory::ReadUnchecked_U32(_Address);
return inst;

Actions #12

Updated by skidau about 11 years ago

comwiz.k, let me know if I have understood you correctly. Please check the PowerPC branch:

Actions #13

Updated by comwiz.k about 11 years ago

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.


Actions #14

Updated by skidau about 11 years ago

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.

Actions #15

Updated by skidau about 11 years ago

comwiz.k, I have made a change to the ICache code which will invalidate the JIT cache appropriately. Would you please test rc0498ca8314e?

Actions #16

Updated by comwiz.k about 11 years ago

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.

Actions #17

Updated by skidau about 11 years ago

Have committed some changes here: re03fd9a942e9

Please test if this game works. Let me know if there are any problems.

Actions #18

Updated by skidau about 11 years ago

  • Status changed from Accepted to Fixed

Fixed in r3d2a2abb49df


Also available in: Atom PDF