It works. Kind of?
There comes a point in every programmer’s education/career where, after spending weeks writing and testing code, one excitedly compiles and runs their code, expecting great things. Often, there seems to be a bug that is causing the program to behave unexpectedly and worse, in the worst case, it seems impossible to find or diagnose.
As far as I’m aware, every programmer has to deal with this situation, regardless of how competent/experienced they are. Perhaps there are people that don’t make mistakes, but that’s certainly not me.
Our 8080 emulator has all the requisite instructions to run Space Invaders. We’ve fastidiously followed the advice and directions of those who have worked on or completed similar projects, and yet, things are not working as we would hope.
Here is the output of a Space Invaders emulator that works, at the title screen:
Our title screen looks similar, but the section under “Score Advance Table” is shifted to the right, so that only the left-half of the sprites is visible on the right- side of the screen. Bizarre.
But what’s this? One of our instructions, RNZ, is not implemented correctly! What if we fix it and run the code again?
Brilliant! Our emulator now displays the main menu and scoring table. All it took was inspecting the code visually. Unfortunately we haven’t found any other errors, and the program crashes once it attempts to enter “attract mode”, which is the game’s demo mode. The emulator is asking for yet another instruction to be implemented, but since other 8080 Space Invaders projects don’t emulate this instruction, let’s instead try running the program a few times to see how it behaves.
Power (sometimes) corrupts
Every programmer that’s ever been introduced to, or heard of C, might have heard a famous quote by Bjarne Stroustroup (creator of C++) “C makes it easy to shoot yourself in the foot.” What he might mean by this statement, at least partially anyway, is that as a C programmer, you’re responsible for allocation/de-allocation of memory in your own program. Often people new to C/C++ are not familiar with the ins and outs of memory allocation, specifically the program stack and heap.
The “corrupted size vs. prev_size” message we see above is a symptom of heap corruption, which is when a program attempts to write too many blocks of data to an area of memory with a limited capacity. It seems that we’re writing too much data to an area of memory, so we’ll likely have to visually inspect our code again to attempt and rectify this issue.
A last resort
And if our team can’t seem to figure out how this heap corruption issue is occurring by visually inspecting the code?
There might be a way out of that. Since we know that there are working Space Invaders projects, we can attempt a crude, but possibly effective technique for debugging our code. We can print the status of the CPU for our own project, say for the first 2000 instructions, and print them to a file. We do the same for a known working project. In particular, we print all the register, flag, and SP values. If we see a discrepancy between the two files, we can see where it occurs and inspect the surrounding instructions to ensure things are working as they should.
The nice thing about this technique is that we might not even have to do a visual inspection of the code to find any discrepancies; there are command-line utilities that do a character-by-character analysis of two files, and can highlight differences between those two files. A crude technique possibly, but it might end up pointing our team in the right direction.
Our goal for the following week is to continue debugging until our game works flawlessly in black/white mode. Once we have that working, we’ll be adding color and audio to our game, which hopefully we can discuss next week!
