I found that design decision a bit odd as well, as the author states multiple times that he's interested in cycle-accurate emulation. When people go for a cycle-accurate emulator, they are purposely eschewing performance for accuracy. e.g. the Higan emulator which focuses on accuracy/code readability, but it's one of the slowest SNES cores out there (and it's fine)
I took that to mean it takes less pico cpu power to reach the same cycle-accuracy.
Esp since there arent graphics routines in the c64 to speak of! There are no plot, screen clear, line, etc. Every program rolls its own.
As a joke a real freak could polyfill/hijack e.g $ffd2 output single char to cursor position in native pico code instead of 6502 to accel basic programs. That could be weird and phone to speed up all thise routines... but at that point just clock it all faster :)
Comments
argh, too bad. If one goes the cycle-accurate way, then not doing everything accurate is a bit strange... I wonder why they made that choice...
I found that design decision a bit odd as well, as the author states multiple times that he's interested in cycle-accurate emulation. When people go for a cycle-accurate emulator, they are purposely eschewing performance for accuracy. e.g. the Higan emulator which focuses on accuracy/code readability, but it's one of the slowest SNES cores out there (and it's fine)
I took that to mean it takes less pico cpu power to reach the same cycle-accuracy.
Esp since there arent graphics routines in the c64 to speak of! There are no plot, screen clear, line, etc. Every program rolls its own.
As a joke a real freak could polyfill/hijack e.g $ffd2 output single char to cursor position in native pico code instead of 6502 to accel basic programs. That could be weird and phone to speed up all thise routines... but at that point just clock it all faster :)