Re: [hatari-devel] strange DSP behaviour?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi Laurent,

The fix appears to work, thanks!
D.


A: A2: 00  A1: 00c110  A0: 01e497
B: B2: 00  B1: 0000e0  B0: 000000
X: X1: 000800  X0: 008000
Y: Y1: 00fcb6  Y0: 00c110
R0: ffeb   N0: 0000   M0: ffff
R1: 0000   N1: 785f   M1: 0002
R2: 0002   N2: 0fc2   M2: ffff
R3: 004e   N3: 0038   M3: ffff
R4: 0000   N4: 012d   M4: ffff
R5: 3da9   N5: 00dc   M5: ffff
R6: 1440   N6: ffff   M6: ffff
R7: 2907   N7: 0005   M7: ffff
LA: 008f   LC: 0014   PC: 008b
SR: 8050  OMR: 02
SP: 05    SSH: 0086  SSL: 8050

> ds
p:008b  4dc7eb         (02 cyc)  macr +x1,y0,b y:(r7)-n7,x1

> dr
A: A2: 00  A1: 00c110  A0: 01e497
B: B2: 00  B1: 0000ec  B0: 000000
X: X1: 000007  X0: 008000
Y: Y1: 00fcb6  Y0: 00c110
R0: ffeb   N0: 0000   M0: ffff
R1: 0000   N1: 785f   M1: 0002
R2: 0002   N2: 0fc2   M2: ffff
R3: 004e   N3: 0038   M3: ffff
R4: 0000   N4: 012d   M4: ffff
R5: 3da9   N5: 00dc   M5: ffff
R6: 1440   N6: ffff   M6: ffff
R7: 2902   N7: 0005   M7: ffff
LA: 008f   LC: 0014   PC: 008c
SR: 8050  OMR: 02
SP: 05    SSH: 0086  SSL: 8050




On 15 July 2014 18:21, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:
Hi, yes - thanks. I'll let you know when I've traced it in my program.

D


On 15 July 2014 18:15, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:
Hi Doug,

I've posted a fix for the bug.
Can you test it ?

Regards

Laurent


Le 15/07/2014 09:10, Douglas Little a écrit :
Hi Laurent,

That's great! :-) At first I thought my eyes were not working properly, and then thought I hadn't read the manual properly... and then I was sure something was wrong. hehe.

This will be a nice fix to have because it is important in my new texture & lighting routine.

D



On 15 July 2014 08:00, <laurent.sallafranque@xxxxxxx> wrote:
Hi Doug,

Well spoted !
I've found the problem.

The dsp_macr_p_x1_y0_b is bugged.

these 32 macr instructions all work the same way :

macr _ p(lus) or m(inus) _ reg1 _ reg2 _ dest_reg (A or B)


There are 32 of them and only one was buggued (the case you gave me in example) ;)

If you have a look at the function : dsp_macr_p_x1_y0_b in dsp_src.c and you compare it with the previous or the next macr function, you'll see that the order of the instructions into the function is not the same (the rounding is done too early).

I'll fix it tonight.

Regards

PS: I've verified the other macr, they seem OK.
PS2: I'll also verify the mpyr tonight.

Laurent



----- Mail original -----
De: "Douglas Little" <doug694@xxxxxxxxxxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Lundi 14 Juillet 2014 18:46:44
Objet: [hatari-devel] strange DSP behaviour?




I noticed this strange effect on Sunday, probably one for LaurentS :-)

MACR seems to be selectively rounding the accumulator - or not rounding - depending on the weather. Or possibly it is never rounding.

The only external influence on MACR (and other rounding ops) are the global scaling bits and these just affect the constant used to perform rounding. The zeroing of the lower 24bits of the destination accumulator is unconditional - it should always occur. But it didn't happen in the example traced below?





> dr
A: A2: 00 A1: 0055fc A0: 00ffa6
B: B2: 00 B1: 000fc0 B0: 000000
X: X1: 002000 X0: 080000
Y: Y1: 000000 Y0: 0055fc
R0: ffeb N0: 0000 M0: ffff
R1: 0000 N1: 29a2 M1: 0002
R2: 0001 N2: 0fc6 M2: ffff
R3: 004e N3: 0001 M3: ffff
R4: 0000 N4: 006c M4: ffff
R5: 29a9 N5: eafe M5: ffff
R6: 151a N6: ffff M6: ffff
R7: 49a2 N7: 2400 M7: ffff
LA: 0093 LC: 0001 PC: 008f
SR: 8050 OMR: 02
SP: 05 SSH: 008a SSL: 8040

> ds
p:008f 4dc7eb (02 cyc) macr +x1,y0,b y:(r7)-n7,x1

> dr
A: A2: 00 A1: 0055fc A0: 00ffa6
B: B2: 00 B1: 000fd5 B0: 7f0000
X: X1: 225100 X0: 080000
Y: Y1: 000000 Y0: 0055fc
R0: ffeb N0: 0000 M0: ffff
R1: 0000 N1: 29a2 M1: 0002
R2: 0001 N2: 0fc6 M2: ffff
R3: 004e N3: 0001 M3: ffff
R4: 0000 N4: 006c M4: ffff
R5: 29a9 N5: eafe M5: ffff
R6: 151a N6: ffff M6: ffff
R7: 25a2 N7: 2400 M7: ffff
LA: 0093 LC: 0001 PC: 0090
SR: 8050 OMR: 02
SP: 05 SSH: 008a SSL: 8040



I haven't had time to investigate this more closely but this was a direct c&p from the Hatari debugger and seems conclusive - something wrong?




See the DSP user manual, page A-114 for a description of MACR behaviour and the zeroing of LSW after rounding.

http://bitsavers.informatik.uni-stuttgart.de/pdf/motorola/56000/1990_DSP56000_DSP56001_Users_Manual.pdf










Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/