[hatari-devel] some videl emulation news

[Nicolas Pomarède]

Le 06/06/2011 22:59, Laurent Sallafranque a écrit :
> OK for video.
>
> All these questions for DSP < - > 68030 synchro.
>
> As we use the 68030 as main clock, if we don't take into account all the
> waitstates (DMA sound, videl, ...) we can miss a lot of clockedges for
> the DSP speed, no ?
>
> The problem with falcon emu is (I think) that we need to be synchro
> between 68030 (main clock), DSP and crossbar.
> If the 68030 eats some waitstates because of sound DMA or Videl, I think
> we should take them into account for better synchro with the DSP and
> crossbar.
>

Yes, when there're wait state you need to count them in the cpu cycles 
to run the dsp for the correct amount of time.

> Maybe I think wrong and shouldn't worry about these cycles, but they
> seem to be "time consuming" (from Mikro's doc about stRam timings and
> 68030)

Depends on what kind of memory the 68030 is accessing. The "normal" (st 
compatible ram) is using a 16 bits 16 MHz bus, and this will certainly 
slow down the 68030 and make it run slower than it should if you have a 
lot of RAM accesses.

> If I try to take them into account, hatari becomes horribly slow.

But this is very complicated to take into account. Measuring wait state 
requires a very precise emulation of all the clocks, and Hatari does not 
have this, so maybe you're doing something wrong.

Also, I'm not sure that waitstate emulation is the cause of some dsp <-> 
cpu synchro : even on a falcon, the same code will not take the same 
number of cycles, depending on the content of the cpu/data caches.

So even a program on a real Falcon that would expect the dsp<->cpu 
synchronisation to work without any sync control is likely to fail 
(unless you take the cache behaviour into account, which is more 
complicated when coding in asm).
That's why I think that for most programs, even a bad number of cycles 
should not create so many bugs. There may be 2 or 3 general issues to 
fix, but I don't think so many things need to be corrected.

But at one point, I think that what is needed is someone who can code on 
Falcon and provide some very simple programs for dsp/cpu that test one 
particular aspect of the dsp emulation (or the videl part)
Very simple test cases that can be ran on a real Falcon and easily 
compared on Hatari.

Trying to run a complete demo, with several dsp/cpu/videl techniques 
used at the same time, makes it very hard to really isolate one single 
problem and fix it, instead of combining many problems that can 
sometimes influence each others.

I had to do the same thing for shifter : at one point trying to debug 
some particular demos was impossible and lead to a dead end. I wrote 
about 20 simple cases to measure very simple (but very important!) 
aspects, one at a time, by changing only one parameter at a time. And 
nearly "automatically", improving Hatari to pass these simple programs 
make the corresponding demos run without any error.

I don't want to sound pessimistic, but unless someone can help with some 
real Falcon coding experiment in video/dsp fields and provide some very 
simple test programs to show some non working aspects in Hatari, then I 
think it will be very difficult to improve Falcon's emulation.

So, any experiment Falcon coder (not me !) should raise his hand :)

Nicolas