Emulator

I can't see menus either :P. k, WXP SP3, r791, using DX9, HLE, nJoy.

PAL version of Metroid Prime, just press A, and the emulator exits without error or
warning.

This only happens in DC mode, in SC mode i can get to the intro and play but as soon
as i fire the weapon, the emulator closes in the same way.

This only happens on the PAL version of the game. Weird, maybe that version checks
for more stuff and fails?

First off I have the NTSC version of MP. By the way I can't see the menu text either
(Both dual core and single core). The big platform that Samus's ship lands on, goes
through the planet.(lol?) Samus's gun is also invisible. As far as I can tell DC
works fine. I'm at the part were u have to use the scanner (lol i forget which button
to push). Might have to pull out the dusty instruction book.

I have a PAL version of MP1 and it works in DC. federelli, redump your MP1 maybe.

off topic: in both mode my MP1 often crashes after intro just when entering in FPS
view. Have you noticed the same thing?

Yeah 99% of the times it crashes as soon as you gain control of Samus, but sometimes
you get to move her around a bit before the crash.

ZTP hang at start a bit after logo only with DC on.
I have noticed lot's of gatherpipe writePtr reset to base addr in DC mode. I have to
check how fifo linkage for gatherpipe is done in SC.

reported by NeoSlider:
(http://forums.ngemu.com/dolphin-discussion/112856-new-trouble-ztp.html#post1481470)
"Starfox Assault also hangs before the title screen if you have DC enabled but it
works fine in SC mode. It used to work in DC in an old Rev but I'm not sure exactly
when it stopped."

Didn't check with this game yet but ZTP seems to required a missing CP->PI interrups
to go further logos. So OvHi/UnLoWatermarks interrupts helps after all >> .
I have a fix but it slowdown MP1 (maybe others) in DC... not satisfied yet.
To be continued...

ZTP logo hang bug:
CPU wait for a PEFinish irq that never come. Interrupts between GP/CPU in DC mode may
need a better scheduled irq queue. That reminds me the bypass bug of HW1.

Well, pretty easily hackable but very ugly.
eg:

• we can count VI irq and raise a PEFinish if over a threshold (over 20 CPU attempts
  self-recovery that fails due to lack of fifo metrics and reset stuff).
• more brutal: we can raise a PEFinish each time a VI_POST_RETRACE is cleared.

I don't want to submit this until a per game hack engine.

GP breakpoint sync system:
is hacked atm: Breakpoint is set once but never clear so CPU thinks, more or less,
"wow my GP is pretty fast". Could be the cause of video stuttering in MP1.
The clean way doesn't work atm. BTW, IMHO BP interrupt is clear on CPIntEnable
raising edge and not just when CPIntEnable = 1.

DC still in WIP...

here is a ugly DC patch that kick a bit PPC when needed.
Well at least it prove irq mess issues.

You have to tweak a bit the threshold (videointerface.cpp->KickCPUThread()) for your
PC spec.

I can't load a stage when Dual Core is enabled in Mario Kart: Double Dash. It's just
turns black and it freezes. :)

Same problem here, but it has been broken since a while, I've just tried revision
1058 and is also not freezing before start any stage

Ah, okay. Well, forgot to tell that I did use Dolphin SVN r1157. It works okay if you
do a savestate in stage in Single Core mode, and enable Dual Core, then use the save
state and you can play with an decent speed if you have a good computer.

I'm not sure when but in the last couple revisions Dolphin now crashes with Dual Core
Enabled while stopping the emulation with the stop button.

I plan to give back, to GP, its asynchronous behavior in a more native way. This
because, GP can be slower than expected by CPU. So fifo's Hi/LoWatermarks strict
emulation is pointless (ie. the gc way to deal with GP/CPU load balancing)
As said in comments:
// * raise watermark Ov/Un irq: POINTLESS since emulated GP timings can't be
accurately set.
// Only 3 choices IMHO for a correct emulated load balancing in DC mode:
// - make our own GP watchdog hack that can lock CPU if GP too slow.
// - hack directly something in PPC timings (dunno how)
// - boost GP so we can consider it as infinitely fast compared to CPU.

hack "1)":
I chose "GP watchdog" (WIP). The spinlock in gatherpipe sucks. Maybe I have to put it
directly in advanceCallBck.

I don't know how to hack properly PPC timings (I think it's the best solution though :p )

