Adding to the x Register

[xxl]

One demo crashed on a 65816 simply because the coder gratuitously used LAX #imm in the init routine wherever LDA #imm or LDX #imm could have been used.

 

 

there is no such opcode. what is hexcode of this LAX #imm

[Irgendwer]

It's not always easy because some of the opcodes do things that would normally require an extra register or RAM variable. So, at the very least the macro might need to push and pop.

 

Yes, but targeted for source code, reserving e.g. one ZP location for them shouldn't be such an issue. There is a runtime penalty for sure, but the macros would allow at least an executable for 'non-original' CPUs.

The same could make sense for 65C02 to 6502 code... when 65C02 owners like to produce a 'std.-build'...

...and then we introduce something like a fat-binary, compatible for all machines but benefiting a CPU type.

[landgraf]

 

 

there is no such opcode. what is hexcode of this LAX #imm

$AB. Also called LXA to seperate it from its stable "brothers" that use other addressing modes. Afaik only LAX #$00 is stable.

[xxl]

$AB - ANX # - performs A AND argument, result saves in A,X - UNSTABLE !

 

and yes, ANX #$00 works

 

http://xxl.atari.pl/sally-6502c/

[popmilo]

Me too:

...
lda ADD10, X
tax
....

ADD10:
.byte 10,11,12,13,14,15,16,17,18...

Why not make it easy to change adding value

...
lda $2010, X    ;for DC=$10
tax
...

org $2000
.byte 0,1,2,3,4,5,6,7,8,9,10... ;range from 0-510

[xxl]

and how to handle C (carry flag) with this LDA $nnnn,X ?

using well documented SBX code is still fastest/shortest/best option