[hatari-devel] DSP addressing bug |

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

*To*: hatari-devel@xxxxxxxxxxxxxxxxxxx*Subject*: [hatari-devel] DSP addressing bug*From*: Douglas Little <doug694@xxxxxxxxxxxxxx>*Date*: Thu, 9 Jul 2015 10:27:58 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aVsqIquQ+CGYDT9L5yUvtq0b7IhZ73tNH85kWioegAE=; b=x3m4STS94qQIgX9LCo/lemE1wt67eufPAbPY7Iy47f71kNDcWZ5cSwgKAbk0lpVviP Pse5FYTYxDXK6UXXMLY4c2ZN5pDSAiqBfJsbB2Wn1NbhwZhpGbyI+rMqtJU1mLwOeCLZ sGVs+XU2R4lJBEeC8iTqAhavsdS4SUPppCzwRi9ctQgMiggw+D4SfquvCeAItRVPBabA ctjKpObasiD/IDcQz6dUfLF28ioj8/hq7NDbMQbOvkzq4aPGhwJLa53QnchQ2LCwdrUC ND52R51um43+16RJqyBsOnvybyBXpnaqtJIZFCtIiP1HYgXGOUI9pWMwpaQfadrTA8ny 2U9Q==

Hi,

Since this is a DSP behaviour thing, it might be one for Laurent!

I ran into this case recently and it appears to be a bug (I think). I see something funny when performing an address update in modulo/ringbuffer mode...r1: $4025

I think r1 should actually read $4028 because there is a special case when +Nn increment is used in modulo mode, where N is a multiple of the 2^n modulo upper bound.

I have actually used this before successfully but in that case the Mn register was set to produce a 2^n modulo (i.e. modulo = 4, buffer size = 4). That appeared to work correctly at the time.

In this case the modulo is odd (modulo = 3, buffer size = 4) and the result is weird.

In this case the modulo is odd (modulo = 3, buffer size = 4) and the result is weird.

Another curious thing is that the earlier case which worked used Nn exactly the size of the ringbuffer (using Nn=Mn+1), and produced this (correct) result in both HW and Hatari:

r1: $0100

n1: 4

m1: 3 (4-1, or modulo=4)

> move (r1)+n1

r1: $0104

...however this is what I get with Hatari using Nn=Mn+1 with the odd modulo.

r1: $0100

n1: 4

m1: 2 (3-1, or modulo=3)

> move (r1)+n1

r1: $0101

The latter hasn't been confirmed on real HW so I'm less sure about it being a bug. However the updated address should land in the *next* ringbuffer not the current one (using the special rules for +/-Nn updates) so it also seems suspect.

So it seems like 'bug' is as follows:

The modulo is still being applied when Nn = P x 2^k, when it should be ignored.

TBH I haven't been able to test the bug cases on HW yet because it is temporarily packed away :( but I will as soon as I can. The manual does seem to explain it with a diagram though (attached).

If an offset, Nn, is used in the address calculations, the 16-bit absolute value, INnl, must be less than or equal to M for proper modulo addressing. If Nn>M, the result is data dependent and unpredictable,

**Attachment:
modn.png**

**Follow-Ups**:**Re: [hatari-devel] DSP addressing bug***From:*Laurent Sallafranque

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [hatari-devel] Release Hatari 1.9 this week** - Next by Date:
**Re: [hatari-devel] DSP addressing bug** - Previous by thread:
**Re: [hatari-devel] Release Hatari 1.9 this week** - Next by thread:
**Re: [hatari-devel] DSP addressing bug**

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