Page 10 of 14 FirstFirst ... 89101112 ... LastLast
Results 91 to 100 of 133

Thread: Gameboy Advance

  1. #91
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi Well at least I thought I got the entire "ATLUS" screen. I wrote a very basic and specialized mode0 renderer and it only showed up partially (the bottom half was black). Don't whats wrong there yet. I don't even get at the point where it first calls "VBlankIntrWait", it just does weird stuff from a specific point on. Don't know whats wrong there. According to armwrestler there are no bugs in my current thumb implementation, my arm implementation has some (I think they come from wrong ROR/RRX and ASR? implementation). So I think I will have to look at points that armwrestler doesn't check?
    Last edited by Flerovium; September 3rd, 2015 at 23:23.

  2. #92
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Well, when I got Super Dodge Ball booting, I failed a lot of tests in armwrestler. I don't think you need to be perfect (although being perfect certainly helps )

    Try to debug things step by step. Take an emulator like VBA-M, no$gba, or mGBA and run it against yours. Try to see if you run code that those emulators don't (this means your code is messing up somewhere). Another handy trick is set a breakpoint for yourself, then check the registers between your emulator and others. If anything looks different, try to go through everything in reverse until you can find out where your emulator deviates from others. Hope that makes sense. Good luck

  3. #93
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi That's already what I'm doing at the moment Do you know if Super Dodge Ball requires proper memory mirrors? Not sure if I got them all correct Also maybe something with my interrupt handling is wrong.. At the moment I'm attempting LLE, maybe I should write some HLE code and see if that gets Super Dodge Ball running.

    EDIT: I just found a very stupid cpu bug. SWI instructions always were detected as conditional branch ^^
    This is what my code looked like^^ I hope that my fix will fix a lot of stuff, including Super Dodge Ball!
    Code:
    else if ((instruction & 0xF000) == 0xD000)
            {
                // THUMB.16 Conditional Branch
                return THUMB_16;
            }
            else if ((instruction & 0xFF00) == 0xDF00)
            {
                // THUMB.17 Software Interrupt
                return THUMB_17;
            }
    EDIT2: And there was another bug in SWI for thumb XD I was writing the return address in r14_usr/sys. Now the swi_demo works. I will report later if other games do work now too
    Last edited by Flerovium; September 4th, 2015 at 01:48.

  4. #94
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    @Flerovium - No, Super Dodge Ball does not make use of memory mirror as far as I know. The only games that really do are the NES Classics. The code for Super Dodge Ball is pretty standard; it does not do a lot of tricks.

  5. #95
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi It is quite funny that MSR/MRS are better documentated in GBATEK than in the official documentation of the ARM7TDMI-S I have fixed this issue now, but it only helped with the inoffical hle-bios from mgba which I was testing. I must have some serious issues in my ARM interpreter because some games seem to crash when calling some SWIs (Super Mario Advance 4 for example when calling swi 0xB or 0xC, I don't exactly remember). Currently I don't exactly where to start searching. Armwrestler reports bugs in mov, and all ldr instructions with register offsets (which all are caused wrong ASR/ROR handling) but I can't imagine that those would affect the control flow...). In thumb mode there are no reported bugs..

    EDIT: Super Dodge Ball Advance doesn't even reach the point where it unsets the "forced blank" bit. Neither it enabled BG0. Super Mario Advance 4, only with hle-bios from mGBA or HLE of SWI 0xB/0xC gets to the "Gameboy Player" screen.

    EDIT2: My condition for throwing an interrupt was wrong (I think). I checked IME != 0 AND (IE AND IF != 0) but it seemingly is IME != AND IF != 0. Now Super Dodge Ball disables "Force Blank" and also enables BG0. Kirby also seems to display "something" (the graphics looks very glitchy /distorted, have to check why that is happening)
    Last edited by Flerovium; September 6th, 2015 at 19:50.

  6. #96
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Kirby is also another good game to get running. It does not do a lot of fancy stuff, if I recall. The only thing is that it requires LZ77 decompression (SWI 0x12) and Huffman decompression (SWI 0x13). Huffman decompression is only used for the graphics shown at the pause screen (the ones that describe Kirby's abilities). Super Mario Advance 4 might need EEPROM support to boot, I'm not sure. Super Mario Advance (the 1st one) needs it to boot properly.

  7. #97
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi Yes, the bug in kirby comes from some sort of CPU bug which I'll try to "hunt down" tonight. Because of that bug SWI 0x12 does strange things. I suppose that the bug occurs when processing compressed blocks because of the structure of the picture.

    This is what it looked like:




    As you can see it misses the parts where the picture is filled with one color.

    I wrote some small HLE code for LZ77 decompression and now I get at least to the titlescreen. I also implemented BG transparency and priority for mode 0 last night.

    EDIT:

    I just wanted to share with you that there is a tool called "ida pro 6.1" which I used in the past to analyze code. It organizes the disassembly as a control flow chart. This is what my current analysis of swi 0x12 looks like:
    Last edited by Flerovium; September 7th, 2015 at 21:48.

  8. #98
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi I fixed a small issue regarding shifts today. This bug actually was the reason why lz77uncompvram (SWI 0x12) went insane, so if you want to do LLE as I attempt currently, you'll have to implement this. I believe (I just looked at your source code, I didn't compile and check this) that your code suffers from this oddness, too. You know the special cases for #0 shift amount, right? These special cases are only applied when the shift amount is specified as immediate value, not if the shift amount is register specified.

    EDIT: Now no tests (beside from ldmia, which should fail because it behaves different on ARMv4T) fail for me in armwrestler Nevertheless, weird things happen and I think the reason is that an interrupt gets issued while executing an software interrupt (I don't know why this happen because I take care of the IRQ-disable bit, maybe the bit gets lost at some mode switch? :S) Even Kirby suffers from this bug and randomly crashes.
    Last edited by Flerovium; September 9th, 2015 at 00:57.

  9. #99
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Quote Originally Posted by Flerovium
    I believe (I just looked at your source code, I didn't compile and check this) that your code suffers from this oddness, too. You know the special cases for #0 shift amount, right? These special cases are only applied when the shift amount is specified as immediate value, not if the shift amount is register specified.
    I actually already take care of this. You can see it in ARM.5 here -> https://github.com/shonumi/gbe-plus/...instr.cpp#L201. It doesn't perform any shifts at all if the shift amount is a register and that amount is zero. In these cases, technically the carry-out of a zero shift should be the old CPSR C Flag, but that information is only used in a handful of ARM.5 instructions (ADC, SBC, and RSC).

    Anyway, keep up the good work. Can't wait to see what games you get playable
    Last edited by Shonumi; September 9th, 2015 at 02:35.

  10. #100
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi Ahh my fault. I had theorized that this must happen because oft the swi 0x12 code. I tested it then in no$gba and I compared it with what you and mGBA do. I was too lazy check outside the arm7.cpp so I assumed you wouldn't check that. xD I added an parameter for each shifting function (expect LSL because it doesn't matter there) which for me is the nicer way
    Last edited by Flerovium; September 9th, 2015 at 14:23.

Page 10 of 14 FirstFirst ... 89101112 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •