Just putting this here in-case someone else mis-reads their assembler documentation as I did recently ...

The mnv and mvp instructions take a source and destination bank numbers, so it's a 3-byte instruction, so naively, you might code it



to move from bank 1 to bank 4. (after setting up A, X & Y).

However this won't work as the assemblers (at least ca65, and I think some others) want the full 24-bit address, even though they strip off the bottom 16 bits, so this ought to be:



I now use a little macro in ca65 for simple moves with immediate values



and so on for other variants.

Anyway. might help someone wondering why random RAM appears to be clobbered..

It's also a shame in a way that the from & to banks can't be easily changed dynamically without self modifying code. (No change from the PDP-8 there, then

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

That's very unexpected!

ca65, at least the version I'm running atm, seems to assemble mvn/mvp just fine with only 8-bit operands:



EDIT: it occurs to me it may be assuming they are 24-bit and expanding them, but since they are both bank 0, it's not obvious from my code. I'll have to try a non-bank 0 example.

It assembles OK and is correct - for arguments 0,0. This is what initially threw me in my 65K 6502->65816 board. It was only with the 65816 board with 512K of RAM that I found different..

e.g. Trying with arguments 1,2 to copy from bank 1 to bank 2



this assembled just fine but appears to put the wrong parameters to the instruction, but if I use:



then it does the right thing.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I found this post when looking for using the 65816 move block instructions with self-modifying code. I had a similar problem in a straightforward port of my 6502 MOVE function to the 65816. assembled as I found that ca65 will accept the following syntax:
to give Apparently in the first place it's treating the operands as addresses.

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

I suppose that would have added a few more cycles to each byte moved. Since the instructions are interruptible, I don't think they could avoid this.
Maybe that's why they decided to go this way.

They might have put the bank addresses in the high and low halves of the accumulator, but I don't know if that would have opened up an engineering can of worms.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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

OOf ... shows how many times I've used those instructions ... I think the last time was around 1988, when I had an '802 installed in my ][+ for some harmless fun with the hi-res graphics pages.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)