Page 11 of 14 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 133

Thread: Gameboy Advance

  1. #101
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi I attempted this way to implement sprites, but currently kirby looks more like a cripple



    Currently Kirby Nightmare in Dreamland is the only game which is playable, most games crash, having some unrealistic address in r15 (like 0xFFFFFFFC for many games). I think it has something to do with swi / interrupt handling, or mode switching, but I cannot exactly find out why. I should write some tests to find out Also Kirby only runs stable when I HLE CpuSet, CpuFastSet and LZ77UncompVRAM, otherwise it randomly crashes (I think it has something to do with interrupts happening while processing software interrupts, also I know that some SWIs, atleast LZ77UncompVRAM, abuse r14 for arbitrary data).

  2. #102
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    I remember having 0xFFFFFFFC for R15 quite frequently. The cause for me will probably be different for you, but generally, it seems to come from some value being 0x0 then subtracting 0x4 from it, then putting it in R15 later. The problem could be anywhere. I don't even know when exactly I fixed stuff like that.

    Hardware IRQs can occur even while SWIs are being processed. If you don't handle nesting IRQs within SWIs, that could be a problem for an LLE approach. Using HLE though, it's possible to avoid that issue entirely.

  3. #103
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi Yes, I already thought about that issue coming from the subs pc, lr, #4 instruction in the irq handler of the bios. I'll have to look how to handle that nesting problem correctly (don't exactly know how it functions, maybe gbatek has something about it).


  4. #104
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    Me and my project aren't dead! How is NDS emulation progressing, shonumi?

    After taking a break in which I did almost no programming (beside of excersises for university) I'm back at work. And no, this time I'd not rewrite everything from the scratch (eventhough I almost did due to frustration)
    Today I finally found and fixed a bug that was (I think so) the cause for lots of crashes. As we say in Germany "the devil lays in the detail". The bug was caused by a small bug in the method which initiates an IRQ. In my ARMv4T interpreter core I have a variable called "flush_pipe" which if set causes the pipeline to be flushed after an instruction was executed. This is used mainly in branch instructions. However, in my FireIRQ method, I set flush_pipe in order to flush the pipeline. The problem obviously is, that the pipeline gets only flushed after the next instruction was executed. What I had to do to initiate a flush manually (set pipe_state to zero). Finding this out was quite tricky for me because the code looked (logically) correct and you had to have exactly in mind what "flush_pipe" was for. Having this fixed and some other mainly small stuff that I did in my programming break, I can now run games like Pokemon Mystery Dungeon Team Red (the first GBA cartridge I ever owned!) per LLE but with graphical glitches:


    (I would've cropped the image if I wouldn't work on my Raspberry Pi 2, which is quite painful, currently)
    Last edited by Flerovium; January 17th, 2016 at 13:58.

  5. #105
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Hey Flerovium, nice to see you're still active. Looks like you made a lot of progress. It's always exciting to get things working, and getting rid of bugs so you can play games is always great! I'm glad to hear NanoboyAdvance can run one of your first GBA games. Keep it up, and don't be shy about posting more screenshots

    About NDS emulation, I work on it now and then. Currently, I am trying to get small demos to run (using libnds + devkitARM). The ARM9 CPU actually isn't significantly different from the ARM7, except the ARMv5 architecture has minor changes to some instructions, and it has a 5-stage pipeline (ARM7 has 3-stages). It has Fetch, Decode, and essentially 3 stages of Execution (ALU, Memory Access, Register Write). Previously, I tried emulating each stage individually. It worked and there was nothing wrong with it, but the setup I made was overly tedious and would have proven unbearably slow in an interpreter. Instead, I've chosen to keep Execution as a single function within the emulator, but I'm going to have to keep track of any cycles that are supposed to be simultaneous with other stages. This should make things simpler than before and maintain correct timing.

    Currently, I can run the TinyFB demo but nothing else. All the demos I make with libnds make use of the coprocessor in the NDS (called the protection unit), which I do not emulate just yet. I don't even emulate the ARM coprocessor instructions, so my emulator exits due to unknown instructions
    Last edited by Shonumi; January 17th, 2016 at 17:46.

  6. #106
    EmuTalk Member
    Join Date
    Jan 2016
    Posts
    12
    Mentioned
    1 Post(s)
    Quote Originally Posted by Shonumi View Post
    Hey Flerovium, nice to see you're still active. Looks like you made a lot of progress. It's always exciting to get things working, and getting rid of bugs so you can play games is always great! I'm glad to hear NanoboyAdvance can run one of your first GBA games. Keep it up, and don't be shy about posting more screenshots

    About NDS emulation, I work on it now and then. Currently, I am trying to get small demos to run (using libnds + devkitARM). The ARM9 CPU actually isn't significantly different from the ARM7, except the ARMv5 architecture has minor changes to some instructions, and it has a 5-stage pipeline (ARM7 has 3-stages). It has Fetch, Decode, and essentially 3 stages of Execution (ALU, Memory Access, Register Write). Previously, I tried emulating each stage individually. It worked and there was nothing wrong with it, but the setup I made was overly tedious and would have proven unbearably slow in an interpreter. Instead, I've chosen to keep Execution as a single function within the emulator, but I'm going to have to keep track of any cycles that are supposed to be simultaneous with other stages. This should make things simpler than before and maintain correct timing.

    Currently, I can run the TinyFB demo but nothing else. All the demos I make with libnds make use of the coprocessor in the NDS (called the protection unit), which I do not emulate just yet. I don't even emulate the ARM coprocessor instructions, so my emulator exits due to unknown instructions
    How hard do you think is DS emulation compared to PS1/N64/Saturn emulation or even something like PS2/GC/Dreamcast/PSP?

  7. #107
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Quote Originally Posted by BigKong View Post
    How hard do you think is DS emulation compared to PS1/N64/Saturn emulation or even something like PS2/GC/Dreamcast/PSP?
    Well, to accurately answer that question, I'd have to know a lot about those systems. I've only studied parts of the Gamecube, the rest I have only limited knowledge of their internals. Still, I'd take a guess. I'm only speaking personally from my own experience if I were to take on each.

    PS1: Complete guess, but I'd wager that if I can tackle the DS, I'll have a very solid grip on how to approach Sony's first Playstation. The CPU is MIPS, and it should be well documented. I can't speak about the GPU or anything else. 3D stuff isn't my specialty right now, but I'm sure I could do this, given time.

    N64: The N64 is a hot mess in terms of documentation, whereas the DS is mostly understood. Whether I'm taking a good LLE path or an advanced HLE path to the N64, I'm going to have to say the DS is easier to get to grips.

    Saturn: Again, a hot mess when it comes to documentation. And keeping those CPUs in sync seems like a nightmare. The DS is simpler (has just two, with one running at 1/2 the speed of the main), and saner, and has better games to make testing more fun

    PS2: Harder. More "moving parts" or components to emulate. Would take a loooot of time to get anywhere or see any results.

    GC: Harder. Same reasons as the PS2.

    Dreamcast: Honestly have no idea. I'd assume harder, simply because the DS is something I'm familiar with. Plus, I'd have to buy a bunch of games and hardware to do testing (never owned a DC).

    PSP: Moderately more difficult, probably because of the graphical components (again, I'm not too good with 3D things just yet, I'm learning though). An HLE approach to the PSP makes some aspects easy to do, and MIPS is a nice architecture in my opinion.

    Yeah, so I imagine just about everything is more challenging than the DS. You have to understand though, I've been working with Nintendo's portables for years. To me, the DS really is an evolution of the GBA (from its CPU to its LCD to various other facets). I know it well, so to go to another system or platform like the advanced ones mentioned above, it would require learning a lot about how they operate. If I had programmed a PS1 emulator, perhaps my outlook on how difficult PS2 or PSP emulation is would be different (I'm sure there are some hardware designs that get transferred or transform each generation).

    I first emulated the GB so I could emulate the GBC. I emulated the GBC so I could emulate the GBA. I emulated the GBA so I could emulate the DS. Each step prepared me for the next. I chose this path because I knew it would gradually help me understand how to emulate a DS properly, instead of jumping in all at once. The DS used to scare me; I thought it'd be a long-shot before I could even try to get it running. But now I am confident that I can do it. So now, I do not think the DS is exceedingly hard to program an emulator for (just needs a little time and love). But I know little about other systems, so they seem like HUGE tasks me.
    Last edited by Shonumi; January 17th, 2016 at 22:25.

  8. #108
    EmuTalk Member
    Join Date
    Jan 2016
    Posts
    12
    Mentioned
    1 Post(s)
    Quote Originally Posted by Shonumi View Post
    Well, to accurately answer that question, I'd have to know a lot about those systems. I've only studied parts of the Gamecube, the rest I have only limited knowledge of their internals. Still, I'd take a guess. I'm only speaking personally from my own experience if I were to take on each.

    PS1: Complete guess, but I'd wager that if I can tackle the DS, I'll have a very solid grip on how to approach Sony's first Playstation. The CPU is MIPS, and it should be well documented. I can't speak about the GPU or anything else. 3D stuff isn't my specialty right now, but I'm sure I could do this, given time.

    N64: The N64 is a hot mess in terms of documentation, whereas the DS is mostly understood. Whether I'm taking a good LLE path or an advanced HLE path to the N64, I'm going to have to say the DS is easier to get to grips.

    Saturn: Again, a hot mess when it comes to documentation. And keeping those CPUs in sync seems like a nightmare. The DS is simpler (has just two, with one running at 1/2 the speed of the main), and saner, and has better games to make testing more fun

    PS2: Harder. More "moving parts" or components to emulate. Would take a loooot of time to get anywhere or see any results.

    GC: Harder. Same reasons as the PS2.

    Dreamcast: Honestly have no idea. I'd assume harder, simply because the DS is something I'm familiar with. Plus, I'd have to buy a bunch of games and hardware to do testing (never owned a DC).

    PSP: Moderately more difficult, probably because of the graphical components (again, I'm not too good with 3D things just yet, I'm learning though). An HLE approach to the PSP makes some aspects easy to do, and MIPS is a nice architecture in my opinion.

    Yeah, so I imagine just about everything is more challenging than the DS. You have to understand though, I've been working with Nintendo's portables for years. To me, the DS really is an evolution of the GBA (from its CPU to its LCD to various other facets). I know it well, so to go to another system or platform like the advanced ones mentioned above, it would require learning a lot about how they operate. If I had programmed a PS1 emulator, perhaps my outlook on how difficult PS2 or PSP emulation is would be different (I'm sure there are some hardware designs that get transferred or transform each generation).

    I first emulated the GB so I could emulate the GBC. I emulated the GBC so I could emulate the GBA. I emulated the GBA so I could emulate the DS. Each step prepared me for the next. I chose this path because I knew it would gradually help me understand how to emulate a DS properly, instead of jumping in all at once. The DS used to scare me; I thought it'd be a long-shot before I could even try to get it running. But now I am confident that I can do it. So now, I do not think the DS is exceedingly hard to program an emulator for (just needs a little time and love). But I know little about other systems, so they seem like HUGE tasks me.
    How do you rank NES and SNES? NES appears simple at the first glance but has a multitude of mappers many of which still aren't emulated by any emulator while SNES seems similar to GBA.

  9. #109
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    I (think I) fixed another small IRQ issue. Now also Super Dodge Ball seems to run without problems (didn't peak too far into the game but it gets further than the titlescreen). Pokemon Mystery Dungeon Team Red seems to crash when entering the first dungeon... I will have to find out why this happens. I also implemented a screenshot functionality, using libpng to dump the screen contents. Using GIMP or any other software to crop the image on the raspberry pi 2 I think would be pain and also unnessecarly takes disk space.

    Here are some screenshots (order is random):







  10. #110
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Quote Originally Posted by BigKong View Post
    How do you rank NES and SNES? NES appears simple at the first glance but has a multitude of mappers many of which still aren't emulated by any emulator while SNES seems similar to GBA.
    The NES is definitely harder than something like the GB or GBC if you're going for a decent amount of accuracy in either one. The GB isn't sensitive to a lot of timing issues (unlike the NES) and like you pointed out, the GB has far less mappers and cart layouts/formats to deal with. On the other hand, there are still various little things that are utterly undocumented about the GB. It's not enough to affect the compatibility of most games, but it's very annoying. Not to mention the MBCs like MBC7 are poorly documented. The NES, on the other hand, has been very extensively covered; its quirks are mostly known factors at this point. I still think the NES is harder, simply because it's a pain trying to keep the timings correct. It's not harder than the GBA or DS though, in my opinion

    I'd put the SNES at or above the DS. I mean, if you look what byuu did just to get bsnes/higan to full commercial compatibility, and all of the undocumented stuff he had to deal with, the SNES is a bit of a nightmare in my opinion. Though in terms of graphical capabilities, it's most similar to the GBA (some aspects look kinda like copy+paste work, e.g. the special effects) the GBA has a lot less to worry about. There are no coprocessors like the SA-1 or Super FX, memory access is pretty straightforward, and the GBA's LCD vs the SNES' PPU just looks and feels more orderly to me. Keep in mind, there are still some odds and ends and obscure behavior we're discovering about the SNES too. I dunno, I just get the impression that I'd have an easier time trying my had at DS emulation than SNES emulation, again, because the DS is pretty familiar territory.

    @Flerovium - Those screenshots look amazing! I guess OBJ rendering could use some work, but everything else looks great

Page 11 of 14 FirstFirst ... 910111213 ... 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
  •