Vamiga: CPU test or.w fails

[dirkwhoffmann]

• The good:
  Moira can boot the workbench with no issues now and the performance decrease is hardly noticeable 😎.

• The bad:
  CPU test or.w (the only test I have at the moment) fails 🙈:

• The ugly:
  It's almost certainly not the OR instructions itself, but the surrounding testing code. There are some features of the M68000 CPU that are not implement yet such as tracing. Maybe the cputest frameworks makes use of it. Don't know 🤔.

[tonioni]

Most likely illegal instruction exception stacked PC field is wrong.

Tester logic is technically simple and does not require any CPU special features:

Take over the system, jump to supervisor mode, fill test memory regions, fill registers, set all exception vectors, fill both stacks, push test SR and PC to super stack, execute RTE -> test instruction is executed (generally in user mode), following instruction is $4afc (ILLEGAL) (this is simplified, in reality it alternates between NOP,ILLEGAL and ILLEGAL,NOP because it can make a difference when previous instruction caused bus or address error..), used exception vector is stored, registers are stored (and few other things).

Finally results are compared against expected values in dat file.

[mithrendal]

Musashi executes the test with a positive result ?

Is it possible to stop at the pc=30800

and compare the CPU state/output values with the Musashi core ?

When I understand the program correctly we have to watch out why the PC is 2 bytes off.

When I understand toni correctly, after each test an exception is generated. This exception pushed the "2 bytes off"-PC to the Stack, e.g. PC+6 instead PC+4.

[dirkwhoffmann]

Most likely illegal instruction exception stacked PC field is wrong.

Hi Toni,

yes, this perfectly makes sense. My test program for Moira (applied for unit-testing) runs Moira agains Musashi for each possible opcode with pseudo-randomly generated extensions words. And indeed, I am skipping all unused and illegal instructions in this loop. I’ll look into it asap.

Let me take the chance to thank you once again for writing cputester. It comes with the perfect timing for me. It was just a couple of weeks ago when I took the decision to write a custom CPU for vAmiga and since then I’ve been racking my brain trying to figure out the right way to test it. Now, it’s clear which is the right way to.

[dirkwhoffmann]

and compare the CPU state/output values with the Musashi core ?

This is the brute-force way to find the bug (in the (unlikely) event that it's not related to the illegal instruction exception). To make testing easier, Moira has a "Musashi compatibility" mode which emulates some of Musashi's quirks (wrong cycle numbers etc.). Using this mode, I can basically run vAmiga up to an arbitrary cycle number (one run with Musashi and one run with Moira) and see where the execution trace starts to differ. The only issue with this approach it that's it's time consuming. I cannot simply dump the complete instruction trace into a file because of it's bare size.

[dirkwhoffmann]

As predicted by Toni, I was pushing a wrong PC to the stack. Now, it works perfectly well 😎:

As a side effect of updating my Musashi/Moira test runner, I have found three more Musashi bugs (already reported to them).