Hmm.. I fooled around a bit with LAX imm in VICE now, and it did not work as I expected. For example, just stepping through the following code in the monitor:

loop:
op = *+1
!byte $ab,0 ;LAX imm
inc op
jmp loop

...does not make the A and X registers change value each iteration. Rather, SOMETIMES the A and X register changed value, but not every iteration. When I look at Graham's description of the LAX imm opcode, it seems that it should work just the same as LAX zp for example, but with immediate addressing mode. It says:

A,X:=#{imm}

...but that seems wrong, judging from what VICE does (if assuming that VICE emulates LAX imm accurately). Anyway, when I look in Ninja's AAY-description of the opcode, it says something else, namely:

It is not entirely transparent to me what exactly this means, but I take it that not all bits are treated the same way. Well, in fact, when looking at the register values that I get in the VICE monitor, it seems that bit 0 and bit 4 in the immediate operand does not seem to make it into the X and A registers. Is that was the LAX imm instruction is "supposed" to be doing on an "unstable" machine? ...or on a "stable" machine? If this bit dropping is what it is doing (sometimes) on an "unstable" machine, then it seems to me that using something like LAX #0 to set both X and A register to 0 should be safe on any machine, since bit0 and bit4 aren't involved anyway? ...and if this is what LAX imm is supposed to be doing on a "stable" machine, then what is it that sometimes happens on an "unstable" machine? No bit dropping? More bit dropping?

i just tried lax# on my c64 and c128d. both worked fine for all 256 values. i tried playing with vic registers, enabling sprites etc. during the tests and apparently, if lax# works on a machine, it works flawlessly.