-
-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pc bit1 "undefined" state on GBA not properly emulated #2964
Comments
I'm pretty sure I correctly implemented part of this a few versions ago, but clearly not all of it. I'd have to dig through the log. It's related to some weirdness with an Emerald ACE payload misbehaving that merrp brought to my attention. |
Can you upload the ROM zipped? You can't upload .gba files but you can upload .zip files with .gba files in them. I think the specific issue is actually in the implementation of the Thumb BX instruction--I'm pretty sure the ARM BX instruction would work as intended here, but having an easy way to test would be much appreciated. |
Here it is: game.zip I could try to write more tests, but I don't have a GBA (I have an NDS-Lite though, but no flashcart), and also I have no idea what I should try to test. |
It looks like this bug was only present in the single specific case tested: |
After some discussion on the gbadev Discord server, it was found that
pc
has a "weird" behaviour when abx
instruction is executed to ARM state with a mis-aligned address (aka bit 1 set): while the CPU is able to "internally" align the address to fetch an instruction with correct alignment, onpc
the bit1 keeps set, which can lead to miscalculations in any instruction that uses it as an operand (such as pc-relative loads and stores).We can check the vaildity of this hypothesis with a very simple subroutine that gets the
pc
on such a state:(the source file is like this)
(I tried to upload a GBA ROM here, but GitHub doesn't let me)
On the hardware (tested by @evanbowman), the returned PC is what is expected by the above hypothesis:
On mGBA, however, the returned PC is aligned to the lowest word (
08001714
), contradicting the result on hardware.This aligns with what the ARM7TDMI Technical Reference says about bits 1 and 0 of
pc
on ARM state:Whether or not instructions having
pc
as an operand will correctly use the "correct" (aligned) program counter value is not tested (though I doubt, sincebl
in Thumb sets bit 1 oflr
).The text was updated successfully, but these errors were encountered: