Emulator Issues #11887
closed[Gecko] Gecko instruction 82/83/92/93 (store to Gecko register) always stores from 0x80000000 instead of from RHS
0%
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.
Updated by JosJuice about 5 years ago
- Milestone set to Current
- Regression changed from No to Yes
- Regression start set to 5.0-8985
Updated by shoutplenty about 5 years 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).
Updated by AdmiralCurtiss about 5 years ago
Does this fix it? https://github.com/dolphin-emu/dolphin/pull/8099
Updated by shoutplenty about 5 years 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.
Updated by JosJuice about 5 years ago
- Status changed from Fix pending to Fixed
- Fixed in set to 5.0-11179