Instruction timing mismatch

[dirkwhoffmann]

In order to test vAmiga (which is powered by Musashi), I started to write some basic CPU timing tests:

https://github.com/dirkwhoffmann/vAmigaTS/tree/master/CPU/ANDI/andi1 https://github.com/dirkwhoffmann/vAmigaTS/tree/master/CPU/BCHG/bchg1

Here is how test "and1" looks like in vAmiga (using Musashi):

Explanation:

Blue area: The Copper is used to trigger an interrupt. Red area: The interrupt handler takes over. Yellow area: The instruction under test is executed several times.

Lines: 1 and 2: Several NOPs are executed to generate reference timelines. 3: andi.l #$80008010,D0 is executed 8 times. 4: ori.l #$80008010,D0 is executed 8 times. 5: andi.w #$8010,D0 is executed 8 times. 6: ori.w #$8010,D0 is executed 8 times.

The picture shows that Musashi consumes 14 cycles for andi.l (which is wrong) and 16 cycles for ori.l (which is correct).

Here is how the test looks on the real machine (andi.l and ori.l both consume 16 cycles).

Hence, line

andi      32  .     d     0000001010000...  ..........  U U U U U  14  14   2   2   2

should be replaced by

andi      32  .     d     0000001010000...  ..........  U U U U U  16  14   2   2   2

There is another mismatch for commands BCHG and BCLR. These consume two cycles less if the bit number is smaller than $10:

Lines: 1 and 2: NOPs are executed to generate reference timelines. 3: bchg d0,d0 with d0 == $0 is executed several times. 4: bchg d0,d0 with d0 == $10 is executed several times.

The latter issue might be hard to fix, because I understand that Musashi is reading the cycle counts from a table that has a single row for each instruction and addressing mode. Apparently, for some commands, the cycle counts depend on the operands, too.