[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