Brainstorm Annual 2010 ported to NDS

[bpoint]

Hello all,

Just dropping a note that I have ported our original PC-based musicdisk to the NDS. The musicdisk features 26 songs in a mixture of streaming (.ogg) and various module (.mod/.xm) formats, with nifty visualizers running at a full 60fps. Sound quality is extremely good when using headphones or earphones (the internal speakers are OK, but not great).

I didn't use maxmod as I have my own replay code, and I had to make some custom additions to the ARM7 side, but we finally got it done. Next year we'll try to do a simultaneous PC/NDS release.

Thanks goes to WinterMute and the libnds team for providing the low-level libraries and a libtremor port that worked flawlessly the first time! \o/

[zeromus]

I'll get this working on desmume as soon as I can (it doesnt start up any sound channels, but if you correctly configure slot2 cflash fat directory it can find the brsannual2010.nds; though not on latest svn) but you could save me hours of my life if you would toss me the source.

[bpoint]

I'd love to see this work on DeSmuME, especially with proper DLDI support. But the production was built upon a rather large multi-platform code base, so sending you all of the source would probably be a bit unwieldy.

If it's just the sound that you're having trouble with, I can send you the relevant sources for both the ARM9 and ARM7 side -- that's only two source files. Check your PM.

[zeromus]

Thanks for getting that together for me. I have just finished identifying the issues. It seems the recently (1 week ago) replaced fat-image generation code in svn doesn't produce long filenames. Therefore, that problem can be worked around (only svn builds) by renaming brsannual2010.nds to rom.nds and proceeding as normal, using the slot-2 compact-flash emulation to mount the directory with rom.nds.

Then, 0.9.6 had some bug which made the arm7 fail to get fifo messages. Whatever it is has been fixed in svn since then, but I am somewhat disinclined to discover the precise problem since I would rather focus the energy on fixing LFN.

desmume's DLDI support is "proper" and it even auto-patches homebrew roms with the appropriate driver, but there are complications. Everything would work if you use a pre-made fat imagefile (instead of the directory scanning) in old and new desmumes. The fault lies in the directory scanning garbage and built-in fat image generation.

Be sure you enable the audio synchronous mode so the oggs sound good.

[bpoint]

Thanks for getting that together for me.

No problem. Glad I could help.

desmume's DLDI support is "proper" and it even auto-patches homebrew roms with the appropriate driver, but there are complications. Everything would work if you use a pre-made fat imagefile (instead of the directory scanning) in old and new desmumes. The fault lies in the directory scanning garbage and built-in fat image generation.

I'm not sure I completely follow you. Are you saying I should have built the image differently? I simply used libnds's NitroFS and had ndstool combine the graphic and music assets into the image for me.

I did originally try using FCSR, but that seemed to be rather hacky, and the FAT12 image it generated couldn't support more than a 32MB filesystem which wasn't enough for all of the data. I never did figure out how to get it to build a FAT16 image, so I just went with NitroFS.

Anyway, good to know most of the issues are already fixed in svn. I look forward to seeing the next version.

[zeromus]

Everything would work with your production in desmume (in latest svn) if a _user_ creates a pre-made fat imagefile (instead of the directory scanning) by adding brsannual2010.nds to a blank fat32 image. That was for others, or for background information, not specifically you. You did everything right and in complete accordance with best practices.

[bpoint]

Ah, ok, I did misunderstand you then. I'm actually not that familiar with DeSmuME, sorry.

I'll update the included .nfo with the appropriate directions to use when the next version of DeSmuME is available. Not that many people are keen to compile their own svn builds.