Conversation
|
This looks good - let me know once you like it and I will merge it. |
|
yup, this should also be good - i added to the forum thread confirming that Klaus' test suite passes. Not exactly speedy though 😅 |
|
on second thought I might fool with a couple of simple optimizations so if you want to hold off merging that's fine. it looks like inlined consts and some native support for bit-twiddling would make a huge difference (lots of shenanigans to maintain flags). do you have any favored syntax for bit twiddling, like test/set/clear a bit, or replace a masked set of bits in a cell? |
|
That sounds fine - I'll hold off on this one for now. I don't have any preferred syntax for bit twiddling - I usually just AND/OR/XOR with masks. Klaus' test suite takes a long time even on real hardware. If you got that to pass, then you should be in very good shape logic-wise. |
2 participants
This is some example TaliForth code that implements an instruction-level 65c02 emulator.
For some 6502 disassembly stuff I'm playing with I wanted some simple logic equations that described each opcode which I could use to reason about which registers or data locations were affected by a given instruction stream.
I realized that Forth would be a nice clean way to express that which was also testable. I got slightly carried away and ended up writing this full 65c02 emulator in TaliForth. As a demonstration it successfully emulates the assembled version of its own UM* word, as well as passing a large suite of tests.