Unit-testing.

[ghost]

So, as i ponder of more improvements of changes and ways to contribute in terms of optimizing the code base to be faster, there really needs to be unit testing to ensure changes don't break the code base.

I am willing to write the entire test suite, the issue is, i will need a lot of test vectors, which i don't have the time to fully obtain them, if somebody wishes to help with this effort and obtain test vectors for each of the chips (the cartridge and input portions i can do easily) we could have a method of ensuring nothing breaks and possibly finding bugs within the chips themselves.

This is apart of #17 as fixing this up for BSD's would be simple, but that would come at a later time. currently optimization should be the goal on top of furthering progress of the compatibility with games.

[nukeykt]

optimization is not a goal anymore, I want to keep code more 1:1 with new verilog conversion and keep C code as reference implementation that is easy to debug (having hard time to debug verilog code atm heh). Working with optimized code is much harder, for vdp for example I had to dig up early (and buggy) revision. I'd rather start from scratch if I wanted faster emulation tbh and write it in more traditional way (not _Clock or whatever mess). Of course, nothing stops you from making a separate fork with optimized version, i won't oppose that

[ogamespec]

Unit tests can always be broken and nothing bad will happen :) Let's wait for HDL chips implementation, then it will be possible to compare not by signals but by contexts (chip state Vs simulator state in C).