Open GoogleCodeExporter opened 8 years ago
I have another major counters revision currently being tested by Rama and
company.
It may resolve this issue. If testing goes well then it'll be posted to the SVN
within a day. So after it's up, try it out and let me know here if it's better
or not.
Original comment by Jake.Stine
on 18 Nov 2008 at 9:36
Please try Ecco the Dolphin with the new revisions (r345 or better) and let me
know
if it is playable now. Thanks.
Original comment by Jake.Stine
on 20 Nov 2008 at 12:19
Well... Tested it on r349... Bug is still out there...
Look at this log from r291:
...
MTC0 Breakpoint debug Registers code = 0
MTC0 Breakpoint debug Registers code = 0
MTC0 PCCR = 0 PCR0 = 0 PCR1 = 0 IMM= 0
IOP Recompiler data reset <--- here!!!
Recompiling COP2:00122140: vmul.xyz vf07, vf04, vf04
Recompiling COP2:00122140: vaddy.x vf07, vf07, vf07y
...and so on...
And this - from r349:
...
MTC0 Breakpoint debug Registers code = 0
MTC0 Breakpoint debug Registers code = 0
MTC0 PCCR = 0 PCR0 = 0 PCR1 = 0 IMM= 0
...a-a-a-a-and stuck... :-)
Maybe you should finish IOP counters part?..
Original comment by eliotfur
on 20 Nov 2008 at 12:26
Actually it looks like something related to the COP2. The MTC0 breakpoints are
related to the COP2 changing the PS2's memory address space, I think. And all
that
seems to tie back into when and how often cpuTestTIMR is called. Even subtle
changes
to counters can alter exactly when cpuTestTIMR is called, and that can break or
fix
games.
The IOP Recompiler data reset doesn't mean much except that the IOP is running.
It
never resets because the emulator's frozen. ;)
If I can find the spot(s) where cpuTestTIMR should be called immediately it
should
help big-time. But it's hard to do without being able to run the game directly
and
trace specific code that's running when it freezes. :/
Original comment by Jake.Stine
on 20 Nov 2008 at 1:22
I've created several logs to compare... From r262, r291 and r317...
I see a lot of difference there... BTW, can you advise me a good program to
compare
logs, totalcmd's file compare is somelike stupid...
I can see some difference in gs and vif interrupts...
And I don't know what am I trying to find...
Original comment by eliotfur
on 20 Nov 2008 at 4:12
Please test Ecco the Dolphin with r393 and let me know if it's crash bug is
fixed or
not fixed. Thanks. :)
Original comment by Jake.Stine
on 5 Dec 2008 at 5:03
No, it still doesn't work... Dig deeper...
Tested with/without MTGS and x2/x3 sync hacks just for sure...
Original comment by eliotfur
on 5 Dec 2008 at 9:50
Even sync hacks didn't fix it? Then I'm probably way off in my assumption.
Something else is breaking this game. I don't know if I'll be able to
troubleshoot
it without a block dump.
Original comment by Jake.Stine
on 5 Dec 2008 at 3:34
Anything resolved on this issue from recent revisions?
Original comment by Jake.Stine
on 17 Dec 2008 at 3:21
Nope... r441 with/without any speedhacks... Everything the same...
Original comment by eliotfur
on 17 Dec 2008 at 3:31
Go figure. So the very broken counters code in r291 allowed the game to start
and
run, and nothing else does. Go figure. Emulation is fun... :P
I'm relegating this issue to low priority. I'll try to revisit it sometime in
the
future.
Original comment by Jake.Stine
on 17 Dec 2008 at 6:39
Well, okay, it's me again...
I've just downloaded r658...
Well... Ecco the Dolphin works with _EE_x3_sync_hack_ enabled and IOP_x2_hack_
disabled only... Period(or ellipsis?).
Original comment by eliotfur
on 30 Jan 2009 at 6:15
Original issue reported on code.google.com by
eliotfur
on 18 Nov 2008 at 9:15