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