Hi,
On perjantai 26 kesäkuu 2015, Douglas Little wrote:
Ok thanks for explaining - I didn't understand that the MFP depends on
the CPU in the same way as the DSP.
Still, I can't explain why it worked so well before, unless somebody
deliberately did something to make the results look correct in earlier
versions (other than CPU cycles alone - which were definitely not correct
in the cases I mentioned). Weird.
I think there *is* rather large change in how cycles are handled
in WinUAE CPU core.
AFAIK earlier 030 versions used hand-coded, static, per-instruction
cycle counts added by Laurent, after he found that WinUAE cycles were
not matching what's expected. Now that Nicolas updated to much newer
WinUAE version, Hatari relies on WinUAE CPU core itself calculating
the cycles correctly.
This means e.g. that cycles counts can differ a lot when executing
exactly the same instruction, depending on caches etc.
Nicolas, can you confirm this?
<speculation>
I think that because Hatari doesn't take all bus activity / peripheral
delays into account, this means that sometimes cycles can be
unrealistically short.
Douglas, could that have unexpected effects on the DSP code behavior?
<speculation>
OldUAE CPU core still uses the static cycles count approach,
so you could try building and timing DSP for that too. If
that gives correct results, we know that issue is in CPU core
itself, not MFP / DSP side.