jsmolka / gba-tests Goto Github PK

Hi,

I've been trying your Thumb test suite lately, and (at least) the test 170 and 171 removed in this commit are still present in the thumb.gba file provided with the source code.

Thank you for your attention,
Arignir

Expected results (tested on real hardware):

• stmdb_empty_rlist.asm: blue (R15 is stored at Rn-40h)
• stmib_empty_rlist.asm: green (R15 is stored at Rn+4)

Hey,

In https://github.com/jsmolka/gba-tests/blob/master/thumb/arithmetic.asm, on line 128, is the (trivial?) instruction "mov r0, r0" instruction expected ?

Is the instruction a typo i.e., should it be "mov r0, 0" (or something like it) to make more sense in the context of the test ?

Thanks,
Revanth

I was running the test against my own emulator, and couldn't figure out why it would go wrong. I checked the registers, and the value in R1 was not the value it was supposed to read, but it was 1 instead. First I thought the m_word macro might not have worked, but it did.

When checking out what happens in the SQRT SWI I found that it jumped to 0x404 in the BIOS, and ran these instructions right after the handler:

the SWI changes the value in R1!

It fails on some other emulators as well, and probably passes on mGBA because it HLEs the BIOS. You can probably simply fix the test by using R0 instead of R1, or some other register that is not changed.

Hey,

First off, I love these tests, thanks so much for publishing them and creating these. I just had one question and the README said to open an issue for clarifications so, here I am.

In this file:
https://github.com/jsmolka/gba-tests/blob/master/arm/data_processing.asm

Tests 224 and 225 contain instructions 0xE1A0001F and 0xE08F0010. My emulator fails on both these tests, and I'm having trouble resolving them because they contain undefined behavior. The undefined behavior is documented here on page 226 at the bottom of the page: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/third-party/archives/ddi0100e_arm_arm.pdf

Register PC can't be used as rm. And, I guess you all already know this instruction performs undefined behavior because you included it in an unorthodox way. I guess my question here is then, how do I resolve this? Is this some behavior that is specific to ARM7TDMI? My original guess was that using PC as rm causes it to be read as (PC + 8) due to pipelining. This is similar behavior to the LSL immediate addressing mode on page 225.

However, by looking at the tests we can see that this is not the case. Look at Test 224 for example. Using this logic, after line 320 runs, r0 is set to the address of the instruction at line 322. Which causes the CMP instruction after it to fail. Contrast this with Test 221, which adds 4 to PC to compensate for this.

What am I doing wrong?

gba-suite does not detect when tst r0, r1 actually acts as ands r0, r0, r1.
The same thing happened for TEQ. I did not test for CMP and CMN.

Is it always going to fail. Because pc is never updated for next instruction.
ldmia r0!, {}

First of all, thank you a lot! Your test suite helped a lot of finding bugs in our emulator.
During searching for more bugs we have encountered that test t002 causes a bios write(instead of DMA registers) which is caused by the address calculated here: https://github.com/jsmolka/gba-suite/blob/3c6b5c5680b01ddc28b5a4853db9a43ea7889c63/nes/nes.asm#L63

this calcualtion results in the address: 0x2 E000 0000 -> 0xE000 0000 -> 0x000 0000 (ignoring 4 MSBits)
I would suspect that replacing the multiplication by an addition or OR would resolve the issue.
Also some code for checking if the DMA transfer worked would be nice and might look something like that:

        adr     r0, .dma_pass
        ldr     r1, [r0]
        cmp     r1, 0xFF
        bne     f002

I haven't tried compiling it yet. Feedback is highly appreciated.

Thanks in advance!

There are a couple of nasty tricks there naive emulators expected to fail.

https://mgba.io/2014/12/28/classic-nes/

Test 254 reads from and writes to SPSR, but it is supposed to be in system mode while the test since test 253 changes to it.
ARM Architecture Reference Manual says that system mode does not have SPSR.
Should my emulator have SPSR for system mode? Which behavior is correct?