• another scheduled fake_watchdog event in the "scheduler"?
• catch DECREMENTER_EXCEPTIONs and make some frame finish checks?
• ...

hack "2)":
iirc, only GP breakpoints can be bypassed by this hack. But, since GP BP system is
already hacked (BP can be set just once), it shouldn't be a problem. Either way, I'm
not sure losing this BP feature is worth it.

I know I'm walking on eggs with those hacks atm, but I'm pretty sure it could be
completely fixed for the next release :)

Ok now I know PPC frame-finish wathchdog is PPC-cycle dependent since there are tons
of negative feedback on different PC specs. RTC doesn't seem to be involve afaik
(can't be sure after all).

So only 2 choices now:
// - hack directly something in PPC timings
// - boost GP so we can consider it as infinitely fast compared to CPU.

I'm working on the first one.

Ok guys we need r1210 tests on your machine. Reports if any bug still present in DC
but not in SC (besides sound). Reports if SC is faster than DC too :p . Don't use
idle skipping plz, it's not mature for DC yet. Don't forget to mention if you use 32b
or 64b. Thx :)

For me compared to SC:

• ZTP: faster and as "well" as SC.
• ZWW: same
• MP1/MP2: same so far but may break though. (They have special stuff that may break
  in DC)

on linux I don't see any improvement in FPS in any game..
I wonder..

DC really helps in windows.

is it time to mark it as fixed?
I haven't heard a DC complaint in a long time now

I don't know, the GameCube version of TP can actually play now with R1523. I think
you can still get different
results with some games if you load them a second time or run a different game in
the same session.

I'll have to check, pcsx2 has been taking up my time lately. :p

PS: Running another Wii game a second time after loading a Wii game at start up
still results in a JIT error. Ew. :(

EDIT: I checked the Wii version - it's fine now.

Last time I tried DC mode (R 152X), random bugs occur in any game (freeze, program
crash, etc), it seems DC still causes memory corruption. mb2, try to beat (or get
far) ZTP or something(with DC + IdleSkip + Dynarec settings) without any errors/problems.

I've had random hangs/emulator closes as well, but nowhere near as many as before.

Yes random hangs/crash for me too. I have no more the good old debugable "GFX fifo
out of sync" messagebox. That's really annoying... well trickier :P

Since it happens for me when CPU-core is heavy loaded (DC+IdleSkipping+DSP_NULL), I
suspect the videoplugin's dirty reads. When videoplugin attempts to read gc memory
directly, I'm still not sure CPUThread have well committed (from cache to RAM) the
whole necessary data requested by videoThread.
Since it's the only lead I have, I plan to find a way to force a
CPUThread/core-cache-flush to find out. Don't know how to do that yet. Maybe someone
of you have an idea.

sounds more like idle skipping bug then?:)

It reminds me...
I thought Omega told me it happens without idle skipping too but I realize he had AR
trouble. Could be a AR bug AND idleskipping bug. Ok that's not clear for me.

Can someone (2 at least) confirm those hangs/crashes happen without idle skipping AND
without cheats plz?
(DC ON, DSP_NULL, Cheats OFF, IdleSkipping OFF)

forgot to say: with "Safe Texture cache" ON too.

eg: I always have a crash/unknown address in Super Monkey ball, when I let the intro
run for a while, only with IdleSkipping ON.

"Since it's the only lead I have, I plan to find a way to force a
CPUThread/core-cache-flush to find out. Don't know how to do that yet. Maybe someone
of you have an idea."

There is no such thing - on x86/x64, all caches between SMP cpu:s are guaranteed
coherent.

Gah... Now I'm confused.

By the way, my Super Monkey Ball issue strangely looks the same as Daco's TS2 one (i403)

Getting AR errors randomly in ZTP with DC enabled and IdleSkip disabled. No AR
problems in SC mode even with IdleSkip. Could be a bug in the Command Processor
where it starts overwritten random parts of memory.

DC Since later revs about between 1880-1980 leads Metroid Prime 2 to freeze with
strange bug-here the description: http://forums.ngemu.com/dolphin-
discussion/117482-gc-metroid-prime-2-echoes-official-thread.html#post1572475
and MP1 & MP2 have huge random slowdowns since that time

Issue 563 has been merged into this issue.

Issue 496 has been merged into this issue.

Is DC still unstable?

No, not as far as I can tell...

