RE: [hatari-devel] WinUAE CPU core CPU/FPU/DSP performance according to Centurbo benchmark |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: "hatari-devel@xxxxxxxxxxxxxxxxxxx" <hatari-devel@xxxxxxxxxxxxxxxxxxx>
- Subject: RE: [hatari-devel] WinUAE CPU core CPU/FPU/DSP performance according to Centurbo benchmark
- From: "Konador, Cyprian" <cyprian.konador@xxxxxx>
- Date: Fri, 2 Jan 2015 23:46:01 +0000
- Accept-language: pl-PL, en-US
- Thread-index: AQHQJn01N0MGhNDgYkqmiOAjPPxigZysy+yAgAATdgCAAAqygIAAJZCAgAAJQoCAACuQAIAAA4GAgAAdtBCAABMSgIAABGMg
- Thread-topic: [hatari-devel] WinUAE CPU core CPU/FPU/DSP performance according to Centurbo benchmark
> -----Original Message-----
> From: Nicolas Pomarède
> Sent: 3 January 2015 00:22
> Le 02/01/2015 23:16, Konador, Cyprian a écrit :
> >> From: Douglas Little
> >> Sent: 2 January 2015 21:27
> >>
> >> (It seems there are still other mechanisms stealing some cycles or causing
> bus slots to get missed because the resulting timings are cycle-fractional - but
> I guess those causes are more likely to be constants. The timings always yield
> integers with Hatari)
> >
> > What about memory refresh cycles? I have no good example, but e.g. in
> Amiga memory refresh cycles steal 4 memory slots per scanline:
> >
> http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/nod
> e02D4.gif
> >
>
> IIRC refresh cycles in STF mode are "taken" when the shifter is not
> displaying bitplanes (during the right border). Maybe it's the same on
> falcon ?
>
As far as I know, ST has a bit different memory usage scheme than Falcon. In ST (and also in TT) the CPU and the Shifter memory slots are interleaved, e.g. the CPU (and DMA/Blitter) gets every even and the Shifter (and Sound DMA/memory refresh) every odd memory slot. Therefore there is no any conflict between them. If I'm not wrong in case Falcon, the CPU has access to every memory slot, IF it's not utilized by: the memory refresh/Videl/SDMA/DMA/Blitter.
BR
Cyprian