[hatari-devel] Strange CPU cycles
npomarede at corp.free.fr
npomarede at corp.free.fr
Tue Feb 23 14:57:23 CET 2010
On Tue, 23 Feb 2010, Laurent Sallafranque wrote:
>> (I think this is already working like this)
>
> Yes it is. But during these 144 cycles, DSP could be waiting a data from CPU
> that it would have received at cycle 50 (for exxample) on the real Falcon.
theorically yes, but in real life I'm not sure the offset is that big ;
most instructions that write to mem (except movem) will take 8-12 cycles,
so this would just delay the dsp from 8-12 cycles, but this would not slow
down the dsp.
the problem could arise with instructions that write many words/longs at
one time to the dsp if the dsp waits for each words to be finished, but
does it really happen often in real cases ?
the blitter is working in a similar way (regarding bus access) and except
for a few instructions, we managed to get correct timings in all cases
(even if in hatari cpu and blitter run one after the other).
I would suggest to try to collect data/examples on 680xx instructions that
seem to block/slow the dsp to see if we can find a clever way to emulate
this. The less we need to modify current cpu core, the better it will be.
>> Latest winuae has a cycle exact mode for the 68000 / A500 mode, where every
> cycle goes to bus or copper or blitter ...
>
> Is it much slower than the older version with cpu as master clock ?
If you consider a typical 68000, inst will be 12-16 cycles, splitting on
bus access will require to add 6-8 times more tests for each cpu
instruction, so yes, this would slow down quite a lot (to get an idea, one
could try to run winuae in normal and dycle exact a500 mode and see how
much cpu ressources it takes)
>
> They've also included the 68030 MMU whick lacks in hatari.
Yes, but this is such a lot of work, than doing this will certainly
deserve to release hatari as 2.0 :)
Nicolas
More information about the hatari-devel
mailing list