perfect6502

s still about 30x slower than a real 6502 at 1 MHz). PS: Let's do some simple napkin math: the Antirez simulator is 3x slower than a real C64, 100x faster would mean around 30x faster than a real C64, e.g. like a C64 clocked at 30 MHz. That means on a 3 GHz host CPU you would have 100 host clock cycles to emulate a (30Mhz) C64 system clock cycle, and that's for 5 complex chips (CPU + 2xCIA + VICII + SID), so around 20 host clock cycles per emulated cycle for each chip, and that doesn't include address decoding and memory access (which is the expensive part in Antirez's simulator). And moving the chip emulators into threads won't help you much here, because you'd need to synchronise at least once per emulated clock cycle (maybe even twice per emulated clock cycle because of the C64's phi-1 and phi-2 'half cycles'). Good luck with that :) (e.g. squeezing a complete VIC-II clock cycle which renders 8 pixels and may have up to 8 active sprites into 20 host system clock cycles, even with perfect pipelining, SIMD, and no cache misses this isn't a lot of host CPU instructions compared to what a VIC-II needs to do each cycle). (disclaimer: I'm the author of the pin-based chip emulators used in this experiment)

nes like the East German U880 are known to have slightly different undocumented behaviour - which barely matters in practice though). The Z80 and 6502 emulators in https://github.com/floooh/chips are tested against their respective netlist simulations for correct behaviour and timing (all being based on the netlists from http://www.visual6502.org/ and the simulation code from https://github.com/mist64/perfect6502 - which is the simulation from visual6502.org ported from JS to C).

s hidden problems (neither ZEXDOC nor ZEXALL have complete "coverage" of the Z80).