Re: [hatari-devel] strange DSP behaviour?

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

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