New trouble with ZTP

[leba2]

Well, now at least it doesn't freeze with the "Loading..." title when enabling Dual Core, but it freezes just when about to start the intro animation, when Link is in Epona at the entrance of Hyrule. Hell, I have to disable DC in order to get past it and try to endure the 1 FPS gameplay. Well, maybe my rig has really become a crap... but anyways does anyone has been able to play a bit ZTP with DC enabled? This has happened to me either with the official last stable release and the SVN ones.

Also I keep getting the same errors saying "Failed to load plugins PadSimple" and "VideoDX9". I don't know what's up with them...

__________________
Laptop Dell Inspiron 1520
Windows Vista Home Premium
Intel Core 2 Duo T7700 2.4 GHz
2 Gb RAM DDR2
Nvidia GeForce 8600M GT 256 Mb (drivers up to 185.85)

[jasong]

Your rig is ok. What version of Dolphin are you using?

[COWBOYJESUS]

A while ago I came up with a rather ghetto solution to the freeze problem in TP. Right before a state transition (eg. from the Dolby logo to the intro) save and reload a state--you may have to reload several times. Doing this prior to any transition will prevent the game from hanging in Dual Core during that transition.

EDIT: It can be a little cumbersome to do, but it becomes less of an issue after the beginning. I also recommend you try to time the savestate as close to the actual transition as possible, as that seems to increase the odds of success on the first reload.

Very ghetto solution I know, but it works.

---

Last edited by COWBOYJESUS; October 17th, 2008 at 06:44..

[omegadox]

It sounds like you have dynamic recompilation disabled. Also ZTP is buggy in DC, I did the same savestate load method as what COWBOYJESUS did, but switching rooms can hang on you. You get the those load errors because you need to update your DirectX, which is mentioned in the "Broke Games List" sticky. Please note that we have FAQ for dolphin now in that sticky.

[memberTwo]

Yes, I'm working on this DC issue but I'm stuck atm. ZTP is the only game I know (so far) that hangs in DC but not in SC. I think the problem is more deep than I thought at first.

Here is the simplified picture:
on real gc there are a CPU (producer), a GPU (consumer) and a CPU/GPU communication device: CP (Command Processor). As usual CPU and GPU run concurrently.

- now on Dolphin SC mode, obviously, the concurrency is faked. Then we hear "it works, it works!"... Good, some CP emulation's stuff are bypassed and it's ok (maybe with a tiny piece of luck ).

- on DC mode it's another story since we attend to emulate that concurrency. We have a CPU thread and a GPU thread. This required a more strict CP emulation. The annoying thing is CP is not completely documented then we could miss some important features.

I need to understand well the CP atm and we'll try to guess unknown stuff...if needed... Not sure yet but I'm afraid it is. This ZTP DC bug makes me believe that.

Guys, if you find other games that works on SC mode and fails on DC please report.
Here is better: Issue 225 - dolphin-emu - Google Code
You could also start a "SingleCore mode OK but DualCore mode KO" thread here too.

And for tough guys ... If you "guess" well CP's missing registers (http://hitmen.c02.at/files/yagcd/yagcd_missing.txt). PM me and I'll buy you your weigh of virtual beer

edit:
for info: DC mode have changed in r791. Report if it breaks things too.
http://code.google.com/p/dolphin-emu...e/detail?r=791

---

Last edited by memberTwo; October 17th, 2008 at 09:32..

[omegadox]

Here is a diagram of that

[memberTwo]

omegadox: thirsty?

5.    Hardware_Registers
5.1   CP_-_Command_Processor

*** register unknown ***
    0xcc000006
    0xcc000008
    0xcc00000a
    0xcc00000c
    0xcc000018
    0xcc00001a
    0xcc00001c

the 0xcc000006 reg is set to 0x0000 just before the hang in ZTP with DC on. Don't know if it means something important but this write16 is retried later but not on SC.

[omegadox]

wow, just one register. I hope you can figure what that value is used for :P. Have to find why the game has to hang, you may have disassemble the game's code. =\.

[John Peterson]

Originally Posted by memberTwo

Yes, I'm working on this DC issue but I'm stuck atm. ZTP is the only game I know (so far) that hangs in DC but not in SC.

