That's interesting to hear. I've only implemented VBlankIntrWait, but it was relatively simple to do so. As soon as the emulated CPU hits the SWI instruction, it calls the HLE'd function, and from there it basically runs the emulated hardware cycle-by-cycle (I try to run most things cycle-by-cycle, not DMAs because I have not gone over the timings + it makes no noticeable difference so far). Once the emulated LCD triggers a VBlank interrupt, the main loop jumps to interrupt handling, then eventually jumps back out and puts the PC right where it should be (after the SWI instruction). I guess other emulators are structured differently, so I won't say it's easy for anyone's project (or hard for that matter), but I didn't have too much trouble. That, and I was really, really determined to get Super Dodgeball Advance to run.
The problem here is, what happens if a non-vblank interrupt occurs after VBlankIntrWait is called? You need to have logic somewhere that determines, after the interrupt returns, whether or not it needs to keep waiting for interrupts, and that's normally part of the SWI handler in the BIOS. I can't think of any outcome with this approach except the interrupt getting suppressed or the SWI returning earlier than it was supposed to, both of which have high potential of breaking the game. It's possible games worked if they didn't have other interrupts enabled or didn't have any that ever fired during that time period but I definitely wouldn't count on that always being the case. Hblank and v-count interrupts would be the biggest offenders, plus some games use DMA or timer interrupts for audio (Sword of Mana IIRC)
Regarding DMA timing, I never handled it in gpSP - that is, DMAs were effectively zero cycle. Usually this won't be a problem because the CPU's locked during DMAs. The only game I know of that needed DMA timing to work properly was GTA Advance, or at least that's what appeared to be breaking it (some race condition where things would go bad if it came out of the DMA handler before vblank or something like that). I tried implementing it at some point but it broke hblank effects with some things, so I don't think I did it right...
Well, in my opinion, you're a very speedy coder
I saw how quickly you got things running for your PC-Engine emulator a few years ago. It took me two years to "conquer" GB/GBC emulation, but I guess that was due to a lack of focus. I flirted with GBA emulation last April, but serious work began in September. I'm much farther ahead than I expected (I used to think it'd be great if I could have games booting around this time), but I don't think I could push something with mostly working graphics + sound in a few months. I dunno, emu-programming is one of those things I have to pace myself with. If I do everything at once, I get obsessed with the project, lose sight of everything else. My GB to DS emulation timeline is 5 years, so...
I don't think I'm that fast though. I was frustrated at how long Temper felt like it was taking to get anywhere. IIRC about 3 weeks before I saw anything from a commercial game, which is about the same amount of time it took with gpSP. GBA should have been a much bigger challenge since it's more complex and it was my first real emulator, but on the other hand it was much better documented and there were more emulators with debuggers to compare it against. It sounds like it only took you a couple months to reach a decent compatibility level on your GBA emulator so I don't think I was really faster than you, since 2 months is about where I switched to writing the recompilers (although I did have a fairly optimized video renderer from the start, and that bloated development time somewhat).
But, with gpSP I worked on it constantly. It was between years at grad school and I didn't have a job so I poured a ton of time into it, maybe 10+ hours a day on average. So I don't know if it's a great benchmark for anything. I never worked on anything so constantly since, what with having a job and some actual social contact.
I did a GB emulator once for a competition, got it "ready" after 24 hours straight coding (the criteria was getting a particular 5 games working properly) but I ended up having to steal the audio code from gpSP to get it to sound right. At that point we just called a draw on the competition. If you went back and did GB again now I'm sure you could do it in a similar timeframe, if you have the focus to stay up that long coding anyway. I probably no longer do.
DS was 15-20 man months for first release, but that was spread out over a long time. Like, one period roughly August 2009 to April 2010 (when I broke my wrist.. real momentum killer) and another period roughly August 2012 to February 2013 for the Pandora release, and August 2013 for the Android one. But if you don't really care about performance it shouldn't be that bad, especially if you already have a good understanding of how its 3D works. Then again, if you're too indifferent to performance it won't even run full speed on a PC.. mine didn't with the interpreter on my desktop machine (~1.8GHz Core 2 class Pentium) and that was before 3D was even implemented.
If your GBA emulator runs around 120FPS on your desktop machine now then I'd say your DS emulator will probably have to be more efficient than it is. I'd estimate that a DS emulator of similar efficiency will cost you somewhere around 6x what a GBA emulator does, both running intensive games.
About DS emulation, I know Desmume X432R has already accomplished one of my dreams, but there's still room to push things. Arbitrary internal resolutions, shaders, custom textures/tiles, free look features, widescreen hacks(?), music and graphics dumping, Wiimote as touchscreen pointer, and a better system to use mouse input. And that's not even some of the crazy, pie-in-the-sky stuff I'd like to see happen (connecting to Dolphin for DS-Wii wireless communication emulation, DS-DS wifi emulation, 3D support). Not saying I'll get to all of those, but it's something to aim for. Having used Dolphin for so long, I've seen how polished an emulator can be. I'd like to make a DS emulator of that same caliber.
Sounds interesting. Good luck with all that. Maybe we could support the same custom texture format if it takes off.
Good luck implementing internal resolution in DraStic. I wonder how far you can push ARM and low-power Intel devices. That'll be fun to watch.
Probably not so far on x86 any time soon.. the x86 recompiler isn't nearly as optimized as the ARM one and the ARM version has a bunch of hand-optimized SIMD ASM that the x86 version lacks. The latter is especially critical since it heavily impacts 3D rendering performance.
From what I've seen so far I'm pretty confident that high end mobile ARM devices (like quad core Cortex-A15, maybe higher clocked Kraits) can handle at least a lot of games with 2x2 resolution enhancement w/o frameskip. But I don't want to commit to that just yet.