you're 242, right?

Yep, I am. I wonder if this issue is known, couldn't find it in the list...

r2343, working here.

federelli, IL is working? What's your OS?

XP SP3

Just tried 2347 JITIL - still isn't working on XP32 SP2. With any settings of emul or
graphics plugin.

Unhandled Exception
Code: 0xC0000005
Call stack info:
DolphinIL!0x00469A53 : ?

Only ordinary 2347 works here, not JITIL, after 2276. I'm wondering if installation
of SP3 will help....

Installed SP3.

Still, SVN2347 JITIL can't run RE1. Tried various settings, as well
as both OpenGL and D3D plugins, no luck.

May be videocard matters?

My videocard is ATI HD3870 512Mb.

does it work with any other game ?

Update:

New IL revisions after 2276 do work, but ONLY when JIT dynarec is disabled, i.e. 2-3
fps obviously. Something was broken after 2276.

But many people say new ILs still work just fine (i.e. with JIT dynarec enabled).

sl1nk3.s,

I have only RE1 and RE0, just tried 2425 IL with RE0 - just the same, immediate error
on disc load (with JIT dynarec enabled).

AppName: dolphinil.exe AppVer: 0.0.0.0 ModName: dolphinil.exe
ModVer: 0.0.0.0 Offset: 0006ad93

exceptioninfo.txt:

Unhandled Exception
Code: 0xC0000005
Call stack info:
DolphinIL!0x0046AD93 : ?

PS:
My current config: C2D 2.4, Intel motherboard, WinXP SP3 32bit, Radeon HD3870, latest
DirectX 9.0c.

We got practically the same computer, it works wonders here, fullscreen, only bad
thing is it crashes randomly, and save states hardly ever work.

I got a C2D E6600, MSI 975X PUE, XPSP3 32bit, Visiontek HD3870.

federelli, ILs after 2276 run fine on your computer?

Now, what is the difference between our sutups that allows yours to work fine.....

About crashes, see issue #620, I had them too, but the problem is gone somehow. I use
2195 IL though.

1. Use 2195 IL
2. Try to restart your computer before playing, don't run anything prior Dolphin.

BTW, it's not a problem of only RE1, ILs can't run any game anymore here.

nah, i've the same problem compiling my own regular SVN builds. it always crash while
booting a game using JITIL...
But there's some guys on emuforums who seem to have tracked the bug as their builds
just run fine.

Same problem here, can't run any game in IL version after R2276 if dynarec is
enabled.

AppName: dolphinil.exe AppVer: 0.0.0.0 ModName: dolphinil.exe
ModVer: 0.0.0.0 Offset: 0006ab83

Exceptioninfo.txt

Unhandled Exception
Code: 0xC0000005
Call stack info:
DolphinIL!0x0046AB83 : ?

As weird as it sounds i've been getting this issue as well, you know what i did, i
created a new folder and moved the emulator there, issue fixed.
Something's being cached somewhere in Windows that the emulator does not like.

