Re: [hatari-devel] Hatari data cache tests

Hi,

Yes agreed its a bit chicken/egg but we can get good visibility of a decent number of ops independent of memory, and with some differentiation (video modes) perhaps figure out a bit more. But it will be tricky to get everything...

Ok I'll post some real logs later from my Falcon, in the different modes.

On 18 June 2015 at 22:03, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

Le 18/06/2015 22:46, Douglas Little a écrit :

I should add - I think its better to use idealized timings to check the
CPU ops, cache, and head/tail timings are accurate.

Later it would be more interesting to use real F030 video modes to get
bus performance more accurate... but even at that it would be some kind
of approximation I suppose.

For now, it's a kind of "chicken and egg" problem : we need correct cpu emulation to get correct video timings (because in Hatari it's the CPU clock that drives all other components), but we also need correct video emulation to know how the videl's bandwidth affects the cpu by slowing down RAM accesses.

So yes, we need to start with the simplest possible case, where we know videl doesn't affect the cpu. When we get correct cycles in all cases, then my idea would be to have an approximation of how many percents each video mode takes from the CPU (taking into account the border size and the resolution). For example, slowing down cpu memory accesses every 10 or 20 cycles if video uses 256 colors.

This is something that is documented for Amiga, where slowdown can be computed depending on DMA/video accesses, but for the Falcon, I'm afraid this was not fully documented, so this will require a lot of tests.

By the way, could you post your results when running your program on a real HW ?

Nicolas