2026 Project Plans

Just a quick post where I wanted to collect some thoughts together I've been having over the past few weeks about a switch in the projects I want to work on during the course of the year.

Foenix

2025 ended up being a year where I spent a lot of time and energy on Foenix-related projects, for the F256K and the A2560K. I ended up forking the Foenix Toolbox into something a little bit different and closer to the Foenix Toolbox's precursor, Foenix/MCP. I ended up calling this project "FNXDOS".

This project has come a long way and I'm quite happy with it. It runs on both the F256K (gen1), and the A2560K now as well. However, there is still a lot more to do before I'd call it release-ready. The most important blocker for release is that I don't yet feel like I've stabilized the public APIs that applications developed for FNXDOS would use. These are the functions that would exist in ROM for things like file I/O, basic text screen functionality, and other simple hardware access. It's actually pretty basic stuff overall and is not meant to be fully comprehensive, as these are devices which encourage you to just use the hardware directly. But still, some stable basic API is useful.

However, I think that I will be setting Foenix-related projects aside for now.

The reason for this is that I've been spending a lot of time on adding support to the A2560K, which frankly, is much more interesting a device to me than anything F256-related. But, Stefany is understandably very focused on delivering the A2560M and I have no current intention to buy an A2560M.

I spent a lot of money on my A2560K and I would say it only finally became usable for stable development in just the past couple months or so due to some very recent FPGA fixes. And there are still what I would call fairly serious problems or shortcomings with it, specifically regarding graphics functionality. It's not that graphics support is completely broken or anything. But the way that bitmap-level access to VRAM works right now is far too slow to be that useful, and there's a very unfortunate endianness-mismatch that makes working with VRAM at a per-pixel level completely impractical. As well, the existing sprite and tilemap functionality feels a bit ... unfinished? Anyway, this is impacting the kind of stuff that I know I will want to do with this device, so I'm reluctant to spend a lot more time on this device until I see more clear evidence that these issues will definitely be addressed.

Stefany is aware of these issues, but has made it clear that they won't be addressed until sometime after the A2560M has finally been shipped or finished or whatever you want to call it. I think a more realistic estimate of when this will happen (if ever ... and to be clear, I do really think it's an "if" not a "when") is "late 2026." I just think it's more realistic to think that post-A2560M-shipping, Stefany ends up needing to spend time addressing bugs or other things that people find in that product, and that it'll understandably get priority because she is currently selling that product, while the A2560K is not something she sells anymore.

But again, personally for myself, I don't see the point in spending more time on projects related to the A2560K until I see some guarantee that the graphics bugs and other limitations/shortcomings in the FPGA are addressed. Otherwise, I end up with no real interesting projects to work on for that machine once I finish up with FNXDOS, at which point it would feel like a big waste of time and effort to me.

What else?

I've been thinking a bit more about projects which I can at least somewhat tie into some form of "career development" while still not being extremely similar to anything I've been doing at my day-job. So, again, this means mostly anything web-related is out.

But just as far as technology-stack goes ... I've been thinking about working on projects in C# and .NET. I've been keeping tabs on what Microsoft has been doing with .NET ever since ".NET Core" was first announced, since that was what I remember wanting .NET to be (cross-platform, not Windows-only) originally way back in the early/mid 2000's which only finally happened in some form due to the Mono Framework, which was never what I'd call perfect.

With the past couple years at my day-job having taken me out of day-to-day software development in a way which feels extremely concerning to me career-wise right now, I think that trying to do something "retro-like-game-dev" with .NET and C# might be a good way to get better acquainted with that ecosystem and might help somewhat keep me from falling too far behind with current technology stacks. It won't be web-related, but at least I'll still have some legitimate ability to claim relevant experience with something modern.

Back in 2019, I wrote about an old project of mine which was originally written in in the early 2010's in C++. I also mentioned at the end of that post that I had ported some of it to Java with libGDX around 2013/2014. As I skim through that old post now, I realize that I apparently neglected to mention that I had also ported that C++ framework to C# and had it running fully cross-platform via the Mono Framework also somewhere around 2012-2015 or so. Kind of an odd omission from that post now that I think about it, considering that it was a considerable effort, heh.

My plan for 2026 is to not quite "revive" or "resurrect" those projects, but to revisit it all and re-implement it with modern .NET and C# with some lessons learnt applied. I definitely do not actually want to revisit the specific games mentioned in that post, but I'd like to re-implement a similar type of framework and use it to work on new projects.

This will be quite a lot of work, but I also think it'll be a lot of fun and I'm looking forward to it!