Re: [hatari-devel] DSP for Previous

[Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>]

I just found where these interrupts are released. They are auto-released (like in the old interrupt routine).

Am 14.06.2015 um 13:01 schrieb Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>:

Thank you for the hint. I'll have a look.

In the meantime i coded a new interrupt routine. It is not yet finished. I need to find out under which conditions these interrupts are released: stack error, swi, illegal, nmi. Any help on this is welcome!

I appended my files to this message. Please have a look and tell me what you think. There are some other minor fixes and the memory map for NeXT inside. You can ignore them.

<dsp.zip>

Am 13.06.2015 um 19:44 schrieb Douglas Little <doug694@xxxxxxxxxxxxxx>:

Hi,

Sorry to top-post but this kind of arithmetic 'bug' is often caused by changes in rounding behaviour or condition flags. The DSP has some configurable rounding modes (affecting several instructions) which have shown bugs in the past and were fixed. It's possible something remains here which isn't 100% yet.

...after a quick look I'd say it could be related to the JEC (extension clear) condition - I don't remember ever using that case on Falcon and I'm not sure if anyone else has either?

D

On 12 June 2015 at 19:02, Andreas Grabher <andreas.grabher@xxxxxxxxxxxx> wrote:

Am 11.06.2015 um 23:21 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 11/06/2015 23:08, Andreas Grabher a écrit :
>> You're welcome! I found some more problems. But now it seems that the
>> DSP works for me!
>>
>> Most problems i found were related to the interrupt system. It does not
>> reflect real behavior. I think i found most issues, but with this method
>> of doing interrupts we will run into further problems sooner or later. I
>> think it needs to be rewritten. My current patch is just a workaround.
>>
>> Now it works like this:
>> The device sends the interrupt to the DSP like some kind of message. If
>> it is not masked, it is then added to a list. The DSP reads the
>> interrupt from the list, removes it and executes the interrupt service
>> routine. If a masked interrupt is unmasked, the interrupt message needs
>> to be re-sent. If an interrupt is on the list while it gets masked, it
>> needs to be removed from the list. If the service routine does not make
>> the device release the interrupt on first try, it needs to be sent
>> again, if it isn't masked.
>>
>> How it should work:
>> The device asserts the interrupt line. The DSP samples the line and sees
>> the interrupt, if it is not masked. It executes the service routine,
>> which then makes the device release the interrupt line. If a masked
>> interrupt is unmasked, the DSP will start seeing it. If a pending
>> interrupt is masked, the DSP will no longer see it. If the service
>> routine does not make the device release the interrupt, the DSP will
>> keep on seeing it, unless it is masked.
>>
>
>
> Hi
>
> thanks for your patch ; regarding changing the interrupt behaviour, the current one might not be complete, but it seems it doesn't cause failure so far (because demos/programs don't rely on it), so I think we should wait after 1.9 is released before doing big changes in Hatari.
>
> But we certainly need to handle it by having a pending and a mask registers (as for the 680xx), not temporarily as a list ; better go for the good way to handle it, instead of having an intermediate one with lists (and handling mask/pending is in fact much simpler than handling lists of events, resending events, ...)
>
> As for the rest, I think Laurent knows the DSP better than I do :)
>
> Nicolas
>

I see! I also would not change it, if it worked for me  ;-)

But in case you want to apply the changes anyway, i appended another little patch. Again this needs to be added manually, as our versions are drifting away. It might be easier to just wait until i'm done and then merge.

In the meantime i tested some things and it seems to work quite well. I love to finally hear sound playing! But while testing i may have found another bug. This time it may be in the DSP logic itself.
If you look at the appended screenshot of a Mandelbrot application you may notice a black line in the middle (vertically) of the DSP (right) window. I can't test on real hardware, but i don't think it should be there.

I tried to get some useful debugging output and think i have copied 2 full loops of what it does. The output is in the appended Mandelbrot debug text.
Maybe someone used to the DSP can see an instruction in the loop that may be responsible for this. Then i think it will be easy to fix.