The behavior of the BIOS function/software interrupt CpuSet in mGBA differs from that of a real GBA BIOS.
In mGBA, when the software interrupt returns, r0 and r1 will both have been incremented by the number of bytes copied.
Using a real BIOS, when the software interrupt returns, r0 and r1 are unchanged.
Example code to reproduce:
.text
.syntax unified
.thumb
.align 1
adr r0, data
ldr r1, dest
movs r2, #3 @ 3 halfwords
swi 11
@ r0 and r1 should be unchanged
.align 2
dest: .4byte 0x02000000
data: .byte 1 2 3 4 5 6
sha256 of BIOS used: fd2547724b505f487e6dcb29ec2ecff3af35a841a77ab2e85fd87350abd36570
Build: 0.7.2
OS: Fedora 29 64-bit
I've reproduced this issue in Pokemon Emerald, where my code was working in mGBA but failing in Bizhawk in my TAS (BizHawk requires using a real BIOS). The code makes a lot of use of CpuSet.
The text was updated successfully, but these errors were encountered:
aarant
changed the title
Inconsistency with real CpuCopy
Inconsistency with real CpuSet
Sep 21, 2019
The behavior of the BIOS function/software interrupt CpuSet in mGBA differs from that of a real GBA BIOS.
In mGBA, when the software interrupt returns,
r0
andr1
will both have been incremented by the number of bytes copied.Using a real BIOS, when the software interrupt returns,
r0
andr1
are unchanged.Example code to reproduce:
sha256 of BIOS used:
fd2547724b505f487e6dcb29ec2ecff3af35a841a77ab2e85fd87350abd36570
Build: 0.7.2
OS: Fedora 29 64-bit
I've reproduced this issue in Pokemon Emerald, where my code was working in mGBA but failing in Bizhawk in my TAS (BizHawk requires using a real BIOS). The code makes a lot of use of CpuSet.
The text was updated successfully, but these errors were encountered: