My original code used SDL, which would be okay except it’s quite difficult to create useful GUIs with it. Thus, I installed Qt so that I could create a proper intuitive interface from the start. Unfortunately, this means all the SDL related code is nonfunctional for the moment; furthermore I’m not entirely familiar with Qt, so progress will be slow for now as I read tutorials and watch some videos to get me up to speed. This is meant to be a long-term project however, so by spending extra time now, CorgiDS will benefit all the more.
As for the bug: I noticed that certain homebrew that I tested would jump to uninitialized or zeroed-out memory; in either case, nothing with valid code to execute. I suspected this to be a problem with the CPU for a while, but as it turns out, this was a red herring. I pinpointed the exact location where the emulator messed up, and I fired up the nocash debugger. The code that I tested (dslinux) would jump to invalid memory if a certain part of memory was set to zero – nocash gave a non-zero value and worked fine. I looked up the memory address on GBAtek and found it had something to do with the firmware user settings.
There it was!
I had overlooked the firmware when writing my direct boot function. The firmware writes to memory the user settings, which contains useful data such as touchscreen calibration points and the user’s language. Without including this, the memory supposed to hold these values would always be zero, and as GBAtek specifies, some of these values are never supposed to be zero. Why the ROMs decided to shit themselves because of this I’m not entirely sure, but regardless, now that I’ve added this functionality, everything seems to work as it should.
My next goal will be to get CorgiDS to its former state before the Qt migration. This will take some time, and of course I’ll be adding more GUI specifics beyond that. Stay tuned!