MVN and MVP block copy: Difference between revisions
Rainwarrior (talk | contribs) (explain MVN/MVP) |
Rainwarrior (talk | contribs) m (note DB overwrite) |
||
Line 20: | Line 20: | ||
We can consider this a branching instruction that does the following each time it executes: | We can consider this a branching instruction that does the following each time it executes: | ||
# Copy byte at source bank X to destination bank Y. | # Copy byte at source bank X to destination bank Y. (DB is overwritten.) | ||
# Increment X and Y (MVN), or decrement (MVP). | # Increment X and Y (MVN), or decrement (MVP). | ||
# Decrement A. | # Decrement A. |
Revision as of 05:20, 17 May 2022
The 65C816 has two instructions, MVN and MVP intended for efficient block copy from one area of CPU memory to another.
Their mnemonics stand for "Move Memory Negative" and "Move Memory Positive". The negative version copies bytes in increasing order, and the positive version uses decreasing order.
Inputs to the instructions:
- Register A is the 16-bit count of bytes to be copied, minus 1.
- Register X is the 16-bit source data address.
- Register Y is the 16-bit destination data address.
- Two 1-byte immediate operands specify the bank address.
Result:
- The specified data will have been copied.
- Register A will be $FFFF after counting down.
- Register X/Y will have incremented (MVN) or decremented (MVP) by the count of bytes.
- Register DB is set to the destination bank operand.
We can consider this a branching instruction that does the following each time it executes:
- Copy byte at source bank X to destination bank Y. (DB is overwritten.)
- Increment X and Y (MVN), or decrement (MVP).
- Decrement A.
- If A is not $FFFF, branch to self.
Each byte takes 7 CPU cycles of the 65C816, though the SNES specific timing is a little more complicated.
MVN example
REP #$30 ; use 16-bit registers .a16 .i16 LDX .loword(source) LDY .loword(dest) LDA #(size-1) MVN #^source, #^dest ; DB = ^dest ; A = $FFFF ; X = source+size ; Y = dest+size
MVP example
REP #$30 .a16 .i16 LDX .loword(source+size-1) ; MVP starts with the last byte to copy LDY .loword(dest+size-1) LDA #(size-1) MVP #^source, #^dest ; DB = ^dest ; A = $FFFF ; X = source-1 ; Y = dest-1
Overlap
For copies between non-overlapping regions, choice of MVN or MVP doesn't normally matter, but when they do, the following operations will ensure the source data is copied correctly to the destination:
- MVP if dest > source
- MVN if dest < source
Thus, MVP is for moving data "forward" in memory, and MVN is for moving it "backward".
In the forward case, since MVP moves the last byte first, it ensures that no part of source will be overwritten by the destination copy before it is read.
Pattern Fill
Overlap and direction of copy can also be exploited to fill memory with repeating patterns.
This is usually most useful with MVN, which can conveniently repeat bytes from the beginning of an array across the rest of it:
LDX #.loword(source) LDY #.loword(source+4) ; copy each byte 4 bytes forward LDA #(size-5) ; array size -4 bytes being repeated, and -1 for MVN count MVN #^source,#^(source+4) ; the first 4 bytes of source are now copied across the entire array
ca65 syntax
MVN and MVP are unique instructions because they have two "immediate" operands. Because they normally will use the high byte of 3-byte address, ca65 provided two alternatives:
MVP #^source, #^dest ; use # to specify the byte directly MVP source, dest ; use a far address directly to have it automatically take the high byte
Using # allows you to directly state the byte of operand which should be used to designate the byte.
Without #, ca65 will automatically treat the operand as a 24-bit far address, and take its 3rd byte. This looks less verbose, but because the lower 2 bytes are automatically discarded without warning, accidental usage has a tendency to select bank $00 by mistake:
MVN $35,$36 ; copies from bank $00 -> $00, and not $35 -> $36. MVN ^source,^dests ; copies from $00 -> $00 rather than the banks of source/dest.
See Also
References
- 65C816 Opcodes - article at 6502.org