The aging cart
So I got the UI far enough to be able to run things again. Of course, I tried the aging cart.

It's a nice help when it comes to making emulators accurate. It has a nice big set of tests. The code is also well-structured and not too hard to understand. There is a table at 0x021F2FD0 that lists all the tests, pointing to each test's name and the corresponding function.

melonDS failed the DMA priority test, like DeSmuME.

The failure was actually not related to DMA priority, which is handled correctly in melonDS. The DMA priority test runs two DMA transfers, a long one that starts immediately and a short one that starts upon HBlank but has higher priority. Each DMA fills a buffer with values pulled from a shared timer. It then checks the continuity of the stored values to find out whether and when the long DMA was interrupted.

This pointed to something I wanted to do since a while: rework timer emulation in melonDS as it was a bit complex and grossly inaccurate. After doing so, melonDS passed the DMA priority test, but it also fixed a bunch of issues, like FMVs playing at shitty speeds.

After implementing some more obscure DMA types, I was able to pass more tests. For example, DMA type 3 is triggered at the start of each scanline, but it runs on scanlines 2 to 193 included, and, unlike HBlank DMA, it always stops on scanline 194. It's not clear what purpose this DMA type would serve -- maybe it was intended for some external device acquiring video from the screens.

Then came DMA type 4, which is used for feeding the display FIFO. The current implementation in melonDS is a gross hack, but it is pretty much impossible to use the display FIFO without DMA due to its tight timing, and emulating it properly would be resource-intensive. The display FIFO is another obscure feature -- I don't know of any retail game that uses it, but I have yet to be surprised.

At this point, melonDS gets to the capture control test, but fails it. Again, the issue is unrelated to the screen capture logic. The test renders 3D graphics, and checks correctness by checksumming the captured image. Which basically requires pixel-perfect 3D graphics.

The aging cart has been a fun ride so far, and it's still far from being finished :)
Ruben M. says:
Mar 25th 2017
Wish I could understand even just a fraction of what was being said here, but at least I know it means positive progress! Wish you the best of luck with your project!
coto says:
Mar 28th 2017
"After implementing some more obscure DMA types, I was able to pass more tests. For example, DMA type 3 is triggered at the start of each scanline, but it runs on scanlines 2 to 193 included, and, unlike HBlank DMA, it always stops on scanline 194. It's not clear what purpose this DMA type would serve -- maybe it was intended for some external device acquiring video from the screens."

I can only think of DMA3 used for actual framebuffer image render (where as any PPU Engines use DMA destination buffer as source buffer).

Since vblank is ensured to have that DMA channel free every time it programatically. If it makes sense. :p
coto says:
Mar 28th 2017
"every time programatically"** fix
YueR says:
Apr 3rd 2017
sorry ,it's my fault,i cannot use the bios.but it has some problems:
1.no sound
2.cannot use savestate
3.setting is poor to set.
Grenwood says:
Apr 7th 2017
Can you add multiplayer to this? I know wifi multiplayer is an issue but could you do Bluetooth multiplayer so we can still play with people in the same room?
Post a comment
Name:
DO NOT FILL