Diff MAME version of Musashi with current about r68k HOT 29 OPEN

Very interesting! I completely agree it's worth checking out!

from r68k.

👍

from r68k.

And the other way around, MAME still have the ADDA bug, it seems. https://github.com/mamedev/mame/blob/master/src/devices/cpu/m68000/m68k_in.cpp#L1248-L1254 and https://github.com/mamedev/mame/blob/master/src/devices/cpu/m68000/m68k_in.cpp#L1273-L1279 should evaluate OPER_AY before AX...

from r68k.

Ah.. Interesting :)

This is something that one needs to make sure of to handle also:

mamedev/mame@b025f69

from r68k.

For the disassembler I found quite a bit of issues as well when I worked on this

https://github.com/aquynh/capstone/blob/next/arch/M68K/M68KDisassembler.c

I know I submitted a few changes back but I missed quite a few I'm pretty sure of

from r68k.

Oh btw. Notice this clr on 000 mamedev/mame@844e696

from r68k.

I've noticed that as well, but didn't care for now, as I feel it would only affect "real-world" devices.

from r68k.

Yeah I guess that is true.

from r68k.

And I guess this is taken into account with the cycle count? As I would assume this would make clr slower but I may be wrong.

from r68k.

If we where to add more accurate cycle counting based on actual RAM-accesses etc, then yes we would need to account for one less read-cycle. Today if the opcodehandler first access RAM (which should costs 4 cycles I think) and then cause an exception, we act as if the instruction was in fact "for free" and only count exception cycles. In real life, the actual cycles taken would depend on how much work the instruction had done before the exception happened, but cycles are not accounted for on that level.

from r68k.

Obviously a "fixed" implementation of CLR would do one more memory read, which would take non-zero time in the real world.

from r68k.

Yeah I wonder if a move (with a dn register set to zero) would be faster in the real-world then compared to a clr

from r68k.

I might actually test it at some point and see :)

from r68k.

Ah, you meant real-world CLR, yes this "feature" makes the instruction 4 clocks slower than absolutely necessary, which you should be able to see if comparing the cycle counts for CLR in the 010, which doesn't do a useless read first.

from r68k.

Yeah I just wonder if a move d0,(a0)+ would be faster than clr.w (a0)+ in the real-world.

from r68k.

Well, either way that should be evident if you compare cycle counts for the two, see the M68000UM section 8, which I don't have time to do now ;)

from r68k.

Yeah, will do :)

from r68k.

Looks like its taking the same amount of cycles (12)

from r68k.

Oops, they have fixed the adda-bug, I now notice!

from r68k.

Ah :) Yeah it would be interesting to just diff the code but it seems they have C++:ified the code so that might prove a bit hard :/

from r68k.

I took a look yesterday, and there seems to be history back to dec 2007, using Musashi 3.31 according to the source code. In particular, one interesting change, is fixing the dependencies on global functions preventing the use of several different Musashi-cores at the same time. Remaining global functions takes a CPU-core as an argument, I think.

Maybe, with some work, it would be possible to both use latest MAME-Musashi (4.90 i think), which I guess would include a few fixes not in https://github.com/kstenerud/Musashi, as well as remove the globals-depencencies that force us to serialize Musashi access with a MUTEX. This would improve test performance greatly, allowing multithreaded tests.

Don't know how much dependencies to the rest of MAME that has crept into the codebase, though.

from r68k.

Yeah that would be nice. I really never liked that Musashi has global functions with no context so yes that would be nice to get it.

As MAME is multi cpu I would imagine they keep the code fairly separate and just don't throw lots of specific stuff in there but you never know.

from r68k.

You didn't find any other opcode specific fixes? (I haven't looked myself)

from r68k.

No,, but I didn't spend too much time looking either. It seemed that the adda fix was just a side effect of removing a lot of macros. Several fixes to 020+ though, including actually emulating 020+ and ColdFire

from r68k.

Alright. Good to know.

from r68k.

And I think they added some more event callbacks (one for TAS in particular, which apparently uses a different bus-cycle in real-world, which can have HW-side-effects which might need to be emulated), as well as allowing bus errors to be triggered externally, and some fixes to exception stack formats IIRC.

from r68k.

I see. I guess some Arcades/games may have relied on it (both by intention and non-intention)

from r68k.

Good guess. They specifically mentioned two games that actually depended on the TAS write not to succeed (apparantly, the callback allows the host to specify if the write should be allowed or not).

from r68k.

Ah I see... Must have been "fun" to track down :)

from r68k.