Thanks for trying to solve this. I'm sure you've seen this but I'm going to repeat it anyway in case it helps. I found that the hanging-on-loading issues seems to disappear when you interpret instead of JIT lwz, and it's only needed when offset = 0. There also seems to be some difference between the "Safe and boring" and "Fast and daring" JITs, safe and boring seems to hang less often on loading. But as ector said it's probably not a problem with how the JIT conversion of lwz is done but rather something else. And I guess you are on the right track. Good job

---

Last edited by John Peterson; October 17th, 2008 at 18:15..

[memberTwo]

Originally Posted by John Peterson

lwz

lwz?... lwz!... LWZ!!!
Hey, John, you're giving me an idea... I think you're closer of the problem than me... Either way I still don't think about a jit bug.
Could be a really twisted sync issue... Some games could deal with the sync by software. I mean without using "normal" GX's API... May be wrong, I've got to check that.

[NeoSlider]

Originally Posted by memberTwo

ZTP is the only game I know (so far) that hangs in DC but not in SC.

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.

__________________
OS: Windows Vista Ultimate x64
Processor: AMD Phenom II X4 965 Black Edition @ 3.8Ghz
Motherboard: Gigabyte GA-890GPA-UD3H 890GX
Memory: 4GB DDR3 1600MHz/PC3-12800 Kingston HyperX
Graphics Card: NVIDIA GeForce 8800GTX 768MB

[John Peterson]

Originally Posted by memberTwo

lwz?... lwz!... LWZ!!!
Hey, John, you're giving me an idea... I think you're closer of the problem than me... Either way I still don't think about a jit bug.
Could be a really twisted sync issue... Some games could deal with the sync by software. I mean without using "normal" GX's API... May be wrong, I've got to check that.

I looked at this a little more and saw that the game does a second round of CP register reads and writes (mostly writes) when DC is on, and right before execution hangs in SelectThread. It also runs a function called diagnoseGpHang() for example. That's sounds like sings of trouble with the CPU-GPU distance or something similar to that. I tried to blr some GX fifo functions and to change some CP registers but I couldn't really get anywhere with it. The reason it hangs when a map is loading may be because the CPU-GPU sync is allowed to get really bad in those cases. But Dolphin already seems to have zero tolerance towards fifo.CPReadWriteDistance because CP.cpp has if(... fifo.CPReadWriteDistance > 0 ...), so I'm not sure what to do next.

Another strange JIT thing was that it seemed like the opening (first 3D) screen would begin loading when I interpreted cmpli (integer opcode) instead of jiting it. But it may be some kind of coincidence.

More on the hanging. Now that I added milliseconds timestamps it seems like the game hangs in about 0.1 seconds after the GX fifo checks begin. First I get a few GXAbortFrame, then GXFifoReadDisable, GXWriteFifoIntEnabl, GXSetGPFifo, GXFifoLink, GXInit, GXClearGPMetric then the logging stops.

---

Last edited by John Peterson; October 19th, 2008 at 02:14.. Reason: Automerged Doublepost

[memberTwo]

Originally Posted by NeoSlider

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.

Thanks for the info.

Originally Posted by John Peterson

I looked at this a little more and saw that the game does a second round of CP register reads and writes (mostly writes) when DC is on, and right before execution hangs in SelectThread. It also runs a function called diagnoseGpHang() for example. That's sounds like sings of trouble with the CPU-GPU distance or something similar to that.

Agree, the "second round" is just a something-went-wrong-let's-try-to-recover-by-myself.
The sync in DC mode is way more complicated than I thought because it involve sync with GP, CP, PE, VI and PI (for PI irq).
Atm, I assume (hope) the CP<->CP<->PI sync is quite ok (besides unhandled watermark irq and maybe some PI irq xchg). Not optimum but "safe" (you saw the spin loops in CP -> r16/w16/GatherPipeBursted).
Now I'm focusing on the GP<->PE<->PI sync issue. Look at that:

DC+Interpreter:

