[hatari-devel] some videl emulation news

[Laurent Sallafranque]

At the same time, I would say that Falcon emulation with the new core is 
much better.
I would say that more than 80% of the programs I use for tests are 
running well or nearly well (some sound or video glitshes).

For DSP, I think there are still 2 bugs I haven't found yet :
   - the strange stack overflow in "build in obsolecsence demo". It 
appears in the 50 first DSP instructions. It's easy to reproduce, but I 
don't understand why it works on a real falcon
   - a computing bug ? (I can see it in a screen from Motion demo)


For me, nearly all the other bugs are related to timings :
   - I've already seen working some demos or games by "bad hacking" 
hatari (eg k.prg discuss we had a few month ago)
   - I've already played to llamazap with hatari
   - I've already seen rot3dbmp.prg (I had to "bad hack again" the 68030 
<-> DSP synchro)
   - I've already heard clear sound with DMA play sound (I think it's a 
regression from new CPU)
   - if I "bad hack" again with some other values the 68030 <-> DSP 
synchro, _ demo is full working
   - if I play with -32Mhz, some more demos runs
   - ...

In 99,5% of time, DSP is correctly emulated now (I think it's the most 
robust chip of hatari's falcon emulation)

There a very few programs I have never seen running under hatari.

The progress between hatari 1.0 and hatari 1.5 version for falcon 
emulation is huge (this is of course my point of view).

I'll continue the effort as much as I can.
It would be nice to be helped by some other atarist :)


Regards

Laurent




Le 06/06/2011 23:23, Nicolas Pomarède a écrit :
> 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
>