[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DGR...
On Thu, 15 Nov 2012, BLuRry wrote:
I felt that way when writing the 65c02 core of Jace. I wouldn't have
gotten far without another solid emulator handy (ahem... AppleWin) to
provide a useful benchmark to ensure the CPU was tracing the execution
path correctly. If you can, figure out a way to step the execution of a
very small program and track the basics (registers, memory changes,
program counter location) to ensure it is following the right path.
The CPU element's been tested. xD I wrote it under DOS, we tested the CPU
code there, as well as part of the graphics code (see below).
Either way you'll be in a chicken-and-egg situation when you want to
test the graphics code, and the graphics output doesn't do anything to
the state of the running program unless there is detected collision (VF
is set to 1). So printing "Hello world" won't alter VF and you can test
the execution of a hello world program without having working graphical
output -- but you will need some primitive way to trace the program
execution. Once you see the program running, then you can leap to
graphics output with some degree of confidence that any future error
will be from new code and not some other untested part of the emulation.
I was thinking about the Apple ][ when I wrote the DOS code. Basically,
because I knew I wouldn't be able to test the screen without bankswitching
my program out unless I slammed some asm way down into the stack, I
actually created a 256-byte buffer (i.e., 64*32 bits) to track the status
of the screen as the CHIP-8 saw it. I don't need to ever read the screen
this way.
All that fails that I have tested is the actual function that does the
drawing, after the status of the virtual screen is already recorded.
-uso.