[hatari-devel] Long mail : new cpu cores + 2 questions.

[Miro Kropáček]

Hi,

Ok, but as the 68030 is the main clock of the emulator, it needs to be
> accurate (sound, DSP, video, ... are based on the CPU cycles).
>
Sure! Nobody says you should drop the 68030 clock! But remember, the bus
clock is in direct relationship with the 68030 CPU, it's not like separate
entities.

Just for a start (before the full file): how many cycles should these
> instructions take on the Falcon ?
>
> NOP (2 or 4 cycles) ?
>
68030 UM: 2(0/0/0) 2(0/1/0)

(total number of cycles) - (number of bus activity cycles) = (number of
internal cycles)

Cache case: 2 - 0*2 = 2
Non-cache case: 2 - 1*2 = 0

Once we have this number (internal cycles), we can re-calculate the bus
activity (4 clock cycles for 1 bus cycle plus split every instruction for
byte+word and long access, since these numbers differ on Falcon 16-bit bus):

Cache case: 2 + 0*4 = 2 cycles (no prefetch, no data, the number of cycles
stays)
Non-cache case: 0 + 1*4 = 4 cycles (instruction prefetch = 1 bus access),



> MOVE.W D0,D1
> MOVE.L D0,D1
>
  2(0/0/0) 2(0/1/0) (MOVE Rn,Dn)
Same as NOP, no bus access for data


> MOVE.W D0,(A0)
> MOVE.L D0,(A0)
>
3(0/0/1) 4(0/1/1)

Falcon numbers for the word variant:
Cache: 1 + 1*4 = 5
Non-cache: 0 + 1*4 + 1*4 = 8

Falcon numbers for the long variant:
Cache: 1 + 2*4 = 9
Non-cache: 0 + 1*4 (instruction prefetch) + 2*4 (long write) = 12



> MOVE.W (A0), D0
> MOVE.L (A0), D0
>
I'm lazy, sorry :) But it's about the same, again and again. We'are "lucky"
the data cache is write-trough, no need to worry about writes, they always
take the same number of cycles.

Another nice thing about timing is you don't need to worry about misaligned
longs, they are always "misaligned", because you read them in two bus
cycles.

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20111031/35087a78/attachment.html>