| |
Intensity
Account closed
Registered: May 2002
Posts: 337 |
How MOS 6502 Illegal Opcodes really work
Maybe this does interest you, i have no clue about it, but MIST (Michael Steil), a german code and hardware c64 enthusiast, recommended me to post that here :
http://www.pagetable.com/?p=39
Maybe there is something to discuss!
Greetings,
Arman Behdad |
|
... 1 post hidden. Click here to view all posts....
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:Personally I hope to one day see some accurate documentation of the unstable opcodes, what precisely makes them "unstable", and therefore when they can be used safely (e.g. can I clear A and X with LAX #$00?).
you wont be safe anyway- the behavior of the unstable opcodes varies between C64`s. you can see it in Wolfgang Lorenz Emulator Test suite in which certain "Trap" tests fail if your machine has a sensitive handling of the unstable op codes. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quote: Quote:Personally I hope to one day see some accurate documentation of the unstable opcodes, what precisely makes them "unstable", and therefore when they can be used safely (e.g. can I clear A and X with LAX #$00?).
you wont be safe anyway- the behavior of the unstable opcodes varies between C64`s. you can see it in Wolfgang Lorenz Emulator Test suite in which certain "Trap" tests fail if your machine has a sensitive handling of the unstable op codes.
Well.. Yes, of course their behavior varies - that's what makes them unstable. The question is precisely how do they vary, and under what conditions (other simultaneous bus activity, certain chips versions always doing certain things, truly random behavior, or whatever). Or are you telling me that and and all of the unstable opcodes might potentially simply crash the chip if you're unlucky?
For instance in the case of LAX #$00 both the possible results documented in Graham's opcode list would achieve the desired result (i.e. resetting both A and X). Similarly SHX/SHY would be highly useful as absolute indexed versions of STX/STY, that is if page crossings are avoided and the AND with the page number is either acceptable or can be predicted to always/never occur under certain circumstances.
And if behavior varies between chips but is always the same on one particular chip then perhaps that could be detected and separate code paths used.
But there's still a big "unstable opcode!" (here be monsters..) warning in there and much mystery still surrounding them so I wish they were better and more authoritatively documented, rendering them too risky to use for anyone without *a lot* of hardware to test on. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
As far as I know, the instability of AXH, SHY, AHX and TAS only means that the AND is skipped when the VIC does DMA for badlines or sprites. So this should be the same on all machine and is also emulated correctly on Vice, or at least Hoxs64. This means that you either have to use some addresses/values where the AND doesn't matter, or time it to the VIC, e.g. use them in a FLI displayer or in some code that always runs where there are no badlines/sprites, like the upper/lower borders.
So that leaves us with only two mystery opcodes left: LAX# and XAA.
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
I take it they (AXH/SHY/AHX/TAS) have been successfully used in demos. I've got a few tables tables which could be relocated to pages where the masking is irrelevant.
What about LAS ($BB) then? |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
LAS is stable (although probably too weird to be useful) according to http://www.oxyron.de/html/opcodes02.html
|
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quote: As far as I know, the instability of AXH, SHY, AHX and TAS only means that the AND is skipped when the VIC does DMA for badlines or sprites. So this should be the same on all machine and is also emulated correctly on Vice, or at least Hoxs64. This means that you either have to use some addresses/values where the AND doesn't matter, or time it to the VIC, e.g. use them in a FLI displayer or in some code that always runs where there are no badlines/sprites, like the upper/lower borders.
So that leaves us with only two mystery opcodes left: LAX# and XAA.
Hmm, interesting!
What about the page-crossing behaviour? Is it also DMA-fetch-dependant?
If those 'unstable illegals' will be understood, then only the DMA-delay-bug stays unexplained (somehow I do not accept this standard argument 'machine-dependant').
Hope to read more on this soon! |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
btw, there's much more detailed info here in hungarian: http://impulzus.sch.bme.hu/6502/6502/.
die picture (BIG one):
http://impulzus.sch.bme.hu/6502/download/6502_full.png
complete transistor schematics (based on the die) here:
http://impulzus.sch.bme.hu/6502/letolt.php3
and there's a little writing where there's very low level (tho quite short and not very indepth) analysis about the ALU, opcode decoder, timing, irq, etc together with their transistor schematics. I can translate it, if an emulator author would like to use the info :)
an interesting part about the opcode decoder:
many input gates processes such outputs of the PLA (=opcode decoder) which are not fully specified: a few bits of the opcode is neither connected to 0 or 1 , thus the illegal opcodes can produce quite interesting behaviour. Because it is not checked wether an opcode is legal or not, something will happen afterall. a few outputs of the PLA will get active, which will mae the registerblock do something. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: btw, there's much more detailed info here in hungarian: http://impulzus.sch.bme.hu/6502/6502/.
die picture (BIG one):
http://impulzus.sch.bme.hu/6502/download/6502_full.png
complete transistor schematics (based on the die) here:
http://impulzus.sch.bme.hu/6502/letolt.php3
and there's a little writing where there's very low level (tho quite short and not very indepth) analysis about the ALU, opcode decoder, timing, irq, etc together with their transistor schematics. I can translate it, if an emulator author would like to use the info :)
an interesting part about the opcode decoder:
many input gates processes such outputs of the PLA (=opcode decoder) which are not fully specified: a few bits of the opcode is neither connected to 0 or 1 , thus the illegal opcodes can produce quite interesting behaviour. Because it is not checked wether an opcode is legal or not, something will happen afterall. a few outputs of the PLA will get active, which will mae the registerblock do something.
Very interesting analysis on that page!
Has anyone managed to make a somewhat readable pdf of the transistor model postscript files?
(http://impulzus.sch.bme.hu/6502/letolt.php3)
I just did a ps2pdf on it, but it turned out many pages. I don't want to print it, just zoom and scroll around.
|
| |
Hein
Registered: Apr 2004
Posts: 954 |
The .ps file is made of different (A3) pages too. I guess the only option is to save 20 seperate PDF files and start glueing the 4 rows of 5 pages together in Illustrator, then save the big one as PDF. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: The .ps file is made of different (A3) pages too. I guess the only option is to save 20 seperate PDF files and start glueing the 4 rows of 5 pages together in Illustrator, then save the big one as PDF.
Thanks for looking into it Hein.
I guess I'll just have to mail him to generate a single page one. He obviously managed to generate a lower res png of it so it should be possible. |
| Previous - 1 | 2 - Next |
