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