Re: [hatari-devel] DSP addressing bug

Woo, that was quick. Thanks!

If the patch has made it into the repo, I can just collect tomorrow's nightly build and see if that works for me. Sounds like it probably will. Otherwise I'll try a local build tomorrow.

Best,

Doug.

On 22 October 2015 at 21:51, Laurent Sallafranque <laurent.sallafranque@xxxxxxx> wrote:

Hi all,

I've just send a fix for this special case.
I've tested it with a few case tests and it seems to behave as expected now.

If some of you could test a few Falcon demos/games/apps to be sure there's no regression with the previous hatari version, I'd be glad.

Best regards

Laurent

Le 09/07/2015 11:27, Douglas Little a écrit :

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: $4020

n1: 8

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

> move (r1)+n1

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.

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, except for the special case where Nn = P x 2k, a multiple of the block size where P is a positive integer. For this special case, when using the (Rn) + Nn addressing mode, the pointer, Rn, will jump linearly to the same relative address in a new buffer, which is P blocks forward in memory (see Figure 5-12).