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).