64.120291 345519: 22aef946 PE ( 8035ed20 ) : VIDEO Set Finish
64.120313 345521: 22aef946 PI ( 8035ed20 ) : Setting Interrupt INT_CAUSE_PE_FINISH (set)
64.120322 345522: 22aef946 Video ( 8035ed20 ) : GXSetDrawDone SetPEFinish (value: 0x02)
64.120331 345523: 22aef946 GEKKO ( 8035ed20 ) : EXCEPTION_EXTERNAL_INT
64.120381 345524: 22aefa26 PE ( 8035c60c ) : (r16): 0xcc00100a
64.120397 345525: 22aefa26 Video ( 8035c60c ) : Invalidate	(vertex cache?)
64.120401 345526: 22aefa28 PE ( 8035c614 ) : (w16): 0x000b @ 0xcc00100a
64.120418 345527: 22aefa28 Video ( 8035c614 ) : Invalidate	(vertex cache?)
64.120422 345528: 22aefa28 PI ( 8035c614 ) : Setting Interrupt INT_CAUSE_PE_FINISH (clear)
64.121033 345529: 22af0c69 GEKKO ( 8035f870 ) : [Scheduler] AudioFifoCallback     (584374500, 584374500) 
64.121579 345530: 22af206e GEKKO ( 80339cf8 ) : EXCEPTION_SYSCALL (PC=80339cf8)
64.123518 345531: 22af65ad GEKKO ( 80339cf8 ) : EXCEPTION_SYSCALL (PC=80339cf8)
64.124789 345532: 22af92f4 GEKKO ( 80339cf8 ) : EXCEPTION_SYSCALL (PC=80339cf8)
64.125468 345533: 22afaa9d GEKKO ( 800544fc ) : [Scheduler] VICallback     (584415000, 584415000) 
64.125853 345534: 22afb7a7 GEKKO ( 80339cf8 ) : EXCEPTION_SYSCALL (PC=80339cf8)
64.127721 345535: 22b003cc PE ( 80341148 ) : VIDEO Set Finish

DC+Jit:

6.992166 346093: 0 PE ( 8035026c ) : VIDEO Set Finish
6.992189 346095: 0 GEKKO ( 80341144 ) : [Scheduler] SetFinish     (603815284, 603814543) 
6.992192 346096: 0 Video ( 80341144 ) : GXSetDrawDone SetPEFinish (value: 0x02)
6.992208 346097: 0 PI ( 80341144 ) : Setting Interrupt INT_CAUSE_PE_FINISH (set)
6.992231 346098: 0 DSP ( 8034fcd4 ) : DSPInterface(r16) 0xcc005030
6.992247 346099: 0 DSP ( 8034fcd4 ) : DSPInterface(w16) 0x8069 0xcc005030
6.992248 346100: 0 Video ( 8034fcd4 ) : Invalidate	(vertex cache?)
6.992263 346101: 0 DSP ( 8034fcd4 ) : DSPInterface(r16) 0xcc005032
6.992269 346102: 0 Video ( 8034fcd4 ) : Invalidate	(vertex cache?)
6.992279 346103: 0 DSP ( 8034fcd4 ) : DSPInterface(w16) 0xeba0 0xcc005032
6.992298 346104: 0 DSP ( 8034fcd4 ) : DSPInterface(r16) 0xcc005036
6.992313 346105: 0 DSP ( 8034fcd4 ) : DSPInterface(w16) 0x8046 0xcc005036
6.992367 346106: 0 GEKKO ( 8033b608 ) : EXCEPTION_SYSCALL (PC=8033b608)
6.992422 346107: 0 GEKKO ( 80341144 ) : EXCEPTION_EXTERNAL_INT
6.992426 346108: 0 PE ( 80341144 ) : VIDEO Set Finish
6.992440 346109: 0 GEKKO ( 80000500 ) : [Scheduler] SetFinish     (603848792, 603848792) 
6.992447 346110: 0 Video ( 80000500 ) : GXSetDrawDone SetPEFinish (value: 0x02)
6.992459 346111: 0 PE ( 8035c5f0 ) : (r16): 0xcc00100a
6.992477 346112: 0 PE ( 8035c5f0 ) : (w16): 0x000b @ 0xcc00100a
6.992491 346113: 0 PI ( 8035c5f0 ) : Setting Interrupt INT_CAUSE_PE_FINISH (clear)

ouch that's bad!

Originally Posted by John Peterson

