Just a comment in passing, and isn't intended to disparage or chastise you! It's more about "assembler education":sdm wrote:ok, everything seems to work, the problem was a small trifle - before LDA% 00000110, there was no "#" character (of course, nesasm3 did not display an error and I missed the problem).
If the code was lda %00000110, then that's 100% valid code; the assembler not showing an error is correct behaviour. What you did there is essentially the same as writing lda 6 or lda $06 (load accumulator from zero page location 6). Just because you chose to use base 2 (binary) instead of base 10 (decimal) or base 16 (hexadecimal) doesn't change things in the least. There's no 100% correct way for the assembler to detect this situation as an error vs. something the user actually wanted to do; you can't assume that using base 2 as an operand isn't what the user wanted to do, and I have seen plenty of code on the Apple II where people have used base 10 addresses as operands, as "bizarre" as that might seem, but it's perfectly OK.
Iplementing a feature in the assembler (defaulting to disabled) that would allow you to tell it "only expect labels/equates, or base 16 numbers, as operands for non-immediate addressing modes" might sound like a good idea, right? When enabled, lda %00000110, lda 6, or MYVAL = %00000110 / lda MYVAL would cause an error to be thrown, while lda $06 or MYVAL = $06 / lda MYVAL would be OK. This would be annoying to implement in the assembler, however, because it would then have to track what base a particular line of code used, and there's no way to sanely deal with, say, lda $06+%10000000 (e.g. lda $86) or MYVAL = $06 + 128 / lda MYVAL. In other words, there would be tons of edge-case situations that would cause the assembler to potentially throw an error when the user didn't want it, plus adding complexity. Starting to see why nobody tries to implement this kind of thing? :-)
Like with any programming language, a single character/byte mistake can cause lots of pain. Pain that can cost you hours of time debugging/reverse-engineering. It's not unique to 6502 assembly at all. There isn't a 100% infallible way to relieve this problem in the computing world, sorry to say.