An update on projects
Traditionally, I haven't written much about my life and what I'm working on. I keep most of that stuff for my Twitter, but it might be interesting to write short updates once in a while. I don't know how much I want to write about my personal life, but I'm happy to talk about programming projects.
I've been working on my Gameboy emulator for two or three years now, on and off. I get stuck on something, leave the project for a while, then come back to it at some point. This strategy works pretty well, it turns out. I recover some motivation, and I'm ready to tackle whatever problem was stumping me with fresh eyes.
It's getting pretty functional now. In theory, it supports:
- CPU and memory emulation
- Joypad input
Some major missing features:
- Memory banking
Of the features that are "supported," there are almost certainly still bugs. Debugging means running a game that clearly doesn't work as intended and reading the disassembled instructions to check that nothing unexpected is happening. That's a pretty slow process.
Fortunately, I've been hankering to build a debugger for a while. In the context of this emulator, for now that means building an interface for setting breakpoints, stepping, reading memory and register values, and disassembling code. I had already hacked something together to debug previously, but I want to build something with a nicer interface.
It's a decent amount of work, but I think it will save a lot of time debugging the emulator itself.
Related to the emulator debugger, I started playing with writing an assembler for the Game Boy. I found out I was pretty dissatisfied with existing assemblers, and I thought it would be really interesting to try to create debug info. This would allow label names to be retained after assembly, for example. If you had the source for an executable, this could be really useful for debugging---for example, writing a Game Boy game. As far as I know, no other emulator supports this feature.
Ironically, though the emulator is written in Python, I decided to write this assembler in C++. Hopefully in a future post, I'll have some thoughts on this decision!
I've been following an OpenGL tutorial at [https://learnopengl.com/]. It's a neat opportunity to play with 3D math, and I don't have much experience with low-level graphics programming, either! Previously, SDL is as low-level as I've gone.
So far, my thoughts are that it's a well-written tutorial, and a fun exercise. Besides, a nice refresher on linear algebra.
A few weeks ago, I started on a C++ library for reading the NBT binary file format that Minecraft uses. Eventually, I want to use it to build a top-down Minecraft world viewer. Maybe I'll also write some Python bindings.
I hacked out a Forth bytecode interpreter recently. C++ was a really nice language for writing it. It's truly "hacked out" for now---I need to write some unit tests, and I need to write an actual compiler to run real programs with it. Certainly it's not compliant with the ANSI standard yet. Maybe one day! Ultimately it would be really neat to combine the compiler with my Game Boy assembler and build a game in Forth.
No code to show for this one, but I started playing with noise generation. I thought about using GNU Octave to plot stuff, but I ended up using Jupyter and matplotlib. So far, I haven't run into any limitations. It was a good opportunity to learn how to plot things like vectors. Right now, my code is broken!
I think it would be neat to try to generate maps, geological features, weather, etc. I don't have a goal in mind, particularly, but I see it as a neat way to learn about the "mechanics" of the real world---simulating rainfall based on wind, proximity to a body of water, elevation, and so on.
Clearly, I have plenty to work on outside of work! I tend to bounce around between projects as motivation waxes and wanes. Stay tuned! I'm hoping to share some knowledge as I learn things from these projects.