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