Re: [hatari-devel] Better cycle accurate mode for 68030 / Falcon

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


>>> Yes, I know this page, including the 2 scan of notes he took on paper :) That gives some idea and it's better than nothing, but that's not precise enough. When does the burst start ? When DE signal is on or before ? Does it preload during border ? How long does the burst last ? And so on. We lack a description of the signals at the bus level to see how and when videl get access.


I've asked on both dhs and atari forum (maybe someone can help, who knows ;)



Le 08/02/2017 à 22:58, Laurent Sallafranque a écrit :
I love your cpu timings.
At least, movem is giving a closer behaviour to the real hardware now.

> I think that now you could commit your improved videl code. Accuracy is not 100%, but it should be good enough for most cases (and since pinball dreams doesn't work now, it could only improve things anyway)

OK, I'll give it a try.

Regards



Le 08/02/2017 à 18:29, Nicolas Pomarède a écrit :
Le 08/02/2017 à 18:18, laurent.sallafranque@xxxxxxx a écrit :
Hi Nicolas,

Great job, I'll test this as soon as I'm back home.


A few remarks :


In hatari 1.8, I didn't use the 32 bits motorola table, but I recomputed every instruction timing for a 16 bits bus + 4 cycles memory access time.
So, the timings were related to the Falcon bus, not the amiga one ;)

I worked on this with Mikro who exp^lained me how to convert the 32 bits bus to 16 bit bus cycles values. You can find a doc about this on his site : https://mikro.naprvyraz.sk/ in the "docs" section (68030, ST RAM and things around it).


Hi

ok, that explains why your table were not that bad :) (note that motorola timings are not necessarily the amiga ones either, because the amiga also has several bus size / ram speed depending on the kind of memory expansion)



Another point : Rodolphe did many measurement about the cycles used by the Videl : you can find this on his site :

http://rodolphe.czuba.free.fr/CT2/english/technic.htm

The general idea is that the Videl reads the st memory in longs burst mode,
This can take from 4 up to 32% of the band width of the bus.


Yes, I know this page, including the 2 scan of notes he took on paper :) That gives some idea and it's better than nothing, but that's not precise enough. When does the burst start ? When DE signal is on or before ? Does it preload during border ? How long does the burst last ? And so on. We lack a description of the signals at the bus level to see how and when videl get access.

For now, I could "slow down" the CPU bus access by 20% in true color mode for example, this would give an overall correct average, but that's not the cleanest way.


I think that now you could commit your improved videl code. Accuracy is not 100%, but it should be good enough for most cases (and since pinball dreams doesn't work now, it could only improve things anyway)


Nicolas










Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/