Re: [hatari-devel] DSP for Previous |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hello Hatari Community!
Is there any recent work on the DSP side? I see my interrupt patches are not yet integrated. After using the new method in Previous for some time, i think it should be safe.
Anyway i have a least two known problems (maybe it is only one): One gives a black line in the middle of a mandelbrot fractal, the other one leads to heavy sound distortion when playing a special piece of DSP audio.
I posted a screenshot of the fractal and some debugger output some time ago.
Any help is welcome. If you have questions about the interrupt code, i'll be glad to answer them.
Regards,
Andreas
Am 05.07.2015 um 12:06 schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:
> Le 05/07/2015 10:29, Eero Tamminen a écrit :
>> Hi,
>>
>> On lauantai 04 heinäkuu 2015, Nicolas Pomarède wrote:
>>> Le 03/07/2015 23:33, Thomas Huth a écrit :
>>>> The "volatiles" are likely a remainder from the times when the DSP run
>>>> in its own thread. But since this support has been removed quite a
>>>> while ago already, I think we could also remove the "volatiles" in
>>>> the DSP code of Hatari.
>>> I didn't know there was a thread version of the dsp code, but volatile
>>> is indeed useful only when content can be changed "externally" by
>>> another process/thread or hardware.
>> Hatari DSP emulation code originated from Aranym, which threads
>> it's DSP code so that it can run parallel to CPU emulation.
>> However, it was so inaccurate [1] that to my knowledge there
>> wasn't any Falcon programs that worked with it.
>>
>>
>> - Eero
>>
>> [1] I'm not completely sure whether issue was just DSP emulation
>> accuracy in isolation, or also synchronizing it to CPU, Aranym
>> CPU emulation not being cycle accurate and emulating mainly 040
>> instead of 030 (I think main reason for emulating 040 is MMU,
>> Aranym runs OSes using MMU and 040 one is easier to emulate)...
>>
>>
> The main reason was difficulty to synchronize the CPU and the DSP.
> But you're right, by the time, the DSP was totally inacurate and very buggy.
>
> I think now that the DSP is really accurate, we could probably thread it again (but as it works like this, it's perharps not a good idea)
>
> I'll integrate Andreas interruptions code by july or september.
>
> Laurent
>
>