hmm.. no unfortunately i'm still getting the same crash, also it's the same behavior
for the weekly builds (http://www.dolphin-emu.com/downloads.php)

i've the same problem compiling my own regular SVN builds. it always crash while
booting a game using JITIL...
But there's some guys on emuforums who seem to have tracked the bug as their builds
just run fine.

Well, then where a newer revision compiled supposedly correctly can be found, don't
you know?
I tried download nightly builds, builds from official page, from Daco, from that
Japanese site - they all don't work.

fiiinally...
r2286 is to blame, if you revert r2286 changes then it works fine.
satanic666 from emuforums
(http://forums.ngemu.com/dolphin-discussion/107876-dolphin-svn-discussion-thread-284.html#post1596527)
had figured it since two week or so..

So, where new working IL builds can be regularly found?

Yep, satanic666's newer ILs really do work.
But almost everybody's else still don't.

Hmm... does reverting the change in r2286 to
Source/Core/Core/Src/PowerPC/Jit64IL/Jit_SystemRegisters.cpp by itself fix the problem?

did you mean reverting Jit_systemRegisters.cpp only ? it didn't work :\

although, just commenting the first part of IR.cpp that you added in r2286 do the
trick. So the following works :

if (getOpcode(*Op1) == FDMul) {
	// return FoldBiOp(FSMul, getOp1(OOp1), getOp2(OOp2));
} else if (getOpcode(*Op1) == FDAdd) {
	// return FoldBiOp(FSAdd, getOp1(OOp1), getOp2(OOp2));
} else if (getOpcode(*Op1) == FDSub) {
	// return FoldBiOp(FSSub, getOp1(OOp1), getOp2(OOp2));
}

So the problem is there, seems like it eventually die in a EmitBiOp() but it could be
the returned value too..

A guy who tried to run 32-bit ILs after 2276 (actually probably 2286 as he didn't try
every version) on 64-bit Windows wrote that they worked for him. BUT they hadn't
worked for him prior 2276.
A totally contrary situation here on 32-bit Windows :)

Issue 700 has been merged into this issue.

Is magumagu still around or did he forget about this issue ? :P
Can anyone cc: this to him ? (and rename the issue at the same time)

rename it to what?

marc...@cox.net, to something like "IL stopped to work after SVNxxxx" because it's
not only RE1 that doesn't start, but any game.
I'm not sure the revision number after which it stopped to work, but it worked on
2276 and 2195.

it's r2286, see http://code.google.com/p/dolphin-emu/issues/detail?id=620#c29

OK. Title changed.

I just did some debugging using the DebugFast configuration and JITTEST=1, it seems
that a LoadFReg Operation breaks at IREmitter::getOp1. With InstLoc i = 0x01080070 by
that time (*i = 7999), the fancy Pointer arithmetics at IR.h:91 return i - 1 - ((*i

8. & 255) = 0x0107fff0 - and thats outside the Memory locations Dolphin uses (it
   is off by 4 DWords/16 bytes).

I guess someone wanted a range check there, but got the wrong Operators ;)

Index: I:/Dolphin/svn/Source/Core/Core/Src/PowerPC/Jit64IL/IR.cpp¶

--- I:/Dolphin/svn/Source/Core/Core/Src/PowerPC/Jit64IL/IR.cpp (revision 2666)
+++ I:/Dolphin/svn/Source/Core/Core/Src/PowerPC/Jit64IL/IR.cpp (working copy)
@@ -326,7 +326,7 @@
if (Opcode == DoubleToSingle) {
if (getOpcode(*Op1) == DupSingleToMReg)
return getOp1(Op1);

•   if (getOpcode(*Op1) >= FDMul || getOpcode(*Op1) <= FDSub) {
  

•   if (getOpcode(*Op1) >= FDMul && getOpcode(*Op1) <= FDSub) {
    	InstLoc OOp1 = getOp1(Op1), OOp2 = getOp2(Op1);
    	if (getOpcode(*OOp1) == DupSingleToMReg &&
    	    getOpcode(*OOp2) == DupSingleToMReg) {
  

That will fix it?

It did for me, and I guess magu wanted to see if the Opcode was between FDMul and
FDSub. As the if-Statement is now, it checks if its either above FDMul or below
FDSub, which is always true.

Nice catch !
It's the right fix, I didn't noticed that these vars were enum values in the first
place, now it's obvious that this condition is dumb :p

OK, I'll commit it.

marc...@cox.net, does it fix 32-bit IL?
because I see the folder name of the edited cpp is called Jit64IL.

shrug
I don't even know how to do a IL build.

sergiy242 > this fix is for the 32-bits IL builds, the only one that works too :p
Jit64IL is just the name of the folder containing the code, just like Jit64 is the
name of the folder containing the standard JIT, whether you want to compile it
compile it in x64 or x86 is up to you, but it's still the same path, with a few
tweaks here and there.

Ah, that's what the issue was... thanks for spotting that.