FX68K Cycle accurate 68000 core

[fpgaarcade]

Imho there were 3rd party cores for the replay that had such a restriction.

Anyway, making it open source sure will make it a success.

That was a long time ago, and Wolfgang has relaxed his rules. We are moving everything public for the Arduino board.

[npomarede]

(All models except 68040)

Does that mean 040 executes the instruction as described in the manual? What about 060?

From Toni's comment in the changelog : "68040 : LINK stacked value is saved after SP was decreased by 4." . The 68060 seems to behave like 68000 in this case, ie "LINK stacked value is saved before SP was decreased by 4."
You can check this WinUAE thread for a list of all the changes that were detected using the cputester against real HW : http://eab.abime.net/showthread.php?t=98746. So far, all those changes were merged into Hatari's devel version?

Nicolas

[ThorstenOtto]

You can check this WinUAE thread for a list of all the changes that were detected using the cputester against real HW : http://eab.abime.net/showthread.php?t=98746. So far, all those changes were merged into Hatari's devel version?

Wow, lengthy list of bugs detected. Of course 99% of them maybe be not relevant for normal programs. Guess i have to take a look again and sync them with aranym. Did you also merge the changes to the JIT compiler?

[npomarede]

Did you also merge the changes to the JIT compiler?

Yes they were merged too, but as JIT is not used in Hatari I can't say if it breaks things or not.

[ijor]

It was fixed in july/august when Toni started working on his 680x0 cputester and commited in WinUAE 4.3.0 beta 1 :

LINK stacked value is saved before SP is decreased by 4. Only affects pointless LINK A7,#x variant. (All models except 68040)

This is (obviously) about LINK, and not about UNLK, which was the case in my post. But yeah, it is the same idea. In this case the An value is copied to a couple of temporary registers while performing a prefetch. And then later, the temporary registers are written to memory.

You can check this WinUAE thread for a list of all the changes that were detected using the cputester against real HW : http://eab.abime.net/showthread.php?t=98746. So far, all those changes were merged into Hatari's devel version?

As I just commented by PM, both to Nicolas and to Toni, I believe that list is not 100% accurate. Need to verify to elaborate and be more precise.

[ijor]

You can check this WinUAE thread for a list of all the changes that were detected using the cputester against real HW : http://eab.abime.net/showthread.php?t=98746. So far, all those changes were merged into Hatari's devel version?

As I just commented by PM, both to Nicolas and to Toni, I believe that list is not 100% accurate. Need to verify to elaborate and be more precise.

As I said, the 68000 behaviour described in that thread is not 100% accurate. We are going off topic here, so I opened a separate thread to elaborate about one of the issues that, I think, it is quite interesting:

http://atari-forum.com/viewtopic.php?f=68&t=37890

[ijor]

Last update adds support for HALT single step.
Not relevant for most platforms. On most platforms HALT is used only for hardware reset.

Please note that a new input port, HALTn, has been added!
Initially I tried using SV default input port values to avoid modifications when this feature is not used. That would allow the new port to be optional. I found out that unfortunately not all compilers support default input port values.