Woopsi and libnds 1.3.5

The guys at devKitPro.org released libnds 1.3.5 today. For the moment, do not use this with Woopsi-based software. For some reason, this library breaks Woopsi. Woopsi locks up when it reaches the call to swiWaitForVBlank(). I have no idea why it does this yet; all I know is that everything was working fine with libnds 1.3.4 and below.

EDIT: Further testing reveals that DeSMuMe locks up at the swiWaitForVBlank() when running Woopsi. No$GBA ignores all input, but otherwise runs as normal. Ideas runs Woopsi normally. I imagine that this indicates changes in libnds’ code that aren’t emulated properly in DeSMuMe and No$GBA.


DevKitPro v24 Compatibility

Those of you keeping up with devKitPro releases will probably have noticed that Woopsi is not compatible with version 24 - devKitARM now includes a built-in “DynamicArray” type which was causing all sorts of problems. I’ve fixed that, plus I’ve reworked the hardware setup code to work with the new register names, touchscreen functions, etc.

A couple of notes on upgrading to handle devKitPro v24. If you call irqInit() and irqEnable() to switch on VBL interrupts, you’ll stop the touchscreen from working. That took ages to find and fix.

Lastly, a word on PALib. PALib has massive problems at the moment. Aside from the fact that the original author, Mollusc, now appears to have a real development job and has stopped maintaining it, the library hasn’t worked correctly with any of the recent devKitPro updates. In fact, you could argue (as most of the GBADev guys do) that PALib has never really worked correctly; I fixed plenty of bugs in it myself trying to get it working. Anyway, Woopsi currently works with dkp24 (when built with the libnds makefile) and also with dkp23 (when built with PALib and the appropriate makefile). However, I can’t maintain the two environments on my laptop at the same time (not enough disk space for two 10GB virtual machines until I can afford to get a new hard disk - not so easy now that I’m a student again and spent Christmas in Italy). This means I’m not checking compatibility with PALib any more, but as the hardware-hitting code shouldn’t change, I don’t foresee any problems. Unless the PALib maintainers do something crazy.

Anyhoo, latest change are in SVN. Expect a real release in the next few days. The only change that could affect user code is the name change from “DynamicArray” to “WoopsiArray”.