Project

General

Profile

Actions

Emulator Issues #11887

closed

[Gecko] Gecko instruction 82/83/92/93 (store to Gecko register) always stores from 0x80000000 instead of from RHS

Added by shoutplenty about 5 years ago. Updated about 5 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
5.0-8985
Fixed in:
5.0-11179

Description

Game Name?
Noticed on Super Mario Sunshine (E 1.00) and Zelda: Skyward Sword (J 1.00)

Game ID?

GMSE01, SOUJ01

MD5 Hash?

0c6d2edae9fdf40dfc410ff1623e4119; ca34457eb03dd6de35383f8439f4bf70

What's the problem? Describe what went wrong.

Any 82-type Gecko code, which should copy from the address specified in the second half into a Gecko register, always copies from 0x80000000. The register it copies to is still correct.

What steps will reproduce the problem?

Run this code on Super Mario Sunshine (E 1.00):
82200000 80404454
82000001 80404458
82100002 00404454
82200003 00404458
It should do the following:

  • copy 4B from 0x80404454 to Gecko register 0
  • copy 1B from 0x80404458 to Gecko register 1
  • copy 2B from 0x00404454 to Gecko register 2
  • copy 4B from 0x00404458 to Gecko register 3

You can use Dolphin Memory Engine to set 0x80000000 and view register N at 0x80001808 + 4*N.
Expected result at 0x80001808: some values that represent the buttons currently pressed on the controller.
Actual result at 0x80001808: GMSE...G..GMGMSE, or whatever's set at 0x80000000.
I also checked that 82x1 and 92x1 instructions also always copy from 0x80000000.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

5.0-11073

Is the issue present in the latest stable version?

Probably not.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

5.0-8985 ("Fix Gecko codehandler lag")

Bisect log:
Build 5.0-5880 marked as a GOOD build
Build 5.0-8364 marked as a GOOD build
Build 5.0-9690 marked as a BAD build
Build 5.0-8953 marked as a GOOD build
Build 5.0-9318 marked as a BAD build
Build 5.0-9180 marked as a BAD build
Build 5.0-9109 marked as a BAD build
Build 5.0-8989 marked as a BAD build
Build 5.0-8970 marked as a GOOD build
Build 5.0-8981 marked as a GOOD build
Build 5.0-8985 marked as a BAD build
Build 5.0-8983 marked as a GOOD build

What are your PC specifications? (CPU, GPU, Operating System, more)

Dell XPS 13 9360, i5-8250U (integrated GPU), 8GB RAM, Windows 10 Home v1903

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

That's all I have.

Actions

Also available in: Atom PDF