Project

General

Profile

Emulator Issues #11887

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

Added by shoutplenty 7 months ago. Updated 7 months 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.

History

#1 Updated by JosJuice 7 months ago

  • Regression start set to 5.0-8985
  • Regression changed from No to Yes
  • Milestone set to Current

#2 Updated by shoutplenty 7 months ago

the latter 2 lines of the test code should be:
82100002 80404454
82200003 80404458
(I was trying to do proof-of-concept with base addresses but forgot to set the base address or something like that).

#4 Updated by shoutplenty 7 months ago

Yes!

I replaced codehandler.bin with this patched one and it passed my tests above; 82x0 and 82x1 codes working as usual.
If I'm understanding correctly, codehandler.s compiles to codehandler.bin (dunno why both are in the repository).
codehandler.bin changed in precisely 3 bytes, all from 8C to 84, reflecting the 3 r12 → r4 changes.
Looks like a quick change to merge + test!
But thanks also for providing me with a codehandler I can use while we await the merge.

#5 Updated by JosJuice 7 months ago

  • Status changed from New to Fix pending

#6 Updated by JosJuice 7 months ago

  • Fixed in set to 5.0-11179
  • Status changed from Fix pending to Fixed

Also available in: Atom PDF