3 ms·

Compare your observations of this project, with what you may feel about the 6502 emulator in oriculator: https://code.google.com/p/oriculator/source/browse/tru

Compare your observations of this project, with what you may feel about the 6502 emulator in oriculator: https://code.google.com/p/oriculator/source/browse/trunk/6502.c#980 https://code.google.com/p/oriculator/source/browse/trunk/650... Which do you find easier to read/understand/work on? In my case, I still think the #include'd switch case's to be less readable in comparison .. although it must be admitted that oriculator uses the C macro processor in its own nefarious ways .. "READ_ZIX;" indeed .. ;) (BTW, oriculator is a very mature 6502 emulator .. and also rocks as a way to return to the glory days of the 80's machines that never got enough love: the Oric-1 and Atmos...)

haldean 13y ago
oriculator is much more powerful and complex than x6502, even you ignore the non-CPU emulation bits (like video and emulated controller, which are complex and difficult). The fact that they manage to get approximately correct timing is really impressive, and involves lots more logic around opcode decoding because you need tables of how many instructions each one takes. That said, I find it much more difficult to read. The reliance on long, complex macros means that I need to flip back and forth between the macro definitions and the opcode interpreter, and long, multi-line macros like they have give me the heebie-jeebies. I'd rather see inline functions used (like x6502 does in functions.h; the functions in functions.h serve much the same purpose as the macros in oriculator). Not to take anything away from the project -- it's obviously an amazing software project and an incredible achievement. We just set out with different goals in mind: mine was more pedagogical, and theirs was more practical.