How many of the 105 illegal opcodes are actually useful, or were ever used?

[applekevin]

As I understand it, the majority just produce erratic behavior. Which of these were worthwhile? Also, does this set differ in the 6502C SALLY from other 6502 variations?

[Magic Knight]

Can you explain what this is? sounds very interesting!

[xxl]

full list:

 

http://xxl.atari.pl/?p=824

[Tezz]

There are useful illegal opcodes, particularly useful in the extremes of optimising code. The argument from many about the use of them at all however is with breaking 65816 compatibility.

[xxl]

which model of 8-bit Atari has a 16-bit processor (65816)?

 

[Tezz]

which model of 8-bit Atari has a 16-bit processor (65816)?

Exactly I don't agree with the 65816 argument either.

[applekevin]

There are useful illegal opcodes, particularly useful in the extremes of optimising code. The argument from many about the use of them at all however is with breaking 65816 compatibility.

 

What percentage of them would you say are useful?

[xxl]

I use these: ANC, SAX, ALR, SBX, DCM, INS, DOP, TOP, LAX, ARR and ANX # $00

[+bob1200xl]

This one...

 

 

 

 

 

which model of 8-bit Atari has a 16-bit processor (65816)?

 

[xxl]

8-bit atari with 16-bit processor rather looks like this:

 

http://cbmmuseum.kuto.de/images/amiga_500.jpg

[Chilly Willy]

8-bit atari with 16-bit processor rather looks like this:

 

http://cbmmuseum.kut...s/amiga_500.jpg

 

Exactly. That's why when the time came to update from my venerable Atari 400, I got the Amiga 500.

[thorfdbg]

As I understand it, the majority just produce erratic behavior. Which of these were worthwhile? Also, does this set differ in the 6502C SALLY from other 6502 variations?

Most of the stuff is completely useless and a waste - despite that these instructions are undocumented and a programmer should be slapped in his face for using such stuff. But anyhow: There are *some* partially useful intructions there to load X and A register simultaneously, and to AND X with A. The rest are either combinations of other opcodes that, in their combination, are too "specific" to be of any value. Some of them use addressing modes depending on the data and stuff like that. Then there is a second class of opcodes that depend on the type of "noise" that is on the bus, and that are thus not even stable (depends on the circumstances what the result of such an opcode is), and a third class of opcodes that simply lock up the CPU where neither a IRQ nor an NMI can trigger any reaction. You need to reset the CPU to restart it.

[ac.tomo]

These are documented in the "Complete & Essential Mapping the Atari" book, & although they're use 'can' reduce instruction time, apparently I've heard that some of them react differently depending on what Atari you have, although, this I ain't sure on.

[xxl]

despite that these instructions are undocumented and a programmer should be slapped in his face for using such stuff

 

all stable "illegal" codes works on atari so what is the problem?

 

code using specific 6502c ability do not work on 65816? so what?

code using specific 65816 ability do not work on atari... also :-)

 

if program could runs faster (or be shorter) with undocumented codes why not use undocumented codes? I think just to fool the user that he needs a 16bit cpu

 

so, write bloated code and upgrade atari to 16bit

[thorfdbg]

all stable "illegal" codes works on atari so what is the problem?

Because a) you don't know what is "stable" because you have nothing from the manufacturer to warrant this. IOW, what may work on your machine may not work on another. I've seen here some "believed to be stable" opcodes that do not work on my XL. It's a standard plane "sally CPU" in it. b) even if, you do not know whether the machine was extended or equipped with a 65C02 or some successor processor. That said, due to timing or production differences, you cannot be sure that they function identically from machine to machine.

 

if program could runs faster (or be shorter) with undocumented codes why not use undocumented codes? I think just to fool the user that he needs a 16bit cpu

Be serious. If I want a fast program, I'll get a PC. The advantage offered by the opcodes, if any, is probably one to two cycles, as in most cases, the overall number of cycles also increase. And no, using the documented instructions does not lead to "bloated code", just to "good engineering practise".

[Bryan]

Most of them are completely stable because they rely on the mechanisms of other opcodes. In other words, a change to the 6502 core would be needed to break them. A few of them aren't stable because they rely on things like the state of floating busses within the CPU and may not always read the same way under all conditions. Anyway, I think they make sense if you can't accomplish what you want any other way, such as when you need maximum speed from demo code or if you're trying to make the smallest possible routine.

 

If you do use them, you should probably test the CPU type and display a warning if possible.

[xxl]

I've seen here some "believed to be stable" opcodes that do not work on my XL.

 

 

wchich one? Could you take a picture of your motherboard and processor?

 

 

