Migrating to Qt and bugs

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!


What lies ahead?

Welcome to the CorgiDS development blog! I’m sure many of you have seen the reddit announcement of my new emulator, and I was pleased to see how much positive reception it received. It’s encouraged me to work even harder than before.

Now, an important topic is the road map I have planned for CorgiDS’s first release. What are all the features that need to be added before I see it fit to release my project to the public?

My feature list is split into two sections: essential and optional. Essential represents all the features I will add for v0.1, and optional represents those features that would be nice but aren’t guaranteed to be added for v0.1.


  • A robust 2D graphics engine, obviously. It should be good enough to run several commercial games that don’t require the 3D portion of the GPU.
  • Two separate interfaces: a Qt frontend with full support, and a minimalist SDL frontend.
  • A powerful GUI debugger included within the Qt frontend. The debugger will support automatic disassembly, memory viewing, peek and poke functions, and program counter breakpoints. Not only will this help with development immensely, but also it ought to be quite useful for homebrew programmers as well as my fellow emudevs.
  • Optimization. CorgiDS is, at the moment, VERY slow. Even a simple “hello world” console test barely makes it above 30 FPS, so in that regard, CorgiDS is half as fast as a regular DS. I’ll need to rewrite the core loop to make things faster without sacrificing any accuracy.


  • Basic 3D support. Arguably this should be in the essential section, but my goal for v0.1 is to be able to run some commercial games, and not all of them necessarily need 3D graphics. Nevertheless, I will more than likely put work into this section before the release. I will also need further optimization if I work on this.
  • Sound. It’s a pretty lovely feature for games, but its inclusion will complicate matters. This is not the most unlikely thing to add, however, and sound will be guaranteed in v0.2 if nothing else.
  • Hi-res support. If it’s not particularly difficult to implement, CorgiDS will come included with this.
  • A nice logo for the project, ideally including a corgi or two. I don’t have the skills necessary to create this, but if someone is willing to pitch in, feel free to contact me and we can work something out.
  • “DS View.” To my knowledge, the other emulators consist of the two DS screens stacked directly on each other in one window. At the moment, CorgiDS does the same as well, but my idea is to include a mode where the two screens are separated and placed on a background all within one window to reflect how an actual DS looks.
  • Savestates. In all honesty, this likely won’t be added for v0.1. The option is there, however.
  • A VRAM viewer for the debugger. This likely won’t be included either, but it is something to consider for future releases.
  • Other things I might be forgetting.

I can’t make any guarantees as to when you can expect the release, but likely something will be ready before the end of this year. Expect to see plenty more posts on here as time goes on, so be sure to follow the ongoing development of CorgiDS!