search

kstenerud / Musashi

Motorola 680x0 emulator written in C
412 stars 93 forks source link

DIVU / DIVS: N flag is wrong #63

Open dirkwhoffmann opened 4 years ago

dirkwhoffmann commented 4 years ago

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 👽:

divu5_A500+

Good news: Musashi performs all calculations correctly 🖖:

Bildschirmfoto 2019-12-29 um 09 37 38

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“.

divu6_A500+

Musashi gets the N flag wrong:

divu6_vAmiga

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.

emoon commented 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)

dirkwhoffmann commented 4 years ago

I just downloaded cputtester.7z, decompressed it, and run it in my Windows VM. It has generated three files in the data directory:

Bildschirmfoto 2019-12-29 um 19 10 34

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?

emoon commented 4 years ago

you run cputest inside your emulator (also the data files needs to be accessible)

dirkwhoffmann commented 4 years ago

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?

mithrendal commented 4 years ago

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.!!!

emoon commented 4 years ago

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.

dirkwhoffmann commented 4 years ago

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.

Bildschirmfoto 2019-12-30 um 09 25 25

All attempts to modify the .ini file didn't work out for me.

emoon commented 4 years ago

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?

emoon commented 4 years ago

@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)

dirkwhoffmann commented 4 years ago

The old version runs just fine 😁. Excellent! Must be an issue with the latest version then.

Bildschirmfoto 2019-12-30 um 10 11 02
dirkwhoffmann commented 4 years ago

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.

IMG_2261

As expected, Musashi has no issues with OR 👍.

Bildschirmfoto 2019-12-30 um 11 22 27

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.

mithrendal commented 4 years ago

Cool and toni has updated its binaries, so the latest version should now work too!! 🤓

emoon commented 4 years ago

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.