chips

if undocumented behaviour is correctly implemented, but maybe updating WZ is handled elsewhere (there are references to the WZ register in other places). In the end, if it looks and feels like a Z80 from the outside (e.g. the right pins are active at the right time) the internal implementation doesn't matter.

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).

outout :) Here in the "sister project" there are some re-used windows from my debugger ui visible (https://colourclash.co.uk/cpc-analyser/), which I think is very cool because it shows how existing Dear ImGui code can be used as UI components (for instance I also re-used the hex editor from here: https://github.com/ocornut/imgui_club/tree/main/imgui_memory...)

heavy burden on the host CPU branch predictor. ...and that's how a theoretical 1000x speedup suddenly becomes a 10x speedup, it's not the CPU emulation (this is usually cheap) but the rest of the emulated system which can be expensive. Different emulators use all sorts of tricks and shortcuts, but usually with tradeoffs like less precise emulation, or less 'compartmentalized' code. PS: case in point this is just the top-level per-cycle function in my C64 emulator, which in turn calls per-cycle-functions in each of the chip emulators (which may each be just as much code): https://github.com/floooh/chips/blob/9a7f6d659b5d1bbf72bc8d0... I'm trying to strike a balance between 'purity' (e.g. an entire emulated system can be 'plugged together' by wiring together chip emulators, just like one would build a real 8-bit computer on a breadboard), while still being fast enough to comfortably run in realtime even in browsers (https://floooh.github.io/tiny8bit/c64.html). It's definitely possible to implement a faster cycle-correct C64 emulator with a less 'pure' architecture, but it's quite hard to do meaningful optimizations while keeping that same 'virtual breadboard' architecture. ...considering all the code that runs per cycle it's actually amazing how fast modern CPUs are :)

lting binary code size a bit). Complex instruction logic like DAA are still essentially hand-written C functions though, the code generation mainly helps with the "mundane" parts of an instruction, like opcode fetch, and regular memory load/store machine cycles. One nice side effect of using code generation is that it is very easy to create variations of the emulator. For instance I created a cycle-stepped version of my 6502 emulator (versus the previous instruction-stepped version) with surprisingly few changes to the code-generation script. PS: the whole stuff is here: https://github.com/floooh/chips PPS: an interesting approach (which I haven't tried) for 6502 emulation would be to use the 6502's decode ROM (aka PLA) as the "base-data" for code generation.