Hi,
I spent some hours today of really boring debugging, but it was worth it.
For those that are in a hurry ;), here is the patch first:
diff -ur snes9x-1.43-dev-src.old/snes9x/snapshot.cpp snes9x-1.43-dev-src.zelda/snes9x/snapshot.cpp
--- snes9x-1.43-dev-src.old/snes9x/snapshot.cpp 2004-07-11 23:51:00.000000000 +0200
+++ snes9x-1.43-dev-src.zelda/snes9x/snapshot.cpp 2005-01-21 01:57:24.000000000 +0100
@@ -317,7 +317,9 @@
{OFFSET (BGMosaic), 4, uint8_ARRAY_V},
{OFFSET (OAMData), 512 + 32, uint8_ARRAY_V},
{OFFSET (Need16x8Mulitply), 1, INT_V},
- {OFFSET (MouseSpeed), 2, uint8_ARRAY_V}
+ {OFFSET (MouseSpeed), 2, uint8_ARRAY_V},
+ {OFFSET (OpenBus1), 1, INT_V},
+ {OFFSET (OpenBus2), 1, INT_V}
};
#undef OFFSET
It seems Zelda stores some important information about the Sprites in PPU.OpenBus1 and PPU.OpenBus2.
Adding those to the list of saved parameters in the snapshot file, seems to solve the desync problems with Zelda.
How I did it:
After trying _all_ possible Parameters in CPU (that were not yet saved) without much success (and spending hours of frustrating work), I had the right idea.
I outcommented the S9xReset() before loading a Snapshot.
And then I could notice, that when I loaded a savestate the sprites seemed to move around quite random.
So, there must be a variable, that is set, and if you do _not_ reset it, the behaviour is (almost) random.
So I did do the same with all functions in S9xReset allowing them to be just called once. (with a static first var, which is set to false after one going through)
I found out its in S9xPPUReset, then I used the same trick as above to corner the variable, which makes random behaviour. Finally I found them.
So, please test it and finally make a great Zelda-Time Attack!
cu
Fabian
PS: Could someone please forward this to Snes9x authors, if the patch works for you?