Page 12 of 14 FirstFirst ... 21011121314 LastLast
Results 111 to 120 of 133

Thread: Gameboy Advance

  1. #111
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    @Shonumi Yes, OBJ rendering is something I haven't worked on for a very long time. But I'm too lazy to fix it, because I've the feeling that there are bigger bugs which I should concentrate on first. In my lastest commit I tried to implement sort of a decode cache for ARM and THUMB instructions, storing the instruction type for each possible instruction. First I did this only for thumb, because I thought that most code is written in THUMB and storing instruction type for each ARM instruction 0 to 0xFFFFFFFF would take waaaay too much memory lol. Then I realized that there are quite lot of bits in the ARM instruction format which can be declared as "don't care" when determining soley the type of instruction. First of all there are bits 24-31 storing the instruction execution condition. Then there are bits 12-19 which neither are relevant for instruction type detection (at this point I had to change my bx instruction detection code because it insisted on the bits 12...19 being all set). Given this I developed a fairly simple lossy "compression" algorithm for ARM instructions, leaving me with only 0x100000 entries in RAM for ARM. The algorithm is implemented in this simple macro:
    Code:
    #define arm_pack_instr(i) ((i) & 0xFFF) | (((i) & 0x0FF00000) >> 8)
    The caches are built at runtime in the constructor of the cpu. At this point you might ask youself "How much is the impact of this optimization?" and I must admit that I currently don't really know. I tested it on my slow Raspberry Pi 2 (my laptop charger is currently broken, so no x86 for me) which isn't powerful enough to run my emulator at fullspeed. In side to side comparison I noticed no difference. This could be due to various reasons. Eventually my drawing code is the main bottleneck (especially on the raspberry) because I have no GPU acceleration, or maybe the ARM architecture is less sensitive to branches than x86 due to the smaller pipeline. I'd love to test it on a x86 computer, maybe I'll find someone to do this job for me (the optimization can be turned of by commenting out "#define ARM7_FASTHAX" in nanoboyadvance/src/core/arm7.h)

    The entire changes I made to accomplish this can be viewed on github: https://github.com/fredericmeyer/nan...b4f96a2c3555d3


  2. #112
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)


    @Shonumi This is actually a dream becoming true!
    In order to get further than to the titlescreen I eventually need to actually emulate FLASH (not just fake its existence by writing a valid chip identifier to 0x0E000000).
    Last edited by Flerovium; February 1st, 2016 at 16:16.

  3. #113
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Great work! I know I was pretty excited when I got Pokemon Ruby/Sapphire to boot in my emulator. Be careful not to spend all day playing games though. That's what happened to me once Pokemon started working

  4. #114
    Emulator Developer
    Join Date
    May 2006
    Posts
    215
    Mentioned
    1 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?
    I feel like I'm familiar enough with emulation of some of these systems to answer about those as well, if you don't mind.

    PS1: Easier than DS. There's only CPU and it's significantly simpler and slower. PS1's GTE is simpler in scope and less autonomous than DS's geometry engine. PS1's GPU is also more straightforward and much less featureful than DS's. And the DS has an entirely separate set of 2D GPUs, and wireless functionality (although I haven't emulated it). PS1 has a somewhat more advanced audio processor, some coprocessors for XA and MDEC decoding, and a CD-ROM interface that DS lacks (and is more complex than its cart interface) but these things don't amount to enough to tip the scales.

    N64: This is difficult to answer because N64 emulation has been "done" in a lot of ways. The usual very-HLE heavy but fairly inaccurate (and not even totally compatible) approach, combined with a hardware GPU renderer, is probably easier than DS emulation, especially if you don't try tackling the more obscure/custom ucodes. But a fully LLE and reasonably accurate N64 emulator with software renderer is approaching a similar amount of work. The dedicated audio hardware is very limited and there's no 2D engine, but the RSP has a significant amount of instructions and the RDP has various features that DS lacks (primarily bilinearish filtering and mipmapping)

    Saturn: In a lot of ways comparable. Like DS Saturn has two CPUs, a 3D processor, and a 2D processor. The 2D is similar if maybe a bit more featured, while the 3D is significantly less featured but tricky to actually emulate correctly. There's no geometry coprocessor but there is a DSP that not a lot of games use. There's way more work involved in the audio part; if you want accurate LLE you have to emulate its DSP which is hardly documented, and there's a 68k, and a mixer. And the usual CD-ROM, including an SH1 CD-ROM controller, but I doubt anyone is going to bother LLEing that any time soon. Plus there's a 4-bit "system" CPU for some reason. So overall there are more individual parts but they get arguably more complex on DS, and you can get a lot of emulation done without doing much on some of them.

    Also regarding your other question, I think GBA is easier to emulate than SNES because it has much simpler audio (no audio CPU, no real DSP), fewer pointless graphics features and overall more straightforward implementation, and less strange memory mapping. The games are also less timing sensitive. GBA does have some (actually useful) graphics features that are more work to emulate though, like sprite scaling/rotation, more comprehensive color blending and better windows.

  5. #115
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    Since I recently started working on NDS emulation I thought I would create some tests, I started with a very basic FIFO test in C
    which should basically count up from 0. The value to be print is generated by the ARM7 core and sent through the FIFO to the ARM9 core which then outputs it to the screen, very basic stuff

    You can get the code from my GitHub: https://github.com/fredericmeyer/NoD...nds/fifo-basic
    Expect more tests to come with time!

    I cannot test this on my own emulator yet though since I have no working ARM9 core, only partial ARM/NDS7 emulation XD
    I want to get the NDS7 part running before I tackle NDS9.

  6. #116
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Most games use the NDS9 for all the heavy lifting from what I understand, e.g. a majority of the game's code will be ARM code running on that CPU (THUMB code is not used as much as it was on the GBA, generally speaking). The NDS7 is generally used for Audio, WiFi(?), and other auxiliary stuff. That's why I'm focusing on the ARM9 and figuring out how to get the NDS7 running in alongside it later. I'm trying to get a very basic demo made with DevKitPro and libnds. So far, so good, but even the most basic demo compiled with libnds seems to want to use a lot of features: Immediate DMAs, the NDS CP15 co-processor, some SWIs, even interrupt handling. All this just to draw a red screen

    I have not worked on my NDS branch in a bit. Trying to get the IRQs done right, but I was recently busy getting 1.0 of GBE+ ready for release. I just finished upgrading the whole project to SDL 2.0, so I'm going to have to rewrite parts of the NDS core to use the new version. I plan on using OpenGL for 3D rendering eventually, and SDL 2.0 makes it easy to create an OpenGL 3.3 or 4.0+ context. I'd like to have access to some of the newer OpenGL features and take a more "modern" approach to 3D graphics. Hopefully SDL 2.0 will support Vulkan sooner or later, and by that time there will be some literature or tutorials on how to properly utilize Vulkan.

  7. #117
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    I wanted to get basic NDS7 emulation first since I don't have to mess with any caches, coprocessors or ARMv5 instruction there, heh. I got support for basic SPI and IPC now, you can see this in
    this video I did for some reason:


    But I'll very soon be at a point where I have to start NDS9 emulation. Also working only on NDS7 is very frustrating since you don't get to see anything beside your debug output :p

  8. #118
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    Looking good

    Even if you can't see the results, it's important to work on anything you can. Even if something is a small component, eventually it will be necessary for the entire emulator to function. Better to write your code now than later. Working on the little things actually gives me encouragement. I know building an NDS emulator is a long, long process, but if I take some steps everyday, I will make it to my goal.

    Not much happening on my end for NDS emulation. I'm trying to get basic IRQ handling finished. It's more or less just like the GBA IRQ handler (NDS9 is a bit different regarding the user IRQ handling address). On the NDS9, it requires some form of CP15 emulation (you need to know the DTCM base address, which is determined by the co-processor) but it's simple really. I think I'm really, really close to getting a libnds binary to run. The next hurdle is to get the IrqWait SWI working via HLE (probably just going to copy+paste the GBA core's code for this).

  9. #119
    EmuTalk Member
    Join Date
    Feb 2014
    Location
    Niedersachsen, Germany
    Posts
    87
    Mentioned
    8 Post(s)
    Interesting. Do you emulate the icache or dcache yet? Or do you happen to know how important it is to emulate them?

  10. #120
    EmuTalk Member
    Join Date
    Mar 2014
    Location
    Chicago, IL
    Posts
    166
    Mentioned
    28 Post(s)
    No, none of the caches is emulated just yet. As far as I know, the caches just affect timing when fetching certain parts of memory, and right now there really is no timing code in my emulator. So, in order to at least draw things on screen, I don't think I'll have to worry about them right away. I'm making tests via DevKitPro, so I'm in control of whether or not the ROMs need exact timing.

    It seems like I will need to emulate the NDS7 running alongside the NDS9 to get even a basic demo to work. I checked everything, and apparently even my homebrew test requires both CPUs to communicate on some level. I got the the point where the NDS9 sets up the CP15, does a few DMAs, then calls the IntrWait SWI, but that's still not enough. Program execution hangs. I hacked up Desmume and effectively disabled the NDS7, and the results are similar; it got stuck on the IntrWait SWI as well. So the only thing left is to emulate the NDS7. I don't think it'll be that hard (since it'll be the same code from my GBA core), it's just going to take a bit to make sure they can both run side-by-side.

Page 12 of 14 FirstFirst ... 21011121314 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
  •