As we begin to draw towards the end of the course, there are plenty of opportunities to look back on successes and struggles alike. As with most projects, there’s a solid mix of both victories and defeats, but in particular I’d like to take the opportunity to discuss my greatest success with the project thus far. In order to do this, a brief refresher and background on my project is necessary. My team is working on building an Intel 8080 emulator with the ability to play Space Invaders. One key tidbit of information on this is that the Intel 8080 was originally released in 1974, keep this in mind, it’ll be relevant in just a bit.
My biggest success, that I’m particularly proud of is a fairly recent development in our project. After our initial step of getting together our disassembler, we went ahead and started building out our emulation of the 8080 itself. This involved coding the behavior of all the different instructions available on the 8080. We would each code out a set of roughly 20 opcodes at a time, picking up another one once we were done. This led to us getting through the instructions nice and quick. Debugging was the step that came after, and that’s where we hit both a challenge and the resulting success I’m so pleased with.
For our debugging efforts, we used the recommended diagnostic test, but were struggling to follow along with the test, and as a result couldn’t figure out where things were going wrong. So, after a lot of scrounging around through the depths of the internet, I found a differently named version of the same diagnostic, along with an output log of accurate instruction usage. Armed with our beautiful new .txt file, I was able to get our emulated CPU fully debugged. I consider that a great success, as from what I’ve seen, properly debugging an emulator is often a genuine nightmare, as there are so many things that can go wrong. Now, there may still be a few people here and there who ask, “But what did getting it debugged really do for you?”. To that, I say this. First and foremost, it gives us a fully functional CPU, which is fairly important for running Space Invaders, and any other game or program that was available for the Intel 8080. Building on that concept, it turns out to have had an impact I wasn’t quite expecting. While I was working on debugging with a teammate, we had another member working on rendering the game’s graphics. After getting the CPU fully functional, it ended up ensuring that the graphics came out crystal clear in comparison to what they had been. So being able to play my part in debugging means a fully functional CPU and graphics that render properly; a pretty big deal in my opinion!
I’d say the experience of debugging and getting the 8080 CPU functional managed to teach me a somethings about the technology itself, and more importantly, myself. Regarding the technology itself, I suppose there’s a fairly obvious bit of wisdom that even the smallest bug can derail an entire piece of software, as seen by the major shift in rendering graphics going from mostly functional to fully functional CPU. Beyond that, digging through the guts of the emulator for hours on end really gave me a better grasp of lower level programming, whether we’re discussing the usage of flags, or the management of the stack. I suppose I’d also say it gave me a chance to review some concepts learned in assembly class; things like 2s complement subtraction would pop up with some consistency.
What I learned about myself can be boiled down to two core things, I very much enjoy lower level programming, and I enjoy the process of unraveling a bug very much (or at least some specific parts of the process). I really think I already knew that I prefer lower level work in comparison to do something like web development, but this really reinforced the concept for me. I know web development is a major thing, but I’ve just never felt the appeal. Part of why a lot of the positions I’ve been applying for are more in the vein of writing C or C++ code. I really enjoy being able to dig into memory and dealing with code that’s more directly tied to hardware (or at least the emulation of hardware in this case). Bug squashing is something that I’ve come to realize I enjoy thanks to this project. Or more specifically, I enjoy the overall process, and the very satisfying payoff. I don’t think anyone actually enjoys the frustration of getting stuck and not being able to find what is breaking things. So all said and done, I think this project has done a really job teaching/reinforcing the idea of what I really enjoy doing in the field, and that holds a lot of value in my eyes.
This course has been very satisfying, and while my team and I have a number of challenges to beat before we can truly say we’re done, my capstone project has had a lot of value to me. Between failures and successes like the one from this post, I’m excited to wrap up this capstone and this degree and really get into the field. Here’s hoping for a successful end to the quarter and a successful (and short) job search!
Leave a Reply