yep, there are still some problems with DC, one that I know is a reproducible crash
in ToS, while it works using single core.
There might be other issue as well, but i know this one for sure...

ahah marcus :p
see issue 686 for more infos.

ok, it's stable for 99% of games...

Is that good enough to close this?

I Don't think so, no.

:)

Basically the issue remains in savestates, so you may rename this issue if you want to.

Using savestates and loading in SC is somewhat safe.
Using savestates and loading in DC is not recommended at all, unless you want to
waste lots of valuable time.

FYI, still issues in the Metroid Prime series with Dual Core, I get freezes and then
it crashes with "game wants to go to memory card manager, BIOS is being HLE'd, so we
can't do this."

Save states still don't work right with dual core enabled... -_-"

Probably nobody took a look at that... yet :)

I was able to beat pikmin in DC with only save states :)

has any work been done on this lately?

it seems perfectly stable to me.

That's what I thought but some people are disagreing

MP1 still hangs randomly when loading, not much when saving. Same as 2000 revs ago.
Using r3171

In my opinion, this is a big one to get fixed before a "official non svn number
riddled release". I think after sound, this should be looked into. Many people are
complaining revision by revision that the speed/timing/projection issues are getting
worse. This might also play a big hand in compatability.

That's my opinion anyway, get sound working first. thx~

It has gotten incredibly better in the last revs, i guess sound had a lot to do with
it. Still, MP1 remains the unstablest game.

projection over all is fixed. Most issues are being caused from my testing by MSAA/EFB
or a combo of the 2. Timing is a huge issue. Some games currently jitter while playing
them like the frames are rendered in reverse time. kinda weird.

Ok guys, if someone want to takeover this issue then go ahead. I have no time for
dolphin atm.
And knuckles, I suggest you to lobby Nolan about DC... No, no I never mention his name :p

A lot changed lately, can someone make a list of issues and in what games they happen?

My personal opinion regarding this issue is to close it and open new tickets for each
individual issue, instead of just one big issue where we can't keep track of the
little problems.

Or, we could leave it open, and mark it as blocked by each of the smaller issues, and
then close it when it all those are fixed.

One thing is for sure: The current system is not working, as pointed out by the
comment above.

hmm, MP1 barely boot in DC now (r4338 at least).
I'll try to fix this.

And marcus, no please, considering game issues separately for DC bugs is too
dangerous. Fixing blindly one game may lead to many others broken. Games use several
ways to deal with fifo. And since I'm sure this number of ways is not infinite :p we
will find a suitable fix/hack for every cases. So we need a a strong DC test game
list reflecting those cases.

BTW, for those who wonders why DC mode==hack. Strict fifo and GP timings emulation is
practically impossible. Checking/Notifing/locking/unlocking for each fifo access
would slowdown dolphin like hell.

My DC test game list so far:

• MP1, MP2 -> fifo BP
• Super Monkey Ball 1 -> try to set RWdist and put pressure on CPU when fps is high
• ZWW -> regular but good for speed test
• ZTP -> heavy vertex and texture loading at start -> need fake watchdog
• Animal Crossing -> boot issues iirc
• pokemon XD -> never worked afaik. TOFIX -> note to self: fifo BP can't fire int cos
  RWdist==0 so the BP address check never happens.

MP1, MP2 and AC are broken again for me. Not sure the AC bug at boot is DC related
though.

Issue 1458 has been merged into this issue.

While playing Dairantou Smash Bros. X, I get the bug "detailed" in the attached
picture. Sometimes Soul Calibur II gets the same bug (or crashes completely, for the
same reason maybe).

Metroid Prime 2 (G2MP01) crashes in DC, but not in SC mode (R4800). In DC mode, the
game doesn't get beyond a black screen.
The last thing dolphin outputs is
"44:38:480 Source/Core/DiscIO/Src/FileMonitor.cpp:109 W[FileMon]: 5,631 kB
FrontEnd.pak" though I remember having seen different .pak files :/. But definitely
stalls while loading.

I'm using openSUSE 11.2 (32 Bit) with kernel 2.6.31.8 on an AMD X2 5200+.

I'd be glad to post more information (if necessary) or help otherwise.

Pokémon XD is playable in single core mode (don't know which revision fixed that) but
in dual core mode it breaks immediately with a graphics FIFO thingiee desync error.
Though it runs at 35%, though using JITIL speeds it up considerably in the menus. On
R4968