I'm pretty sure this is the case, but curious of any conflicts.

Simply, will a 6502 assembly language program assemble properly in a 65816 assembler, especially if the LONGI and LONGA attributes are defaulted to 8 bit.

That is the 6502 instruction set is a complete, perfect subset of 65816. That there isn't anything that the 65816 changes on top of 6502, (and 65C02).

The LONGI and LONGA pseudo codes to the assembler handle whether, for example, LDA #123 is a 8 bit or 16 bit operation, but, in 8 bit most it's completely compatible with 6502.

The "downside" of assembling a 6502 program in a 65816 assembler is simply that if you accidentally use a 65816 feature (different addressing mode, for example), then the assembler wouldn't complain, and it would assemble an inappropriate code. So, in that sense, the assembler protects you as a 6502 developer from making those kinds of mistakes.

But, beyond that, there's no semantic differences, right? 6502 IS 65816 code.

I'm talking at the assembly level and the code generated. Not specifically running 6502 code on a 65816 (whether emulated or native). Just, source code compatibility.

If I have a 65816 assembler, I also have a 6502 assembler.

Pretty much, yes. Those 65C02s which filled in the unused opcodes fully do then conflict with the 65816 opcodes. Some things which would be mistakes in 6502 land might be legal in 65816 land - such as an absolute address longer than 16 bits.

I like to use this page as a reference:
http://www.llx.com/~nparker/a2/opcodes.html

Edit: I suppose with the '816's extra instructions, some words which were, say, previously legal labels, variables or macro names might now match mnemonics and become illegal. For example if you had a macro called JML that might be an error.

_________________
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?

Yes.

Incidentally, the LONGA, LONGI, etc., pseudo-ops are specific to certain assemblers and merely tell the assembler to generate an 8 or 16 bit immediate mode operand. These pseudo-ops do not tell the '816 which register sizes to use—that is determined by how the m and x bits in the status register are conditioned. The REP and SEP instructions are used to condition m and x, usually within some macros, as Garth mentioned.


Most assemblers that support the '816 have a pseudo-op that defines the target MPU. If that is the case and the assembler is told it is assembling for a 6502 or 65C02, 65C816-specific mnemonics and/or addressing modes will produce an assembly-time error.


That seems to vary from one assembler to another. I've encountered a few assemblers that consider anything that starts in column one to be a label or symbol, even if it is a legal mnemonic. Hence:

Code:

LDA      LDA #$12

would assemble without error. Of course, that is probably something best avoided for clarity's sake.

Also, there are a few assemblers that allow macro names to be the same as mnemonics and thus will allow a macro to replace the mnemonic in instructions. The Commodore HCD65 assembler had this capability, which allowed me to assemble standard 6502 instructions with 65C02-specific addressing modes (e.g, BIT #).

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

The 2500AD assembler that granati mentioned earlier today or yesterday has a MACFIRST ON|OFF directive that lets you use a macro to re-define a mnemonic, and tell the assembler when to when to use the macro version and when to use the normal version. I suppose it could be quite useful, although I never used it when I was using 2500AD.

_________________
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?

While 6502 source code should assemble fine for a 65816, there are some bugfixes that the later processors (65c02, 65816) corrected, so the software might run differently depending on if you used some of those edge cases. Most of them were timing-related, but I think the most major software-exposed one is that JMP (xxFF) on 6502 would not wrap the high byte, e.g. JMP ($20FF) would read $20FF and $2000 for the low & high bytes of the address, whereas the later processors would read $20FF and $2100. There was also some cleanup with how the processor flags worked around decimal mode and interrupts.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Yea, I realize all of that.

My main driver was that I was going to work on a Forth 6502 assembler, and it occurred to me I could just write a 65816 assembler instead, and have a 6502 one "for free", for new "greenfield" code.

Thanks all