I tried to blr some GX fifo functions and to change some CP registers but I couldn't really get anywhere with it. The reason it hangs when a map is loading may be because the CPU-GPU sync is allowed to get really bad in those cases. But Dolphin already seems to have zero tolerance towards fifo.CPReadWriteDistance because CP.cpp has if(... fifo.CPReadWriteDistance > 0 ...), so I'm not sure what to do next.

Another strange JIT thing was that it seemed like the opening (first 3D) screen would begin loading when I interpreted cmpli (integer opcode) instead of jiting it. But it may be some kind of coincidence.

More on the hanging. Now that I added milliseconds timestamps it seems like the game hangs in about 0.1 seconds after the GX fifo checks begin. First I get a few GXAbortFrame, then GXFifoReadDisable, GXWriteFifoIntEnabl, GXSetGPFifo, GXFifoLink, GXInit, GXClearGPMetric then the logging stops.

yup... coincidences IMHO. Again if it's a sync issue you could find some random hack that seems to solve the problem for a while with lucky timings.

We definitely need to understand well how GP/PE/VI/CPU are synchronized on a real gc and it's not for today. I barely imagine the speedup when it will be done... W or WO a better idle skipping

Btw, John, where/how did you get those exact API symbols? I use totaldb.dsy from googlecode and I don't have any diagnoseGpHang for example.

[omegadox]

ZTP DC will boot ok under DX9 with idle skipping disabled.

[leba2]

Thanks for all help, sirs, although since I'm new on programming (especially on C++), I think I'll need to re-read this entire thread before asking for related help. Also, for the first guy who asked, I tried the last revisions and the last stable official built. ZTP DC freeze happens on all, but let's talk about the last one (SVN's are not supported).

Also, how can I upgrade the DirectX, or at least if it's needed? Since I'm on Vista and with an Nvidia 8 series, it works with DirectX 10, which supposedly has an "emulator" of DirectX 9... well, that's all what I know.

__________________
Laptop Dell Inspiron 1520
Windows Vista Home Premium
Intel Core 2 Duo T7700 2.4 GHz
2 Gb RAM DDR2
Nvidia GeForce 8600M GT 256 Mb (drivers up to 185.85)

[Dax]

Just update DX in general with MS's web updater. It updates both 9 and 10.

__________________

My PC Specs|My Consoles|Emu SVNs|Project OSX|How to ask a Question

[John Peterson]

Originally Posted by memberTwo

Btw, John, where/how did you get those exact API symbols? I use totaldb.dsy from googlecode and I don't have any diagnoseGpHang for example.

It's from the map file on the disc. It's in map > Final > Release > FrameworkF.map. They somehow decided that everyone that owns the game should also have a map file for the DOL. To bad they didn't use it for the advertising. They could have written something like "Does your kid also enjoy reverse engineering? In that case, bundled with the game is a complete memory map to get him started."

[memberTwo]

Originally Posted by John Peterson

It's from the map file on the disc. It's in map > Final > Release > FrameworkF.map. They somehow decided that everyone that owns the game should also have a map file for the DOL. To bad they didn't use it for the advertising. They could have written something like "Does your kid also enjoy reverse engineering? In that case, bundled with the game is a complete memory map to get him started."

Ector told me that "nintendo is sloppy" but I was too lazy to find the right file. Nice, thanks

[leba2]

Well, finally updated DX and gotten rid of the plugins errors (even with SSBM sound worked, I just would wish more speed, considering that 6.5 fps felt like 25 or somewhat). Finally ZTP booted with DC enabled, but was the same as disabled. Even with DC the Nintendo and Dolby logos ran at 3 fps -and in this game 3 fps don't feel by any means like 17 fps-. I realized that, at least in this game, it's not DC which apparently adds speed, but Dynarec is. However, for some reason Dynarec and DC don't get along each other, whenever both are enabled the game frezzes just after the Dolby logo.
Does anyone have a viable suggestion for a rig like mine rather than just switching to the real GC or another better rig? Thanks.

__________________
Laptop Dell Inspiron 1520
Windows Vista Home Premium
Intel Core 2 Duo T7700 2.4 GHz
2 Gb RAM DDR2
Nvidia GeForce 8600M GT 256 Mb (drivers up to 185.85)