Open dirkwhoffmann opened 4 years ago
@dirkwhoffmann if you haven't seen this https://eab.abime.net/showthread.php?t=98747 it may be useful for you as it's tons of CPU tests for 68k indented for emulators / FPGA implementations (and verified against original CPU)
I just downloaded cputtester.7z, decompressed it, and run it in my Windows VM. It has generated three files in the data directory:
I must be missing something because I have no clue how to proceed from here 😕. I would like to test the CPU of my Amiga 500. But how?
you run cputest
inside your emulator (also the data files needs to be accessible)
you run cputest inside your emulator
OK, I see. Just to make sure that I understood it correctly: If I used, e.g., adftools to create an ADF, put cputest
and the three dat files in it, could I then boot my Amiga 500 with that ADF and it would run the tests on the real machine?
If I used, e.g., adftools to create an ADF, put cputest and the three dat files in it, could I then boot my Amiga 500 with that ADF and it would run the tests on the real machine?
I understand it that way. But of course it will not start automatically to run the test.
You have to type one of the following I guess ...
cputest all = run all tests, in alphabetical order. Stops when mismatch is detected.
cputest tst.b = run tst.b tests only
cputest all tst.b = run tst.b, then tst.w and so on in alphabetical order until end or mismatch is detected.
what means this in tonis description ?
Instruction cycle order or timing is ignored. It is not possible without extra hardware.
Maybe it will test only the register state and correct execution of instructions without caring about the timing???
when copying to ADF be aware of this
Copy all memory dat files, test executable compiled for target platform (currently only Amiga is supported) and data/
contents to target system, !!! keeping original directory structure.!!!
cputest
is an Amiga executable. You can run it in any way you like as long as it can load the required files. If that is from floppy or hdd (image) is up to you. There is more info on the forum post and the source / readme. I found it very useful at least when making sure instructions work correct and sets the right flags.
Having studied the README file in more detail, I think cputester can really help to further improve Musashi's emulation accuracy. Unfortunately, I am still struggling with generation the test cases. If I leave the standard .ini as it is provided in the zip file, 0 tests are generated for each command.
All attempts to modify the .ini file didn't work out for me.
this isn't how it looked when I generated my tests for an older version. Maybe you can ask in the thread if it has broken or something?
@dirkwhoffmann For now try this older version https://www.dropbox.com/s/k4r77h0xhvklmyq/cputester.7z?dl=0 (it may of course lack some stuff but might be useful)
The old version runs just fine 😁. Excellent! Must be an issue with the latest version then.
As a proof-of-concept, I have generated tests for the OR instruction and made an ADF out of them via xdftool. I was then able to boot the ADF on my real machine and in vAmiga.
As expected, Musashi has no issues with OR 👍.
Other commands might be more difficult. E.g., the MOVE tests are so comprehensive that they don't fit onto a standard 880KB disk. But that seems to be a minor issue that can be solved. The great news is that we do have an extensive CPU test suite for the Motorola 68k now 🥳. I was always hoping that somebody is going to develop something similar to the Lorenz test suite for the 6502 which was invaluable for me when I developed VirtualC64.
Cool and toni has updated its binaries, so the latest version should now work too!! 🤓
Notice I also wrote a tester API around the code Toni did over here https://github.com/emoon/m68k_cpu_tester_api It allows you to use the tests from an API instead (it includes example for Musashi so all the data is hosted on the PC side instead and just "feed" in to the emulation) it may not work with the latest version of the tool because the format needs to be updated in my code as I need to have a separate loader for the data files.
Sorry to bother you again. This time, I have tested DIVU and DIVS and encountered an issue with the N flag.
Test cases divu5: https://github.com/dirkwhoffmann/vAmigaTS/tree/master/CPU/DIV/divu5
This test case creates some alien art by performing divisions with certain operands 👽:
Good news: Musashi performs all calculations correctly 🖖:
Test case divu6: https://github.com/dirkwhoffmann/vAmigaTS/tree/master/CPU/DIV/divu6
This test case visualises the value of the V flag (left) and the N flag (right). Solid means „flag set“, striped means „flag cleared“.
Musashi gets the N flag wrong:
I know that some references state that the N flag remains untouched when an overflow occurs, but the test case falsifies this statement. The test case shows that the N flag is set together with the V flag when an overflow happens.
I’ve set up similar test cases for DIVS, too. The issue is the same there.