6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: Michael J. Mahon on 11 May 2006 22:21 mdj wrote: > John Selck wrote: > > >>Some illegals are quite useful, like SHX/SHY which in some cases can be >>used as STX absolute,Y / STY absolute,X if you use the right. Also you >>can do a CPU test and use different code on different CPUs. The demo >>"Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on >>65816 it uses a slower but illegal-free code. > > > This is reasonable on the C64 where all machines were fitted with > 6502's, and in the case of a 65816 it's accelerated, so a slower code > section is acceptable. > > The Apple II series is essentially 3 platforms, and 3 CPU generations, > all backwards compatible. > > I'll concede there is a potential fringe case where a piece of code was > so tight that downconverting from 65C02 to 6502 broke it, and it was > fixable using an undocumented instruction. Damned if I can think of an > example though; there's almost always another way to find a cycle or > two. And in any case, depending on the peculiarities of a particular chip implementation is just asking to be locked out of future improvements. -michael Music synthesis for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: Bruce Tomlin on 12 May 2006 10:01 In article <1147397570.212608.111710(a)i40g2000cwc.googlegroups.com>, "mdj" <mdj.mdj(a)gmail.com> wrote: > John Selck wrote: > > > Some illegals are quite useful, like SHX/SHY which in some cases can be > > used as STX absolute,Y / STY absolute,X if you use the right. Also you > > can do a CPU test and use different code on different CPUs. The demo > > "Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on > > 65816 it uses a slower but illegal-free code. > > This is reasonable on the C64 where all machines were fitted with > 6502's, and in the case of a 65816 it's accelerated, so a slower code > section is acceptable. > > The Apple II series is essentially 3 platforms, and 3 CPU generations, > all backwards compatible. And of course you've neglected to mention the other major 6502 computer series of the era, Atari. They never used anything but a standard 6502 core (but with an extra pin added to make DMA easier), so the 65C02 and 65816 were never an issue. In fact, Atari's 6502C with the extra signal meant that you _couldn't_ just drop a 65C02 into the same socket. This was even less of an issue on the 2600, which always used a 6507, which is a standard 6502 die in a reduced pin count package. Quite a few games used illegal opcodes to reduce cycle count so that they could do things that were otherwise impossible with its clock-locked 1-D graphics chip. Oddly enough, the Apple II is where I heard most about people using illegal opcodes and side effects like JSR ($xxFF) back in the day, as a way to obfuscate copy-protection code. Like I cared, because I had a TRS-80 (then a CoCo, and a 128K Mac), and most of the Z-80 undocumented opcodes were obvious, even when they weren't useful. And none of the 6809 undocumented opcodes were useful at all, except there was one that would do an SWI (equivalent to 6502 BRK) through the FIRQ vector and another that would jump through the RESET vector.
From: Michael J. Mahon on 12 May 2006 20:44 Bruce Tomlin wrote: > In article <1147397570.212608.111710(a)i40g2000cwc.googlegroups.com>, > "mdj" <mdj.mdj(a)gmail.com> wrote: > > >>John Selck wrote: >> >> >>>Some illegals are quite useful, like SHX/SHY which in some cases can be >>>used as STX absolute,Y / STY absolute,X if you use the right. Also you >>>can do a CPU test and use different code on different CPUs. The demo >>>"Oneder/Oxyron" does this. It works on 6502 with illegal opcodes, and on >>>65816 it uses a slower but illegal-free code. >> >>This is reasonable on the C64 where all machines were fitted with >>6502's, and in the case of a 65816 it's accelerated, so a slower code >>section is acceptable. >> >>The Apple II series is essentially 3 platforms, and 3 CPU generations, >>all backwards compatible. > > > And of course you've neglected to mention the other major 6502 computer > series of the era, Atari. They never used anything but a standard 6502 > core (but with an extra pin added to make DMA easier), so the 65C02 and > 65816 were never an issue. In fact, Atari's 6502C with the extra signal > meant that you _couldn't_ just drop a 65C02 into the same socket. That was DMA for video RAM acces, right? If so, they just didn't get how trivial it is to share RAM with a 6502--it only accesses RAM during half the clock signal! > This was even less of an issue on the 2600, which always used a 6507, > which is a standard 6502 die in a reduced pin count package. Quite a > few games used illegal opcodes to reduce cycle count so that they could > do things that were otherwise impossible with its clock-locked 1-D > graphics chip. It's kind of a self-fulfilling prophecy. If enough people write applications that depend on undocumented behavior, then that behavior becomes a "feature" that cannot be changed in future versions--usually preventing useful improvements. (Not that I think of the 65C02 as much of an improvement. All the changes made in the 65C02 were what is known technically in the computer architecture community as "mouse nuts". ;-) > Oddly enough, the Apple II is where I heard most about people using > illegal opcodes and side effects like JSR ($xxFF) back in the day, as a > way to obfuscate copy-protection code. Like I cared, because I had a > TRS-80 (then a CoCo, and a 128K Mac), and most of the Z-80 undocumented > opcodes were obvious, even when they weren't useful. And none of the > 6809 undocumented opcodes were useful at all, except there was one that > would do an SWI (equivalent to 6502 BRK) through the FIRQ vector and > another that would jump through the RESET vector. There were a few cases of using undocumented behavior to obfuscate, but it was never much more than a curiosity on the Apple II platform. -michael Music synthesis for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused."
From: heuser.marcus on 13 May 2006 01:28 > It's kind of a self-fulfilling prophecy. If enough people write applications > that depend on undocumented behavior, then that behavior becomes > a "feature" that cannot be changed in future versions--usually > preventing useful improvements. IMHO Atari didn't even seriously consider replacing the 6502. The 8-bit platform was virtually unchanged for ten years. The machines were cash cows and the Tramiel-aera Atari concentrated in making them cheaper and cheaper (to compete with Commodore and reach the Eastern Europe market) - so there was small room to get innovative. The case with the 2600 is even clearer IMHO: It used the cheaper 6507 and the video game market crash in 1983 did the rest. I really don't think that Atari even had the telephone number of WDC... > (Not that I think of the 65C02 as much of an improvement. All the > changes made in the 65C02 were what is known technically in the > computer architecture community as "mouse nuts". ;-) Ha ha - now that's a technical term I can learn quickly! bye Marcus
From: Bruce Tomlin on 13 May 2006 10:56
In article <b_2dnVaBwopOtvjZRVn-uQ(a)comcast.com>, "Michael J. Mahon" <mjmahon(a)aol.com> wrote: > That was DMA for video RAM acces, right? If so, they just didn't get > how trivial it is to share RAM with a 6502--it only accesses RAM during > half the clock signal! As I understand it, they actually halted the CPU for DMA so as to get more memory bandwidth than "half the clock signal", and they needed to know when the CPU had actually stopped so that they could start DMA. This was also done on the Atari 7800. I've heard that in the original 400/800 they actually used a regluar 6502, but the extra signal allowed them to save all the external circuitry that figured this out. Again, I grew up on the TRS-80, so all of this is stuff that I've learned about the old Atari hardware in the past five years or so. |