That said, due to timing or production differences, you cannot be sure that they function identically from machine to machine.

 

These commands are in the "unstable" group :-)

 

b) even if, you do not know whether the machine was extended or equipped with a 65C02 or some successor processor.

 

cmos version (65c02 & 65c816) even in documented codes are not 100% compatible with 6502c (Sally)...

Edited August 17, 2013 by xxl

[+bob1200xl]

What??

 

Which 6502C instruction is not 100% compatible on a 65816?

 

65816s are available on the 8-bit, with more to come. Writing code that will certainly break on a 65816 is no different than jumping into the OS routines on a 400/800, deleting the PBI code in an XL/XE system, or using bit 6 of $D301 as some kind of flag. All of these things will cause conditional crashes on new hardware.

 

Do me (and the rest of the Atari community) a favor. If you are writing such code, mark your software with a warning label so we won't waste our time trying to figure out what is breaking your software.

 

Bob

[Nukey Shay]

You're saying that NONE of them are useful. We get it already.

[Bryan]

What??

 

Which 6502C instruction is not 100% compatible on a 65816?

 

There are some differences. I'd say they're compatible under most circumstances...

 

http://www.6502.org/tutorials/65c02opcodes.html

[xxl]

furthermore 6502c (Sally) is NMOS so in read-modify-write codes do "false" write, 65816 in this case do "false" read - eg. in some cases use inc irqen do not work on 65816 but on atari work just fine. on 65816 in this case you need use about 4 commands.

 

 

 

 

If you are writing such code, mark your software with a warning label

 

"WARNING! this software works on Atari" - is this enought for you?

 

so if you replace part of atari with almost compatybile chips you got machine almost compatybile with atari

[thorfdbg]

wchich one? Could you take a picture of your motherboard and processor?

Has already been discussed in the acid test thread. You'll find a picture there, too. There's nothing special about the model. It is an early 800XL PAL version with a Sally CPU.

 

These commands are in the "unstable" group :-)

How do you know that something is in the unstable group? It's not that there is any official documentation about them. IOW, you're depending on your luck that the production masks haven't changed, but nothing else. That's "bad engineering practise".

[thorfdbg]

"WARNING! this software works on Atari" - is this enought for you?

No, because the term is loosely defined. Is an Atari with a 65C02 an Atari? Certainly so, and well-written software will continue to work. Which includes most if not all software I'm aware of, and certainly the type of software I have written. Atari made changes to the ROMs (various versions) to the wiring (PIA port B), to the chips (GTIA vs. CTIA) and so on. So there is nothing wrong with a 65C02 per se as it satisfies the same interface MOS/Synertek defined. There is a document that describes what the CPU can do, and if you depend on anything else, I just hope that I don't have to use your software anytime soon

[xxl]

Has already been discussed in the acid test thread. You'll find a picture there, too. There's nothing special about the model. It is an early 800XL PAL version with a Sally CPU.

 

you mean this: "Unfortunately, I've currently no access to my 8-bit" ( http://atariage.com/...75#entry2702415 )

which opcode? pictures of mainboard and cpu may help find the same config and perform more tests :-)

 

 

> my 130XE, after few hours of continuous running, stops passing the "CPU: Illegal instructions" test

 

I think it's "SHA". I reported to remove it from Acid test because on some atari change modus operandi - depends of ??? temperature ???

SHA is "unstable" - works only on some atari.

 

 

 

Is an Atari with a 65C02 an Atari? Certainly so.

 

Certainly Atari with 65C02 :-) cmos 65c02 is enough compatible to fool some users that it's the same :-)

 

 

Atari made changes to the ... to the chips (GTIA vs. CTIA) and so on.

 

therefore you suggest not to use GTIA modes (16c) because it will not work at CTIA? hehe

I suggest to use full power of documented & undocumented features of Atari computer. it's ok until program works on standard atari.

[thorfdbg]

you mean this: "Unfortunately, I've currently no access to my 8-bit" ( http://atariage.com/...75#entry2702415 )

which opcode? pictures of mainboard and cpu may help find the same config and perform more tests :-)

Scroll further. You'll find an image. I uploaded one.

 

therefore you suggest not to use GTIA modes (16c) because it will not work at CTIA? hehe

I suggest to use full power of documented & undocumented features of Atari computer. it's ok until program works on standard atari.

Except that Atari documented what the register does, did not before and what the extra bits do. That's not the case here. What the instructions do was left undocumented, and for good reason. What happens there is rather a side-effect of the internal CPU design and not part of a documented interface. You do understand the difference between "documented change" and "undocumented side effect", do you?