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

[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

[BigEd]

That's very unexpected!

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

[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

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

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

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

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

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

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