| |
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
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
usually there's a way to do what you want with illegals, and a way with legals, and 95% of the time the cyclecount are the same. You cant really generalize where and what is useful, using illegals needs quite specific code. But some will prove me wrong lets see :) |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Those opcodes with "AND PCH+1 drops sometimes off" are not that mystical. It drops off, when VIC takes over the bus. Try disabling badlines and it will never drop off (at least on the various machines I checked). Activate a sprite and it will drop off again. Maybe you can time your code to that :)
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Any examples where Illegal opcodes have been used in VIC trickery? One example I know of is darwin/dreams where 6 sprites over full screen FLI were achieved.
Any more? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@algorithm: When Crossbow did 5 sprites over FLI :)
@ninjadrm: What does "drop off" mean in this case? That it doesn't perform the and, or that it adds 1 to the and value?
|
| |
Ninja
Registered: Jan 2002
Posts: 411 |
@algorithm: Surely some more VIC-tricks have used basic stuff like LAX or SAX.
@cruzer: The AND drops off, so in case for SHX and SHY you have the pretty nice STX abs,y and STY abs,x opcodes. If you time it to VIC access that is :) Geez, I really could finish the article about those one day...
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Often you need to use illegals if you want to put magic colors on the leftmost 3 chars of a normal FLI-picture. That's more a conisidence though.. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ninja, now thats interesting !! could you shortly describe how and what happens ? |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@Ninja: So.. Does that mean SHX/SHY works in the border or do you have to disable VIC? (I could try it, but only on one machine..) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
this means imho that if the vic takes over the bus during shx/shy etc, then the and effect is dropped, or something like that :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
What bugs me with the VIC-take over explanation is the fact that the VIC has taken the bus... i.e the CPU doesn't do anything at all. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
as i understand it... if its a RRMW, the vic could take over the bus in the M cycle and somehow make the "shortcut" that causes the AND disappear... *shrug* |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
My guess is that AND doesn't disappear, it just does the operation with #$FF which appears on the bus when BA goes low (instead of anding with the last read byte, which was high byte of address). 6510 isn't halted until it does read access. |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
TNT: Yeah, this is my assumption, too. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Ok, so just to recap... The only unstableness of AHX, SHY, SHX and TAS are that the AND is not performed (or is performed with $ff) if the VIC uses the bus during the execution of the command. So if the code is placed in $ffxx or somewhere else where the values are not affected by the AND, it will be completely safe to use these opcodes? |
| |
Ninja
Registered: Jan 2002
Posts: 411 |
Cruzer: Correct. Only that you have to use $FExx, as the AND is performed with PCH+1. $7Exx or $3Exx might also come handy. I think, Graham used this in Oneder. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: My guess is that AND doesn't disappear, it just does the operation with #$FF which appears on the bus when BA goes low (instead of anding with the last read byte, which was high byte of address). 6510 isn't halted until it does read access.
Interesting thread...
I must be wrong but I thought #$ff is on the bus when BA goes low, and this happens within those "X" cycles. If the AND is done with the value which is on the bus it should only be stable when BA goes low and it should make problems when BA does not go low (i.e. when there is no X-cycle). AAY64 tells us that the VIC reads the last byte from the actual VIC_bank (modded when in ECM), so does this byte affect the stability, too? Is there any explanation for the page_wrapping behaviour?
Those opcode said to be highly unstable (LAX imm, ANE/XAA imm) should also have some general explanation, no?
Unfortunatly I do not have the time to test things on my own atm - maybe in some weeks.
CF |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Accurate descriptions of the "highly unstable" ones (as mentioned, LAX imm, ANE/XAA imm..) would be very interesting indeed. I could use LAX imm every now and then for sure... |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
LAX #imm is only unstable on some CPUs and it's much more unstable there compared to the AND of SHX etc, so it's propably not bound to VIC activity. |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
LAX imm and ANE imm might also depend on some other things like CIA, cpu type (6510 or 85xx) or what else is sitting in the breadbin. Does "only unstable on some cpus" mean that for most of the cpus LAX imm is completely stable? And does this really only depend on the cpu used? Don't know how many tests (on way too much different machines) would be necessary to find this out...
It would really puzzle me if the highly unstable opcodes are capable of giving truly random results - there must be some explanation for what the whole system does when the cpu is fed with these ops.
CF |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: LAX imm and ANE imm might also depend on some other things like CIA, cpu type (6510 or 85xx) or what else is sitting in the breadbin. Does "only unstable on some cpus" mean that for most of the cpus LAX imm is completely stable? And does this really only depend on the cpu used? Don't know how many tests (on way too much different machines) would be necessary to find this out...
It would really puzzle me if the highly unstable opcodes are capable of giving truly random results - there must be some explanation for what the whole system does when the cpu is fed with these ops.
CF
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. |
| |
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. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Edit: nothing... |
