Let's Golf: the horseman of apocalypse that wasn't one

< More camera trouble...melonDS 1.0 is out >

Let's Golf: the horseman of apocalypse that wasn't one
Jul 7th 2025, by Arisotura

I figure I need to resolve the dramatic tension from the previous post.

So the issue we had was a screen-sized DMA3 transfer interfering with NDMA1, which is used to transfer camera data...

Shortly after I made that post, I recalled that Jakly mentioned VRAM timings, and started to figure it out.

I said that when I reproduced the setup in a homebrew, it would trigger a data overrun error and get stuck. But there was one thing I was missing: my homebrew was using a camera resolution of 256x192, with DMA set to run every 4 scanlines, the standard stuff. However, Let's Golf uses cropping to achieve a resolution of 144x144, and runs the DMA every 7 scanlines. This means more time between each NDMA1 transfer.

Regarding VRAM, the DSi supports accessing it over the 32-bit bus, instead of the old 16-bit bus. One effect is that this makes it possible to write to VRAM in 8-bit units, which wasn't possible on the DS. Another effect is that it affects timings: for example, a 32-bit DMA transfer from main RAM to VRAM would take 2 cycles per word, instead of 3.

I did the math, and with such timings, the screen-sized DMA3 transfer would have enough time that it could run between two NDMA1 transfers without disrupting the camera operation. But with the 16-bit bus timings, DMA3 would definitely take too long.

I even modified my homebrew to use the same 144x144 resolution as Let's Golf, and added a key to toggle the 32-bit bus for VRAM (via SCFG_EXT9 bit 13). Suddenly, my homebrew was running just fine as long as the 32-bit bus was enabled, but when it was disabled, it would trigger the data overrun error and get stuck.

So, basically, this is nothing fancy, just a case of "this works out of pure luck".

I added support for the new VRAM timings in melonDS. But this wasn't enough, Let's Golf would still get stuck.

I looked at it, and it was still possible that DMA3 would start right before a NDMA1 transfer, which would be the worst time. The camera FIFO would definitely be almost full at that point, and further scanlines would overflow before NDMA1 had a chance to run.

I thought about it, and... there was no way this could work unless there were some double-buffering shenanigans involved.

I modified my homebrew to try and verify this hypothesis. My idea was to start a camera transfer, let it fill and overrun the FIFO, and use a dummy NDMA to track it. The NDMA channel would be configured like for a camera transfer, but it wouldn't actually read camera data, and the length would be set to 1 word. I would just use the NDMA IRQ as a way to sense the camera transfer condition. This way, I could know how many times it fires before hitting the overrun error.

This didn't reveal anything, as the NDMA was only fired once.

My next idea was to wait for the NDMA IRQ, and from that point, count how long it takes for the data overrun to be raised (by checking bit 4 in CAM_CNT). The timings I measured from this definitely suggested that a second block of camera data was being transferred after the NDMA IRQ, before it would raise the data overrun error.

Which, in turn, tended to confirm my hypothesis that there are actually two FIFO buffers for camera data. Thus, when one buffer is filled entirely (ie. as much as the DMA interval allows), if the other buffer is empty, the buffers are swapped and the DMA transfer is fired, otherwise the data overrun error is raised.

So I reworked melonDS's camera interface implementation to take this into account. Fixed a bunch of other issues. Had some "how the fuck did this even work?" moments.

There are still minor issues I need to iron out, but: finally, Let's Golf is fixed, and I haven't seen regressions...

3 comments have been posted.

< More camera trouble...melonDS 1.0 is out >

lucaspltn says:
Jul 7th 2025

🙌🏼🙌🏼🙌🏼

Barbro says:
Jul 7th 2025

I hope you know that I am enjoying this post with great mirth.
This whole situation is so funny to me, mostly because I've found that I come into issues with other things like others' mods work with my setup often. Sometimes the most inane things cause all of the problems, like forgetting vanilla AI packages for quests in Fallout within a mod... Just how...?
Also, if you care at all, the bottom of the site says "Kuriblog 1.3 | © 2017-2024(should be 2025)<--- Arisotura." I'm not sure if that's in your control or not, but it just bugged me a bit.
Anyhow, hope you have a good day now, and good luck with MelonDS.

Arisotura says:
Jul 7th 2025

thanks!

the copyright bit is in my control, just forgot to update it I guess :P