the video output of the target, shown in the accompanying figure. In this example a sprite’s location is definitely incorrect. The top sprite is offset from being in the expected column and is at 13, 11 instead of 24, 11. We know the aliens always attack in columns, so something is wrong with the emulator. A pair of values in the emulator’s memory state determines the sprite’s position. This address would, in fact, be the location of a video hardware register that directly determines the displayed position. You can use the platform debugger to confirm the register values are, in fact, 13, 11. Unfortunately, even if you know the values are wrong, finding the actual error is not easy.

The incorrect register values are the
end of a chain of earlier calculations
(see the accompanying sidebar “Screen
Image Chain”). Finding the error in-
volves working backward through the
causal sequence to find where the mis-
calculation occurred. The debugger,
however, shows us only the current
state of the machine. If it is possible at
all, reconstructing the event chain will
involve a lot of detective work.

traces to the Rescue
There may be an easy shortcut to solv-
ing the problem. If you are trying to
create a faster emulator from an exist-
ing one that is known to work, then
you can use the correct emulator to
debug the incorrect one. The correct
emulator can be modified to create a
trace of input and CPU state, and the
target emulator can read this trace file
(see the accompanying sidebar “An Ex-
ample 6502 Trace”). The input values
are used instead of real input (joystick
positions). After each do-instruc-
tion call, the current machine state
is matched with the trace, and execu-
tion is halted on divergence. At this
point you can use the host debugger
to examine the problem in detail and
find the resolution.