Page 1 of 1

Another 65816 'gotcha' .. mvn/mvp ...

Posted: Tue Aug 20, 2019 9:13 am
by drogon
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

Code: Select all

        mvn    1,4
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:

Code: Select all

    mvn    $01000000,$04000000
I now use a little macro in ca65 for simple moves with immediate values

Code: Select all

; bmn
;       Block move macro

.macro  bmn     len,from,to
        lda     #len-1
        ldx     #(from & $FFFF)
        ldy     #(to   & $FFFF)
        mvn     (from & $FF0000),(to & $FF0000)
.endmacro
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

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Tue Aug 20, 2019 9:53 am
by BigEd
That's very unexpected!

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Wed Aug 21, 2019 1:53 am
by jmthompson
ca65, at least the version I'm running atm, seems to assemble mvn/mvp just fine with only 8-bit operands:

Code: Select all

000082r 1  44 00 00             mvp     0,0                     ; remove parameters
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.

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Wed Aug 21, 2019 6:16 am
by drogon
jmthompson wrote:
ca65, at least the version I'm running atm, seems to assemble mvn/mvp just fine with only 8-bit operands:

Code: Select all

000082r 1  44 00 00             mvp     0,0                     ; remove parameters
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

Code: Select all

000306r 1  54 00 00             mvn     1,2
this assembled just fine but appears to put the wrong parameters to the instruction, but if I use:

Code: Select all

000306r 1  54 02 01             mvn     $010000,$020000
then it does the right thing.

-Gordon

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Thu Jun 09, 2022 5:18 pm
by tmr4
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.

Code: Select all

mvp 1,2
assembled as

Code: Select all

44 00 00
I found that ca65 will accept the following syntax:

Code: Select all

mvp #1,#2
to give

Code: Select all

44 02 01
Apparently in the first place it's treating the operands as addresses.

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Thu Jun 09, 2022 6:56 pm
by BigDumbDinosaur
tmr4 wrote:

Code: Select all

mvp 1,2
assembled as

Code: Select all

44 00 00
I found that ca65 will accept the following syntax:

Code: Select all

mvp #1,#2
to give

Code: Select all

44 02 01
Apparently in the first place it's treating the operands as addresses.

The MVP #1,#2 syntax is not in agreement with the official WDC syntax, but actually makes more sense, since the source and destination addresses are loaded into the index registers. The MVN/MVP instructions are kludges that are of very limited usefulness if all code is running out of ROM. What would have been better is if the operand was an address at which the source and destination banks would be found.

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Thu Jun 09, 2022 8:59 pm
by tmr4
BigDumbDinosaur wrote:
What would have been better is if the operand was an address at which the source and destination banks would be found.
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.

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Thu Jun 09, 2022 9:24 pm
by barrym95838
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.

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Thu Jun 09, 2022 11:16 pm
by BigDumbDinosaur
barrym95838 wrote:
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.

The accumulator is used as the “bytes copied” counter, so it’s spoken for.

What is really needed is a 65xx bus-compatible “blitter” to take care of mass memory copies and DMA-type operations.

Re: Another 65816 'gotcha' .. mvn/mvp ...

Posted: Thu Jun 09, 2022 11:31 pm
by barrym95838
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.