6502_65C02_functional_tests VS ghidra-tlcs900h

Klaus Dormann's 6502 tests don't rely on a particular emulator environment. They could be used with Ghidra.

https://github.com/Klaus2m5/6502_65C02_functional_tests

How about some assembler code to test all of the opcodes? https://github.com/klaus2m5/6502_65c02_functional_tests

https://github.com/Klaus2m5/6502_65C02_functional_tests might be worth a look, it's a comprehensive test suite

Great! (and not surprising). You may want to look into using a 6520 test suite to check correctness of your emulator, like this one -- note: I have no experience with it, but it took me some time to iron out the last error of my 6502 emulator, and in hindsight I should probably have used such test suite.

Currently i'm trying to implement 6502's instructions one by one using TDD. I was curious are there any test - corner cases already been written ? I found out ( https://github.com/Klaus2m5/6502_65C02_functional_tests ) but this requires all instructions to be implemented which I don't currently. Is there any way to test a single instruction in isolation for all the edge cases ?

By "bad branch", I mean the emulator takes the wrong branch because it fails to emulate some part of the Apple hardware properly. The 65C02 emulation has passed some pretty stringent tests (https://github.com/Klaus2m5/6502_65C02_functional_tests/blob/master/bin_files/65C02_extended_opcodes_test.lst), so I'm pretty confident in it. But the instruction trace file is around 90,000 lines, so is kinda hard to slog through.

I've been exploring new ways of testing Ghidra processor modules. In this repo, I was able to emulate NES ROMs in Ghidra to test its 6502 specification, which resulted in finding and fixing some bugs.

Context: Ghidra is used for reverse engineering binary executables, complementing the usual disassembly view with function decompilation. Each supported architecture has a SLEIGH specification, which provides semantics for parsing and emulating instructions, not unlike the dispatch handlers you would find in interpreters written for console emulators.

Emulator devs have long had extensive test ROMs for popular consoles, but Ghidra only provides CPU emulation, so it can't run them without additional setup. What I did here is bridge the gap: by modifying a console emulator to instead delegate CPU execution to Ghidra, we can now use these same ROMs to validate Ghidra processor modules.

Previously [1], I went with a trace log diffing approach, where any hardware specific behaviour that affected CPU execution was also encoded in trace logs. However, it required writing hardware specific logic, and is still not complete. With the delegation approach, most of this effort is avoided, since it's easier to hook and delegate memory accesses.

I plan on continuing research in this space and generalizing my approaches, since it shows potencial for complementing existing test coverage provided by pcodetest. If a simple architecture like 6502 had a few bugs, who knows how many are in more complex architectures! I wasn't able to find similar attempts (outside of diffing and coverage analysis from trace logs), please let me know if I missed something, and any suggestions for improvements.

[1]: https://github.com/nevesnunes/ghidra-tlcs900h#emulation