Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > How MOS 6502 Illegal Opcodes really work
2008-07-30 23:16
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
2008-07-31 00:26
doynax
Account closed

Registered: Oct 2004
Posts: 212
Nice work tracing the die, and I'd surely like to see a more extensive study of the "weirder" illegal opcodes. This short post doesn't tell use anything new about their behavior though, and it leaves some obvious questions. Like how are penalty cycles and 8-cycles illegals dealt with, surely no one designed the chip to make those sequence properly?
An awesome project would be making the herculean effort of fully deciphering the logic and directly basing an emulator on the results..

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?).
2008-07-31 00:50
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.
2008-07-31 07:02
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.
2008-07-31 10:56
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.
2008-07-31 11:10
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?
2008-07-31 11:34
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
2008-08-02 18:53
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!
2008-08-03 04:45
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.
2008-08-03 09:30
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.
2008-08-03 21:30
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.
2008-08-04 09:22
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.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Andy/AEG
BYB/Hokuto Force
Soya/Fairlight
Peacemaker/CENSOR/Hi..
t0m3000/hf^boom!^ibx
Conjuror
kbs/Pht/Lxt
zscs
XmikeX
Brataccas/HF
rexbeng
megasoftargentina
McMeatLoaf
Technotron/I-I F
Guests online: 133
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Musicians
1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.063 sec.