Lessons I've, just, learned the hard way. I thought I'd share
them.
Moving or copying blocks of memory can be tricky with the
6502. I've made all the mistakes so I thought, I'd put them
here to, maybe, save others the pain.

A simple move, down in memory, might look like:

All looks OK but what say you wanted to move $100.
if you do it the same, you can't set Y=$100 for the
size.
An alturnative might look like:

Of course, anything over $100 would need to be done
in multiple chunks of $100 or less.
There is a potential problem with MOV2. If the from
data overlaps the first byte of the to location, the
first byte of the to location is over written.
If one is making a general case of a move down, it is
safer to use blocks smaller than $100 in size. The
math is simplest for $80 in size and use MOV1 and
avoid MOV1.
An alternative that, take more, code might be:

It still won't do a size of $100.

Just now learning my 6502 coding.
Dwight

Dwight, to make your code appear as intended, monospaced and without the spaces removed, put [code] and [/code] around the source-code sections.

Bruce Clark has a short article on this site about memory-moving, at http://6502.org/source/general/memory_move.html . One thing I don't see there is self-modifying code which could make it a little faster and more memory-efficient. This is where the variables are the operands of instructions themselves. If your routines are in RAM, you might want to experiment with that.

Note that the 65816 has the memory-moving instructions MVN and MVP. You set up X, Y, and C (16-bit A) to hold the source, destination, and count, then do MVN or MVP with the operands being the source and destination bank numbers you want. Up to 64K can be moved at once, at seven cycles per byte, and it's interruptible.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I find I seldom have to move 256 bytes or more, since most moves are strings or other short pieces, so in my '02 Forth, I added QCMOVE and QCMOVE> (adding the "quick" to the standard "character move" and "character move up" words). Here's an approximate translation of them. FROM and TO and COUNT are ZP variables.

Code:

QCMOVE_UP:
        LDY  COUNT
        BEGIN
           DEY
           CPY  #$FF
        WHILE_NEQ
           LDA  (FROM),Y
           STA  (TO),Y
        REPEAT
        RTS
 ;--------------

QCMOVE: LDY  #0
        BEGIN
           CPY  COUNT
        WHILE_NEQ
           LDA  (FROM),Y
           STA  (TO),Y
           INY
        REPEAT
        RTS
 ;--------------

The structure macros are from my article on the subject; but I have no doubt that you can guess exactly what they assemble.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'd forgot about the html code makers.
Thanks for reminding me.
Could a moderator move this to programming, I seem to have
put it in the wrong place.
I had a number of different sized blocks to move that were from
my test EPROM code, if you see my KIM-1 stuff in nostalgia.
one block more than $100. It seemed like before I thought about
it, I'd fix one section and break the other, back and forth.
When I thought about it I saw what I was doing.
I'd played with multiple block moves in RAM doing self modifying code.
I kept the FROM and TO pointer separate so after each block,
I'd do two increments for each pointer. That allowed me to have one
subroutine to do all the moving. I was trying to move every
thing into a single EPROM but finally gave up. I just didn't have enough
free space. It was for micochess. If I didn't load the one opening moves,
I could have done it but not with it. I only have the 1K window to work
with and a few extra bytes.
Bruce doesn't mention about overlapping memory for moves.
Dwight

MVN can also be used as a high-speed block fill method.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

[quote="GARTHWILSON"]I find I seldom have to move 256 bytes or more, since most moves are strings or other short pieces, so in my '02 Forth, I added QCMOVE and QCMOVE> (adding the "quick" to the standard "character move" and "character move up" words).

Hi Garth
I should note that I don't use a regular assembler. I have fpc running on an older 486 that I use for blowing EPROMs. It has a PB-10 (ISA bus). I have fpc running on it and use a single pass assembler I wrote in Forth. It has no infixed notation. I use macros to eliminate meaningless labels as you do.
I deal with large forward references by what I call Segments. I define a segment like this:

Each segment word keeps track of where it was so that invoking its name moves
the assembly pointer back to the last location to be used by that segment.
It does this by indirecting the assembly pointer.
I don't do any intentional warning for overlapping code but I do manually check
before writing it all out to files.
Using macro structures for code, like yours, such as:

similar to what you have.
Dwight

That's a piece of gold! Take care of that and don't let it get away! (I have a PB-10 too, in a similar old PC.) I seldom use it, but I hope that it (especially the PB10) never quits working. The assembler I use on the PC is Cross-32 (C32), originally from Universal Cross Assemblers. I think I still have 2500AD's assembler too, but haven't used it in decades.


The assembler I wrote that runs in the Forth on my workbench computer does not do any parsing, but it still puts the mnemonic before the operand, so you have for example
where you comma-in the operand. Being Forth, you can do any desired amount of calculation to figure out the operand before comma'ing it in. The LDY_ZP only lays down the op code. Branches have slightly more complexity, but still start with laying down the op code, like BNE. In its original form, I wrote it in one evening. It was an exciting moment when I realized macro capability was automatic.


That's something I have not seen before.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Here is the code:


When I look at the code now, I realize it would have been
better to update the current pointer when changing segments rather
then updating for each byte but it works as it is. It is just not as
efficient as it could be. I wrote this assembler at least 20-25 years ago.
Although, not in this assembler, for other assemblers, I have
a way of creating a linked list for forward references that patch
themselves when the reference is resolved. I uses a lot of space
for the linked list but allows a different method of keeping things
as a single pass.
One has to predefine a template similar to what is done in C.
Since I always assemble in a separate buffer that one can use
as a virtual space of any size, I can arbitrarily build the linked
list in Forth's definition space.
One has to be careful if doing forgets as these links are not attached
tightly to any word. Things are so fast at compiling now that I
recompile the entire assembler and the code at the same time.
Any changes, I just delete all the definitions.
It is done before I have time to remove my finger from the enter
key.
It only takes another millisecond to write the finished image code to
disk.
I still sometimes do assembly on my IMSAI under CP/M.
It is astounding how far we've come.
Dwight