I noticed in my other post about starting out with SBCs; viewtopic.php?f=1&t=3513 ... that in the sourcecode you provide on your website for SBC-OS (which is told to be used with TASM I believe?), uses "DEC" opcodes.. yet the simulator you provide to me.. 'barfs' at "DEC" and seemingly wants "DEA". I'm going to have to go with what the 6502 assembler needs, but I want to know...

Which is correct? DEC? or DEA?

DEA is an alias for DEC A. Both are correct. I'm not familiar with TASS though.

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

TASS supports DEC without an operand to impy the accumulator. The Kowalski simu;ator however does not allow DEC or DEC A. DEA is the only option for DEC accumulator. I should have added that in the comments.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

In the official MOS Technology assembly language standard, the syntax for any accumulator instruction is xxx A, where xxx is the instruction—A is an internal assembler symbol that represents in the accumulator. The reasoning has to do with the fact that all implied accumulator instructions, other than those that are register-to-register copies, can also also act on memory. Hence consistency in the assembly language is maintained by always having an operand for accumulator instructions, regardless of addressing mode. So one could write ASL FLAG or ASL A, and the assembler would understand the former to be acting on memory and the latter to be acting on the accumulator.

Many assemblers written by amateurs don't conform to the MOS Technology/WDC language standards for a variety of reasons, often resulting in unnecessary work to fix up source code so it will assemble.

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

Also, INA must be used in place of INC A.

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

In a way INA & DEA are consistent with register addressing (INX, DEY). We don't write INC X or DEC Y, so it kind of makes sense.

Actually, no. To understand why, you need to look more closely at the way the 6502 assembly language evolved from "prior art."

DEC A and INC A weren't part of the original instruction set—they were added in the 65C02. Their syntax follows the pattern of other arithmetic and logical instructions, such as ASL, LSR, etc., all of which are instructions that can act on memory or the accumulator, but not on the index registers. For example, with the 65C02 I can INC memory or the accumulator, which is different than INX or INY, which can only affect a specific register. INC is not register-implied, and thus the assembler has to have a way of determining which opcode to use when it assembles an INC instruction.

As a matter of necessity, any instruction that can act on memory must have an operand. Hence when MOS Technology wrote the assembly language standard 40 years ago, they copied what had been done with the Motorola 6800, the 6502's immediate ancestor, and required that any instruction mnemonic that could reference memory or the accumulator must have an operand. If the operation is on the accumulator then the symbol A acts as the operand. It's quite unambiguous and countless programmers who have known the 6502 assembly language since the processor's inception see it as the proper syntax. It's only the relative newcomers to 6502 machine code who don't seem to understand it.

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

I appreciate your preference for the original style, BDD, but I learned 6502 on the Apple ][, and Woz lumped the accumulator mode into the implied mode for his mini-assembler and dis-assembler. He seemed to have no trouble at all dealing with the issue you cite above, but he is the Woz. In his scheme, one-byte instructions have no operand, and I find that I prefer it that way. So, for me, it's DEA or a naked DEC, and I lean slightly toward the latter.

Mike B.

[Edit: "site" -> "cite" ... thanks, Jeff!]

Woz's "mini-assembler" is part of a machine language monitor, and is classified as an "absolute assembler," which is not a symbolic assembler. We're comparing apples with oranges here.

It's possible in an absolute assembler to do what you are describing, as the only thing that can appear in the operand field is a literal address or constant. Hence it can be assumed that an instruction such as DEC or ROL that has no operand must be acting on the accumulator. In an symbolic assembler, however, the operand field may contain a literal address, literal constant, label, symbol or computed value. That's quite a bit different than what goes on in an absolute assembler. So for the sake of consistency, the symbolic assemblers that were published over the years have required the presence of an operand with any mnemonic that operates on either the accumulator or memory. As I early said, the deviation from this started with relative newcomers to the 6502 assembly language, unnecessarily complicating things for those who have been working with the MPU since its inception.

Incidentally, Supermon, Supermon 64, the resident M/L monitor in the Commodore 128 and my Supermon 816 all work as does the absolute assembler in the Apple monitor, as again, the operand can only be a literal address or constant.

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

Please forgive me if I fail to completely understand what is "quite a bit different" ... by my reckoning, there's an operand, or there isn't an operand, regardless of its attributes. San Bergmans made a very nice symbolic assembler that has no problem recognizing a missing operand for a mnemonic that may or may not have an operand. If it sees a naked ASL (or DEC or whatever) it assembles the accumulator mode version and moves on. The only reason that he requires a newline (or a minimum amount of white-space between the naked mnemonic and the remainder of the line) is because he allows trailing non-delimited comments which could cause an attempt to treat the comment as an operand, with undesirable results.



Mike B.