loading savestate shortly after starting emulation causes strange effects

[GoogleCodeExporter]

Linux distribution: Debian Lenny
Machine type: 32-bit
Mupen64Plus version: svn r1135
Plugins used: all

Example affected game:
THE LEGEND OF ZELDA
ec7011b7 7616d72b
5BD1FE107BF8106B2AB6650ABECD54D6

Summary:
If a savestate is loaded right after the emulation is started then
something bad happens. The exact effects seem to depend on the rom but they
usually render the game unplayable.

Example to reproduce:
compiled from svn, started with a clean ~/.mupen64plus directory,
loaded Zelda, went to main menu and savestated, then closed the rom.
Opened it again, hit F7 to load the savestate
(this has to be done within 1 or 2 seconds after starting emulation)

Now if I do this then I usually end up in one of two broken states:
1) Looks fine, but is running very very slow (~5fps)
2) Graphics totally corrupted, but seems to be at full speed
(This is for Zelda. The exact effects seem to vary from rom to rom. With
Mario64 I can even get it to crash: The Core thread recieved a SIGSEGV)

Once the emulation is in such a broken state the only way out seems to be
restarting the game. Trying to load another savestate did not work. I want
to add that all my savestates load perfectly fine if I wait 3 or more
seconds before loading them.

Original issue reported on code.google.com by ling.weak@googlemail.com on 30 Oct 2008 at 11:48

[GoogleCodeExporter]

Rendering problems are probably related to bug #51 (cannot create them after 
setting
floating point register mode after each savestate load). The slowdown can be
recreated from time to time.

Original comment by sven@narfation.org on 30 Sep 2009 at 2:46

[GoogleCodeExporter]

In "Legend of Zelda, The - Ocarina of Time (E) (M3) (V1.1) [!]" (MD5
D714580DD74C2C033F5E1B6DC0AEAC77) there is a "sw $t8, 0x0010($t0)" at 0x80003464
which results in a slowdown of the whole game when you load a savestate after 
that
instruction (if i did count correct it is instruction 8681963 without counting 
delay
slots).

$t0 is 0xFFFFFFFFA4500000
and
$t8 is 0x0000000000003FFF

The speed seems to be ok again after "sw $t9, 0x0010($t0) is executed after 
18441805
instructions without counting delay slots).

$t0 is 0xFFFFFFFFA4500000
and
$t9 is 0x000000000000060F

This memory region seems to be a special memory region. Writing is implemented 
by
write_ai in memory/memory.c 2778 ("case 0x10" for "switch(*address_low)". An
interesting function is here aiDacrateChanged(SYSTEM_PAL) - it is here handled 
by
jttl_audio/main.c. We must probably call that function when loading a savestate 
to
set the correct frequency.

Original comment by sven@narfation.org on 3 Oct 2009 at 1:12

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is an experimental patch which seems to work quite well for me.

Original comment by sven@narfation.org on 3 Oct 2009 at 4:17

Attachments:

• load_aidacrate.patch

[GoogleCodeExporter]

There seems to be an similar issue width video, but I couldn't find a rom which 
has
problems width it.

Original comment by sven@narfation.org on 3 Oct 2009 at 5:06

Attachments:

• load_vistatus.patch

[GoogleCodeExporter]

patches applied to Mupen64Plus v2.0 Hg repository

Original comment by richard...@gmail.com on 14 Nov 2009 at 6:09

[GoogleCodeExporter]

Can the original reporter please test with the latest code in Hg and tell us if 
this
bug still remains?

Original comment by richard...@gmail.com on 12 Jan 2010 at 5:16

• Changed state: Started

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 12 Jan 2010 at 6:04

• Added labels: Component-Core, Type-Defect

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 20 Jan 2010 at 4:06

• Added labels: Milestone-2.0

[GoogleCodeExporter]

I tested (latest Hg code) using the given steps to reproduce with Zelda, and was
unable to reproduce the bug; it worked perfectly every time.  Presumably ecsv's
patches fixed this problem.

Original comment by richard...@gmail.com on 28 Jan 2010 at 4:35

• Changed state: Fixed