The final test of the system is get the actual Nintendo game code to run. This is much more challenging than the test code used to debug the different components. The code chosen to run on the hardware was Nintendo Tennis, because of it simple graphics requirements. Testing with real code executes a mass of instructions to setup all of the game data structures and configuration. Furthermore, the source assembly is completely uncommitted which makes understanding exactly where the code fails a challenging task.
The debugging tools are critical in this testing since it can take many hours before reasonable output is generated and the simulation could break at any moment. Debugging this code includes studing the code, trying to comment it, examining the execution flow, and also how it is setting up the graphics hardware. Since the game code will execute almost all of the different instructions, if there is a remaining a bug in the design, it will cause a fault to occur that may not be clearly visible.
For example, I noticed that the Nintendo code went into an infinite loop inbetween the third and fourth frames. This required me to step through the code starting at the end of the third frame looking for where it could have entered the loop. As it turned out, the control logic had a design flaw in the way it calculated overflow in branching, addition between a unsigned and signed values. This required an additional signal to be exported from the datapath to the control for calculating this overflow. Since the design was kept modular and expandable, this change required little structural changes, and was working after the first recompilation.