| |
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....
|
| |
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: 404 |
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: 404 |
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: 466 |
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: 1627 |
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: 466 |
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: 885 |
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: 293 |
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. |
| Previous - 1 | 2 | 3 | 4 - Next |
