Regarding the future of BlocksDS

Published on November 15, 2024

For those unfamiliar, BlocksDS is a fork of the primary Nintendo DS homebrew toolchain1. It was created almost two years ago, in March 2023, by AntonioND; I have been involved in the project in a position somewhere between that of a contributor and a co-maintainer. Recent developments have made people uneasy about its future, so I’d like to clarify what’s going to happen from my perspective and hopefully ease those concerns.

I found out about BlocksDS on the day preceding its public release; I was hardly an insider. As a friend of Antonio’s and a fellow tinkerer, I proposed to help him out with various aspects of the toolchain, most notably providing the compiler/standard library stack and binary packaging in the form of the Wonderful toolchain. My work on WonderSwan homebrew (and previously platforms like the PS1) meant I already had a solution for packaging Linux binary builds, as well as experience with packaging GCC-based toolchains. The idea of crossing at least some years-old tickets off my to do list was also appealing to me.

In exchange, I expected to have a say in its design decisions and direction. My thinking was that by hosting the packages, I took part of the responsibility for them, and I wouldn’t want to put my name on something whose direction I disagree with. As time went on, however, I started feeling like my input2 was becoming a roadblock relative to Antonio’s vision for the project. This manifested itself in many ways and throughout many discussions, but the most impactful was our approach to exploring new and refactored functionality.

Generally speaking, I like treating Wonderful as my personal testbed. I want to have the freedom to try new things and see if they lead to a better, or at least more interesting, user experience. This, however, conflicts with the goal of providing a stable API: either you delay public releases for a long time until you are mostly confident in its design, or you have to provide shim after shim as you change things3.

BlocksDS has become a project attractive for people who, in line with Antonio’s vision, wished to port and maintain legacy homebrew without too much hassle while also gaining bug fixes, optimizations and improvements. There have been discussions about reconciling this with removing and cleaning up functionality, but in the background was always the added complexity of maintaining such solutions.

In the end, I usually ended up conceding this argument to Antonio; however, I was motivated by a different reason. I believed that, so long as breaking changes were minimal, projects would be able to switch between the upstream stack and this fork relatively freely. This was, effectively, my little contribution towards minimizing friction between the two projects. As a matter of fact, projects I have externally contributed BlocksDS support to in the past had generally retained the ability to be built using the upstream stack (1, 2).

However, all of this changed with the recent major upgrade of the upstream stack, which introduces many breaking changes. After it happened, that line of thinking was no longer applicable. Projects supporting both toolchains are now faced with a choice: either they will pick a favourite, or maintain a mountain of #ifdef calls. In turn, our approaches to homebrew development have finally diverged. It is my concern that trying to force a middle ground could hurt Antonio’s vision and goals for his toolchain. In addition, I’m personally frustrated with the unnecessary fanning of flames and drama surrounding the relevant homebrew communities, occasionally even bordering on harassment - I’ve lived through enough of those for a lifetime.

Therefore, I’ve decided to announce some changes within the coming weeks and months which will affect the BlocksDS community:

  • I will cease to provide and package binary builds of BlocksDS. The two projects will now forge independent paths.
    • BlocksDS will continue to use Wonderful’s build of the GCC-based ARM toolchain for the foreseeable future; it is dependent in many ways on picolibc’s changes to newlib, and thus not compatible with many existing embedded ARM toolchains.
    • BlocksDS will continue to have binaries available via the wf-pacman ecosystem, albeit the Pacman repository in question will be separate and support for those binaries will no longer be provided by me.
    • Nevertheless, on my end, I will take steps to ensure this transition is reasonably gradual and painless for existing BlocksDS users.
  • Going forward, BlocksDS will be managed solely by AntonioND. This means specifically that I am giving up the right to authoritatively exercise my influence over the project; what happens from here is out of my hands.

I don’t think this change is going to hurt the project; my involvement has been secondary at best, and removing my personal concerns and reservations from the project should allow it to progress faster on issues which matter to the community it has forged. Personally, I’m happy to have been able to serve it for over a year. I believe the project’s future will be bright under AntonioND.

I’d like to thank all of you who supported me and helped me, and I wish you all the best.

Maybe we’ll see an NDS toolchain in Wonderful at some point? If only there were 48 hours in a day, things would be much easier… If you’ve read my project updates, you are probably aware that a key motivation for me is pursuing ideas I consider to be novel or interesting. While I have some of my own already, feel free to suggest ideas - I’m always eager to listen to and ponder other people’s creativity in that regard.


  1. Out of an abundance of caution regarding the relevant project’s trademark rights, in particular the non-disparagement clause, I have decided not to use any names the project asserts as trademarks in this article. I apologize for the inconvenience. ↩︎

  2. A lot of it is documented on the BlocksDS issue tracker. I tried to maintain the transparency of our decision-making process. For issues we disagreed on or ones which required more extensive discussion, I generally want others to be able to understand why certain decisions went a certain way. It is my belief that communication helps everyone involved, and it allows bystanders to learn valuable knowledge if they choose to become contributors. ↩︎

  3. Well, you could provide migration documentation, but that’s no longer a stable API; it’s a changing API that’s a little easier for developers to adapt to. ↩︎