BillG wrote:
zeefour wrote:
Looking at the original emulator code (largely untouched), the only potential major inefficiency I see is that the opcodes are parsed as a long switch statement (shades of old Windows programming *grin*). A lookup table might be faster and I have plenty of room for one. But in reading a bit about switch vs lookup tables it's not clear that one has an advantage over the other depending on the compiler implementation and what optimizations they make. Also, the lookup table would likely just be a mapping to function pointers, adding another level of indirection and M0 compute cycles. Any thoughts? Either way, I'll probably defer rewriting things to a later version so I can get what I have published sooner than later.
A decent compiler should be able to pick the best way to implement a switch, whether by a series of compare and branch tests or a jump table.
The calculation of the states of the flags can sometimes be streamlined by the use of tables.
A couple of updates for you.
1. Just published the GitHub repo, see new thread...
2. I noticed that Mike Chambers published his Fake6502 code here on 6502.org. It appears to use a lookup table, or jump table but at least it ISN'T using a switch statement. I tried it and it seem to actually run a bit slower than the switch version he put out for the Arduino (not available on 6502.org). So I just reverted back to my old switch-statement code and I'll run with that. With heavy compiler optimizations it runs about 0.8Mhz and as Adam Osborne once said "adequate is sufficient"
3. I took a bit longer to get this out because I realized I had the infamous BCD bug. But I plugged Mike B's BCD patch in and it worked a treat and EhBasic gives the proper results to HEX$(). Yay!
It might be good if someone updated Fake6502 to include that as well.Barring any bugs that raise their ugly heads, I'll get back to my other project and see where this one goes over the next few days.
It's been a fun rabbit hole and I've learned a lot about the Apple I and 6502 emulations in general.
Robert