[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Of course I don't have the setup code for the NeXT routine, only the inner
part. So it may be something to do with initial conditions, or what happens
after escaping (calculation from LC).
TBH I have myself seen an odd bug in my own code when doing calculations
from LC remainder. And it doesn't involve mandelbrot - something else.
I have not figured out what that issue is yet - assuming for now its just a
bug in my code, but there's a small chance these things are related? I'll
need to check that bug on real HW soon - just haven't had time.
Doug.
On 22 November 2015 at 22:29, Andreas Grabher <andreas.grabher@xxxxxxxxxxxx=
>
wrote:
> Laurent and Douglas, you are of course right. This should be checked on
> real hardware. I try to find someone to test it for me. But until then,
> given the sense for perfection of all NeXT stuff, i think it is quite
> unlikely they shipped it with that obvious bug. There are also obvious
> issues (black line in the middle), if the default parameters are used.
> I'll report back as soon as is have information from real hardware.
>
> Laurent, i tried to answer your questions below.
>
> Douglas, your optimizations are interesting. I think NeXT would have been
> interested in them, because the main purpose of the Mandelbrot demo was t=
o
> demonstrate the performance advantage of the DSP over the CPU for certain
> tasks ;-)
> I'll have a look if i can isolate the complete DSP application. It seems
> to be embedded into the binary. Maybe i'll just print if from the DSP RAM
> ...
>
>
> Am 22.11.2015 um 12:06 schrieb 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 =3D $00:8... ) ?
>
> I think this is all correct. It gets back to 00:7... later just before th=
e
> jec.
>
>
> 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
>
> y1 is 0x2c28f8, it gets set up at the beginning and does not get changed
> during the calculation.
>
>
> 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
>
> I think that overflow is normal behavior. But i'm not sure about it.
>
>
> 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 ?
>
> The problem seems to that unlike with the "good" pixels, a is too small t=
o
> get to 00:8...
>
> Reg: sr $8050 -> $8040
> p:0099 0af0a5 0000a1 (06 cyc) jec
> p:$00a1
>
>
>
> Laurent
>
>
>
> Le 22/11/2015 10:24, Andreas Grabher a =C3=A9crit :
>
> 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>
> andreas.grabher@xxxxxxxxxxxx>
> *Betreff: **[hatari-devel] DSP Mandelbrot bug*
> *Datum: *22. November 2015 09:53:17 MEZ
> *An: * <hatari-devel@xxxxxxxxxxxxxxxxxxx>hatari-devel@xxxxxxxxxxxxxxxxxxx
> *Antwort an: * <hatari-devel@xxxxxxxxxxxxxxxxxxx>
> 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 append=
ed
> 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 bett=
er
> 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 remaini=
ng
> count, the lower is the output value of the function. The loop exits usin=
g
> 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 b=
e
> in dsp_mul56.
>
> Any help is greatly appreciated!
>
> Andreas
>
>
>
>
>
>
>
>
>
>
>
--001a1144315e091668052531aad3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div>Hi,<br><br></div>I was able to ru=
n a test of the NeXT mandelbrot routine by tidying up the debug log and ext=
racting the inner loop instructions (which my last post was based on), befo=
re trying to optimize it.<br><br></div>From what I could see, there were ac=
tually no bad pixels in the output. This test was run inside Hatari (i.e. n=
ot on real HW - didn't bother trying that since I didn't see a prob=
lem).<br><br></div>Of course I don't have the setup code for the NeXT r=
outine, only the inner part. So it may be something to do with initial cond=
itions, or what happens after escaping (calculation from LC).<br><br></div>=
TBH I have myself seen an odd bug in my own code when doing calculations fr=
om LC remainder. And it doesn't involve mandelbrot - something else.<br=
><br>I have not figured out what that issue is yet - assuming for now its j=
ust a bug in my code, but there's a small chance these things are relat=
ed? I'll need to check that bug on real HW soon - just haven't had =
time.<br><br></div>Doug.<br><br><div><div><br><div><div><br><div><br></div>=
</div></div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On 22 November 2015 at 22:29, Andreas Grabher <span dir=3D"ltr=
"><<a href=3D"mailto:andreas.grabher@xxxxxxxxxxxx"; target=3D"_blank">and=
reas.grabher@xxxxxxxxxxxx</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div style=3D"word-wrap:break-word">Laurent and Douglas, you are of =
course right. This should be checked on real hardware. I try to find someon=
e to test it for me. But until then, given the sense for perfection of all =
NeXT stuff, i think it is quite unlikely they shipped it with that obvious =
bug. There are also obvious issues (black line in the middle), if the defau=
lt parameters are used.<div>I'll report back as soon as is have informa=
tion from real hardware.<br><div><br></div><div>Laurent, i tried to answer =
your questions below.</div><div><br></div><div>Douglas, your optimizations =
are interesting. I think NeXT would have been interested in them, because t=
he main purpose of the Mandelbrot demo was to demonstrate the performance a=
dvantage of the DSP over the CPU for certain tasks =C2=A0;-)</div><div>I=
9;ll have a look if i can isolate the complete DSP application. It seems to=
be embedded into the binary. Maybe i'll just print if from the DSP RAM=
...</div><div><br></div><div><br><div><div><div>Am 22.11.2015 um 12:06 sch=
rieb Laurent Sallafranque <<a href=3D"mailto:laurent.sallafranque@free.f=
r" target=3D"_blank">laurent.sallafranque@xxxxxxx</a>>:</div><br><blockq=
uote type=3D"cite">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Hi Andreas,<br>
<br>
First, are you sure the resulting bad pixels don't appear on the
real computer too ?<br>
(just to be sure).<br>
<br>
<br>
<br>
When I have a closer look at the trace, I can read :<br>
<br>
<br>
; Previous loop<br>
p:0099=C2=A0 0af0a5 0000a1=C2=A0 (06 cyc)=C2=A0 jec p:$00a1=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 <br>
<br>
<br>
; New loop that seems to bug=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 <br>
<br>
p:00a1=C2=A0 2000d8=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 mpy
+y0,x0,b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: b=C2=A0=C2=A0 $00:4a0b9a:44a2c4 -> $00:235=
5a0:579062<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8040 -> $8050<br>
p:00a2=C2=A0 20003a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 asl
b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: b=C2=A0=C2=A0 $00:2355a0:579062 -> $00:46a=
b40:af20c4<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8050 -> $8040<br>
<br>
<br>
; Is the next one correct ? (we have b =3D $00:8...=C2=A0=C2=A0 ) ?<b=
r></div></div></blockquote>I think this is all correct. It gets back to 00:=
7... later just before the jec.<br><blockquote type=3D"cite"><div bgcolor=
=3D"#FFFFFF" text=3D"#000000"><div>
<br>
p:00a3=C2=A0 20003a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 asl
b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: b=C2=A0=C2=A0 $00:46ab40:af20c4 -> $00:8d5=
681:5e4188<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8040 -> $8060<br>
<br>
<br>
; What worth Y1 value just below ? (I haven't found it in the
trace)<br>
; The problem may be here<br></div></div></blockquote>y1 is 0x2c28f8,=
it gets set up at the beginning and does not get changed during the calcul=
ation.<br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#00000=
0"><div>
<br>
p:00a4=C2=A0 200078=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 add
y1,b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: b=C2=A0=C2=A0 $00:8d5681:5e4188 -> $00:ae4=
c44:5e4188<br>
<br>
<br>
; Just below, we've got the "overflow" (7fffff) (into y=
0)<br>
; The problem seem to be that the program copy $00:ae4c44:5e4188
into y0 and set it to $7fffff<br></div></div></blockquote>I think tha=
t overflow is normal behavior. But i'm not sure about it.<br><blockquot=
e type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><div>
<br>
p:00a5=C2=A0 21e696=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 mac -y0,y0,a
b,y0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: y0=C2=A0 $4e71df -> $7fffff<br>
=C2=A0=C2=A0=C2=A0 Reg: a=C2=A0=C2=A0 $00:19f86d:2f6242 -> $ff:e9e=
540:1a21c0<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8060 -> $8058<br>
<br>
<br>
p:00a6=C2=A0 200032=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 asl
a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: a=C2=A0=C2=A0 $ff:e9e540:1a21c0 -> $ff:d3c=
a80:344380<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8058 -> $8059<br>
p:00a7=C2=A0 200060=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 add
x1,a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: a=C2=A0=C2=A0 $ff:d3ca80:344380 -> $ff:fff=
376:344380<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8059 -> $8058<br>
p:0096=C2=A0 21c498=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 mpy +y0,y0,b
a,x0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: x0=C2=A0 $39a7ef -> $fff376<br>
=C2=A0=C2=A0=C2=A0 Reg: b=C2=A0=C2=A0 $00:ae4c44:5e4188 -> $00:7ff=
ffe:000002<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8058 -> $8040<br>
p:0097=C2=A0 200080=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 mpy
+x0,x0,a=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: a=C2=A0=C2=A0 $ff:fff376:344380 -> $00:000=
001:3a74c8<br>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8040 -> $8050<br>
<br>
p:0098=C2=A0 200018=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (=
02 cyc)=C2=A0 add
a,b=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <br>
=C2=A0=C2=A0=C2=A0 Reg: b=C2=A0=C2=A0 $00:7ffffe:000002 -> $00:7ff=
fff:3a74ca=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <-- Here KO ?<br></div></div=
></blockquote>The problem seems to that unlike with the "good" pi=
xels, a is too small to get to 00:8...<br><blockquote type=3D"cite"><div bg=
color=3D"#FFFFFF" text=3D"#000000"><div>
=C2=A0=C2=A0=C2=A0 Reg: sr=C2=A0 $8050 -> $8040<br>
p:0099=C2=A0 0af0a5 0000a1=C2=A0 (06 cyc)=C2=A0 jec
p:$00a1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 <br>
<br>
<br>
<br>
Laurent<br>
<br>
<br>
<br>
Le 22/11/2015 10:24, Andreas Grabher a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
=20
Update:
<div><br>
</div>
<div>Looking at the values of b at time of final jec it seems that
it might also be some kind of rounding issue:</div>
<div><br>
</div>
<div>
<div>00:800d9f:248aca <--- 3 pixels before</div>
<div>00:80064e:53e34a</div>
<div>00:8001b2:34bbf4</div>
<div>00:7fffff:3a74ca <--- bad pixel</div>
<div>00:80016c:07e922</div>
<div>00:800631:562b04</div>
<div>00:800e89:ff27ca <--- 3 pixels after</div>
<div><br>
<div>Anfang der weitergeleiteten Nachricht:</div>
<br>
<blockquote type=3D"cite">
<div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px=
;margin-left:0px"><span style=3D"font-family:Helvetica"><b>Von: </b></span>=
<span style=3D"font-family:'Helvetica'">Andreas Grabher <<a href=
=3D"mailto:andreas.grabher@xxxxxxxxxxxx"; target=3D"_blank"></a><a href=3D"m=
ailto:andreas.grabher@xxxxxxxxxxxx" target=3D"_blank">andreas.grabher@cable=
..vol.at</a>><br>
</span></div>
<div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px=
;margin-left:0px"><span style=3D"font-family:Helvetica"><b>Betreff: </b></s=
pan><span style=3D"font-family:'Helvetica'"><b>[hatari-devel] DSP
Mandelbrot bug</b><br>
</span></div>
<div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px=
;margin-left:0px"><span style=3D"font-family:Helvetica"><b>Datum: </b></spa=
n><span style=3D"font-family:'Helvetica'">22. November 2015
09:53:17 MEZ<br>
</span></div>
<div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px=
;margin-left:0px"><span style=3D"font-family:Helvetica"><b>An: </b></span><=
span style=3D"font-family:'Helvetica'"><a href=3D"mailto:hatari-dev=
el@xxxxxxxxxxxxxxxxxxx" target=3D"_blank"></a><a href=3D"mailto:hatari-deve=
l@xxxxxxxxxxxxxxxxxxx" target=3D"_blank">hatari-devel@xxxxxxxxxxxxxxxxxxx</=
a><br>
</span></div>
<div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px=
;margin-left:0px"><span style=3D"font-family:Helvetica"><b>Antwort an: </b>=
</span><span style=3D"font-family:'Helvetica'"><a href=3D"mailto:ha=
tari-devel@xxxxxxxxxxxxxxxxxxx" target=3D"_blank"></a><a href=3D"mailto:hat=
ari-devel@xxxxxxxxxxxxxxxxxxx" target=3D"_blank">hatari-devel@lists.tuxfami=
ly.org</a><br>
</span></div>
<br>
<div>Hello Hatari Community,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Short overview on the calculation:<br>
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).<br>
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 ar=
e 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.<br>
<br>
Can someone with more DSP experience see the bug? It might
or might not be in dsp_mul56.<br>
<br>
Any help is greatly appreciated!<br>
<br>
Andreas<br>
<br>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
=20
<br>
<fieldset></fieldset>
<br>
=20
<br>
<fieldset></fieldset>
<br>
=20
<div><br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div=
>
--001a1144315e091668052531aad3--