Decide if a more accurate emulation of cycles taken for DIVS/DIVU operations are needed. For now we just consume a fixed worst-case amount of cycles for DIVS/DIVU, but for example EASy68k uses an algorithm from an old usenet post that uses analysis on the operands to determine the number of cycles taken.
There's also the corresponding EASy68k implementation (note that this is not the official sources, which as far as I can see are only available as a zip through the EASy68k website, but at a glance it's the same implementation)
We need to decide if we care about more precise cycle counts for DIVS/DIVU, versus raw performance (more accurate emulation is slower), and if we do that, how to handle the fact that some Musashi timings then will no longer match (unless we also patch Musashi). Some exception-rule in the QC-tests, perhaps.
Decide if a more accurate emulation of cycles taken for DIVS/DIVU operations are needed. For now we just consume a fixed worst-case amount of cycles for DIVS/DIVU, but for example EASy68k uses an algorithm from an old usenet post that uses analysis on the operands to determine the number of cycles taken.
There's also the corresponding EASy68k implementation (note that this is not the official sources, which as far as I can see are only available as a zip through the EASy68k website, but at a glance it's the same implementation)
We need to decide if we care about more precise cycle counts for DIVS/DIVU, versus raw performance (more accurate emulation is slower), and if we do that, how to handle the fact that some Musashi timings then will no longer match (unless we also patch Musashi). Some exception-rule in the QC-tests, perhaps.