| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Unstable Illegal Opcodes
I have always avoided the opcodes that are marked as unstable on Graham's opcode list:
http://www.oxyron.de/html/opcodes02.html
But maybe some of them could be used in some cases after all? Anyone who can shed some light on when excactly they are unstable?
According to Graham's list there are two kinds of unstableness, the first being "unstable in certain matters", which applies to these opcodes:
ahx
shy
shx
tas
The other one doesn't leave much hope: "Highly unstable (results are not predictable on some machines)", but only these two are that bad:
xaa
lax #imm
|
|
... 21 posts hidden. Click here to view all posts....
|
| |
AlexC
Registered: Jan 2008
Posts: 299 |
Quote: The best check would ofcourse be to swap the CPU's if you find a system that is highly unstable and a completely stable one. For now all my machines seem to be 100% reliable on LAX #Imm.
I confirm - all my machines produce stable results with LAX #imm. However I am wondering if anyone actually did any further research into XAA cases. It seems to me that on mine C128D this instruction is also stable always producing the same result. |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
I remember that I had some problems with this opcode on my first c64 (rest in peace now).
It results different for "LAX #$ff":
Sometimes $FE, sometimes $EF and sometimes $EE.
But in the case of "LAX #$00" there was no problem at all.
|
| |
ready.
Registered: Feb 2003
Posts: 441 |
I found this about XAA:
http://visual6502.org/wiki/index.php?title=6502_Opcode_8B_(XAA,..)
I still haven't tested it on a real c64, but this is the best description I have found so far about this illegal opcode. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
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:
Operation: X04 <- (X04) /\ M04 N V - B D I Z C
A04 <- (A04) /\ M04 / . . . . . / .
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? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
You might be interested in checking this: http://vice-emu.svn.sourceforge.net/viewvc/vice-emu/testprogs/g..
The assumed behaviour of LAX #<imm> is: X,Acc = (Acc | CONST) & #<imm>.
As far as I could tell peiselulli's assumption about LAX #$00 holds. The "& <imm>" would always be honoured on the machines I tested.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Hmm.. I fooled around a bit with LAX imm in VICE now
better use the real thing for this kind of stuff =P the opcodes mentioned in this thread are kindof hard to test (and thus to emulate) so there are probably still bugs in the vice cpu core. |
| |
Skate
Registered: Jul 2003
Posts: 494 |
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. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
@skate: as you can see from the runs of my test program the behavior of LAX #<imm> will depend on things like temperature and perhaps voltage on some machines.
As far as I have seen that formula holds though. I.e only CONST is different and it can _change_ over time, but presumably slowly. There might also be correlation effects between registers and CONST.
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
So lax #$00 should always work? And this should be safe too:
lda #$ff
lax #anyValue
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Yes it should. Note that ane-lax.prg was primarily designed to test ANE so it only tests the resulting ACC of LAX #<imm>, not X.
IIRC the visual6502 guys tested both Acc, X and flags using a test rig for 6502/6510 chips. |
| Previous - 1 | 2 | 3 | 4 - Next |
