It is currently Tue Nov 21, 2017 8:56 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Sat Apr 02, 2016 12:46 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2360
When I try to use these instructions in bass.exe, they don't work for some reason. I don't know if I'm doing it correctly. Let's see if I have this straight:

- For MVP, data moves from $0000,x to $0000,y and both x and y are decremented.
- For MVN, both x and y are incremented.
- On most assemblers their written like this "MVN $aa,$bb" which means move from $aa0000,x to $bb0000,y.
- On bass.exe, it's written like this "MVN $aa=$bb".

Anything I have wrong?


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 2:20 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
I can't determine from your post vs. subject if you're asking about how MVN/MVP actually behave/operate, or if you're asking about the weird syntactical difference between assemblers (or more specifically with bass).

If the former -- no, there's more to it than that (and some nuances that aren't immediately apparent), but you understand the gist of it correctly.

If the latter -- can't help with that one. Syntactically in all Apple IIGS assemblers I've used, it's been MVN $src,$dst (and MVP is the same syntax), where $src refers to the source bank, and $dst refers to the destination bank. However, the assembler should be generating them in reverse order (e.g. MVP $20,$7f should assemble to 44 7f 20).


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 2:41 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
The reason I went with mv[np] target=source is because the 65xx processors don't have any other dual-operand instructions (addressing modes don't count; with saner mnemonics, they'd be + and not ,); and so it's ambiguous whether it's "target,source" (x86 style) or "source,target" (68k style). I preferred to just use = instead to make it unambiguous.

However, you can easily extend bass in real-time with the traditional syntax if you like. See the manual for the "arch.append" syntax.


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 3:22 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Official Western Design Center documents clearly outline the syntax as mvn srcbk,dstbk and mvp srcbk,dstbk, with full explanation that the actual assembled bytecode is $54 dstbk srcbk and $44 dstbk srcbk respectively. I've always shrugged this off as "part of the little-endian aspect" (even though these are bytes and not words) and have never cared to get political about it -- there's an actual reason the bytecode is "reversed" even for this. WDC's official documentation for the MVN/MVP opcodes is:

Quote:
Assembler syntax for the block move instruction calls for the operand field to be coded as two addresses, source first, then destination – the more intuitive ordering, but the opposite of the actual operand order in the object code. The assembler strips the bank bytes from the addresses (ignoring the rest) and reverses them to object code order.

However, in the same document describing how to use MVN/MVP with actual code examples (stripped), we find this:

Quote:
... In the object code, the first byte following the opcode is the bank address of the destination and the second byte is the bank address of the source. But while this order provides microprocessor efficiency, assembler syntax has always been the more logical left to right, source to destination (TAY, for example, transfers the accumulator to the Y index register). As a result, the recommended assembler syntax is to follow the mnemonic first with a 24-bit source address then with a 24-bit destination address - or more commonly with labels representing code or data addresses. The assembler strips the bank byte from each address (ignoring the rest) and inserts them in the correct object code sequence. (Destination bank, source bank.) For example:

Code:
440102     MVP SOURCE, DEST      move from bank of source(02) to bank of dest(01)

The bank byte of the label SOURCE is 02 while the bank byte of the label DEST is 01. As always, the assembler does the work of converting the more human-friendly assembly code to the correct object code format for the processor.

If the source and destination banks are not specified, some assemblers will provide a user-specified default bank value.

The assembler will translate the opcode to object code, then supply its bank value for both of the operand bytes:

Code:
440000     MVP

If either bank is different from the default value, both must be specified.

That statement compounded with the fact that (splitting hairs/nitpicking) the SNES CPU isn't from WDC, whatever syntax someone wants its their choice. I think if bass says it wants mv{n,p} $src=$dst then fantastic and no problem.

The question then becomes: what, given the initial post, does "they don't work for some reason" mean exactly?


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 3:37 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
Still, that's a neat anecdote. I didn't see that in their manual previously.

There's no reason I can't support both, so I'll add their preferred method in to a future release, then.


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 5:18 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
byuu wrote:
the 65xx processors don't have any other dual-operand instructions (addressing modes don't count; with saner mnemonics, they'd be + and not ,); and so it's ambiguous whether it's "target,source" (x86 style) or "source,target" (68k style). I preferred to just use = instead to make it unambiguous.

The T series register move instructions are all 68K style: tax, tay, txa, tya, and all the new ones added to 65816.


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 5:19 pm 
Offline

Joined: Sun Mar 27, 2016 7:56 pm
Posts: 138
Note that the number of bytes to move is determined by the A register. To copy $400 bytes from $7e4000 to $7f8000 in bass, you'd write the following (assuming 16-bit A/X/Y):

Code:
ldx #$4000
ldy #$8000
lda #$0400
mvn $7f=$7e


However, keep in mind that MVP and MVN are significantly slower than DMA, and thus not very useful on the SNES. Specifically, DMA transfers a byte every 8 master cycles, which is equivalent to 1 CPU cycle at 2.68 MHz, or 1.333 CPU cycles at 3.58 MHz. MVP/MVN transfer a byte every 7 CPU cycles, which is equivalent to 56 master cycles at 2.68 MHz, or 42 master cycles at 3.58 MHz. In short, this means DMA is anywhere from 5.25x to 7x as fast as MVP/MVN.

Given the overhead in setting up DMA registers, there might be cases where MVP/MVN is better with small amounts of data (I haven't done the math to say for sure), but for the most part, DMA is the way to go.


Top
 Profile  
 
PostPosted: Sat Apr 02, 2016 5:24 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
tepples wrote:
The T series register move instructions are all 68K style: tax, tay, txa, tya, and all the new ones added to 65816.


I didn't consider that a compelling argument since those are three-letter opcodes and not comma separated functions ala "mov x,a" (thank god. I actually wrote my own alternate SPC700 syntax because that chip was clearly a specialized 6502 core and not an x86-alike.)

However, the discussion's rhetorical at this point: I'll follow the manual excerpt koitsu posted and add mv[np] source,target to the next bass release.

Quote:
However, keep in mind that MVP and MVN are significantly slower than DMA, and thus not very useful on the SNES.


Further, it corrupts the DB register to the target bank. Be sure to phb; plb or ensure that the target bank is an acceptable new value for DB.

The only good use I've ever found for mvn/mvp was for the sliding window in an LZSS decompression routine, because the SNES can't DMA to and from WRAM at the same time for obvious reasons.


Top
 Profile  
 
PostPosted: Sat Nov 11, 2017 1:34 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 75
Nicole wrote:
To copy $400 bytes [...] lda #$0400

These instructions copy accumulator+1 bytes, so you'd use #$03FF.

Another difference to DMA is that MVx can be interrupted, so an ISR would be able to observe the copying progress. This also makes the duration variable, in addition to the bus waitstates of the SNES memory areas.


Top
 Profile  
 
PostPosted: Sun Nov 12, 2017 1:47 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 582
I thought WDC named these exactly the wrong way around. MVP is to me "move positive" and MVN "move negative", when they thought "move previous" and "move next". /unrelated rant


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group