> > > And to add to that: Emulate instructions and features as you encounter them.
> > Run
> > > your emulator until you hit an unimplemented opcode, add it in, rinse,
> > > repeat.
> > Lemme just back up Bart here - everyone's first mistake when writing a CPU
> > emulator is just to implement all the opcodes and *then* test it. Don't ever
> > that, it makes it nearly impossible to debug :-)
> I don't think its strictly necessary that the test is done before all
> instructions are implemented and rather the important part is that the
> instruction set emulation is independently tested to some extent prior to
> debugging large applications.
> My preference is to create a reasonably exhaustive test program which exercises
> all instruction forms and associated flag settings. This is a laborious task,
> to be sure, but with judicious use of macros and a structured test procedure,
> most of the work is reduced to calculating initial and expected values.
That's personally not my cup of tea, because I'm lazy ;-)
Instead I use real programs. For example if I don't know how addx works yet, I leave it out of the core and wait till a real game I plan to run uses it. I then look at the docs on the opcode, and how it is being used.
I implement it exactly how the docs say, BUT as a sanity check make sure that the first usage of addx in the program gets the right result and flags. It's the mix of theory and practice which tends to give me the confident I have a good implementation.
I can't be 100% confident, but the confidence level is fairly high and it's a lot less work.
I'll put my hand up an admit that I do currently have a problem with ABCD or SBCD after using this method, but I'm sure I can solve it by stepping through Sword of Vermillion. Or I could always revert to a structures test procedure later.
You learn something old everyday...