Re: Fwd: [hatari-devel] DSP Mandelbrot bug

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

Hi Andreas,

First, are you sure the resulting bad pixels don't appear on the real computer too ?
(just to be sure).



When I have a closer look at the trace, I can read :


; Previous loop
p:0099  0af0a5 0000a1  (06 cyc)  jec p:$00a1                 


; New loop that seems to bug                     

p:00a1  2000d8         (02 cyc)  mpy +y0,x0,b                                     
    Reg: b   $00:4a0b9a:44a2c4 -> $00:2355a0:579062
    Reg: sr  $8040 -> $8050
p:00a2  20003a         (02 cyc)  asl b                                            
    Reg: b   $00:2355a0:579062 -> $00:46ab40:af20c4
    Reg: sr  $8050 -> $8040


; Is the next one correct ? (we have b = $00:8...   ) ?

p:00a3  20003a         (02 cyc)  asl b                                            
    Reg: b   $00:46ab40:af20c4 -> $00:8d5681:5e4188
    Reg: sr  $8040 -> $8060


; What worth Y1 value just below ? (I haven't found it in the trace)
; The problem may be here

p:00a4  200078         (02 cyc)  add y1,b                                         
    Reg: b   $00:8d5681:5e4188 -> $00:ae4c44:5e4188


; Just below, we've got the "overflow" (7fffff) (into y0)
; The problem seem to be that the program copy $00:ae4c44:5e4188 into y0 and set it to $7fffff

p:00a5  21e696         (02 cyc)  mac -y0,y0,a b,y0                                
    Reg: y0  $4e71df -> $7fffff
    Reg: a   $00:19f86d:2f6242 -> $ff:e9e540:1a21c0
    Reg: sr  $8060 -> $8058


p:00a6  200032         (02 cyc)  asl a                                            
    Reg: a   $ff:e9e540:1a21c0 -> $ff:d3ca80:344380
    Reg: sr  $8058 -> $8059
p:00a7  200060         (02 cyc)  add x1,a                                         
    Reg: a   $ff:d3ca80:344380 -> $ff:fff376:344380
    Reg: sr  $8059 -> $8058
p:0096  21c498         (02 cyc)  mpy +y0,y0,b a,x0                                
    Reg: x0  $39a7ef -> $fff376
    Reg: b   $00:ae4c44:5e4188 -> $00:7ffffe:000002
    Reg: sr  $8058 -> $8040
p:0097  200080         (02 cyc)  mpy +x0,x0,a                                     
    Reg: a   $ff:fff376:344380 -> $00:000001:3a74c8
    Reg: sr  $8040 -> $8050

p:0098  200018         (02 cyc)  add a,b                                          
    Reg: b   $00:7ffffe:000002 -> $00:7fffff:3a74ca                    <-- Here KO ?
    Reg: sr  $8050 -> $8040
p:0099  0af0a5 0000a1  (06 cyc)  jec p:$00a1                                    



Laurent



Le 22/11/2015 10:24, Andreas Grabher a écrit :

Update:

Looking at the values of b at time of final jec it seems that it might also be some kind of rounding issue:

00:800d9f:248aca <--- 3 pixels before

00:80064e:53e34a

00:8001b2:34bbf4

00:7fffff:3a74ca <--- bad pixel

00:80016c:07e922

00:800631:562b04

00:800e89:ff27ca <--- 3 pixels after

Anfang der weitergeleiteten Nachricht:

Von: Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>

Betreff: [hatari-devel] DSP Mandelbrot bug

Datum: 22. November 2015 09:53:17 MEZ

An: hatari-devel@xxxxxxxxxxxxxxxxxxx

Antwort an: hatari-devel@xxxxxxxxxxxxxxxxxxx

Hello Hatari Community,

i am experiencing a hard to find DSP bug here with Previous. Luckily it can be made "visible" using NeXTstep's included Mandelbrot demo. It might also be responsible for some distorted audio in other applications.

I appended a screenshot of the mandelbrot application where the effect of the bug is clearly visible. I pointed to one failing pixel. I also appended some debugging output containing the calculation of the failing pixel and one pixel before and one after the failing one. The last file i appended contains an overview about the variables during calculation to get a better overview.

Short overview on the calculation:
Every pixel is calculated separately. The visible pixel color is derived from the remaining loop count of some calculation. The higher the remaining count, the lower is the output value of the function. The loop exits using a jec instruction (check extension bit, exit if false).
For the "good" pixels it exits after the second run, because the upper 9 bits of b are no longer all 0. For the "bad" pixel it does not exit, because these bits are still all 0. The most suspect part of the calculation seems to be mpy +x0,x0,a at p:0097. The value of a after the third call of that instruction seems to not fit into the pattern.

Can someone with more DSP experience see the bug? It might or might not be in dsp_mul56.

Any help is greatly appreciated!

Andreas