[hatari-devel] some videl emulation news

[Eero Tamminen]

Hi,

On tiistai 07 kesäkuu 2011, Laurent Sallafranque wrote:
> 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".

And e.g. in the Yepyha demo (which has also other issues).

The Stocasto demo freeze is also strange.


> 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)

The graphics in "Agressive II party info" look also different
from the graphics shown on pouet.net.


> 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)

I guess it's a related issue with all the Falcon audio apps (AceMidi,
AceTracker, FalcAmp, FlaySid, FlexTrax, GemPlay).  FlaySid & FlexTrax
actually have _no_ sound according to the compatibility list...


>    - 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 :)


	 - Eero

> 
> 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
> 
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel