6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: Anders Carlsson on 18 May 2006 16:21 "John Selck" <gpjiweg(a)t-online.de> writes: > STA $12 > TXA > STA $FE00,Y > TAX > LDA $12 > SBC $10 > BCS .skip > ADC $11 > INX > .skip I don't know the circumstances, but why the TAX? -- Anders Carlsson
From: John Selck on 18 May 2006 16:23 Am 18.05.2006, 10:22 Uhr, schrieb Michael J. Mahon <mjmahon(a)aol.com>: > I admit that I don't have a quantitative estimate of the number of > transistors (PLA terms) required to protect at least most of the > unused opcode space, but I suspect it would not be more than a few > hundred (out of about 3700 in the 6502). And you think people would waste a few hundred just for that? Also, you have propably noticed the lack of space on the cpu... If they had space for a few hundred more transistors, they would rather have added another adressing mode or opcodes like PLX/PHX or TXY etc, but not NOP'ing out the illegals. Btw, also x86 CPUs have undocumented opcodes aswell... and programs do use them.
From: John Selck on 18 May 2006 16:30 Am 18.05.2006, 22:21 Uhr, schrieb Anders Carlsson <anders.carlsson(a)sfks.se>: > "John Selck" <gpjiweg(a)t-online.de> writes: > >> STA $12 >> TXA >> STA $FE00,Y >> TAX >> LDA $12 >> SBC $10 >> BCS .skip >> ADC $11 >> INX >> .skip > > I don't know the circumstances, but why the TAX? Just drop it... Best case: 19 vs 11 clock cycles (1.73x speed) Worst case: 23 vs 15 clock cycles (1.53x speed) Fact remains: illegals can make a difference on certain tasks.
From: mdj on 19 May 2006 00:19 Michael J. Mahon wrote: > Errata are always a special case. The designers always hope that code > that runs correctly on the original, buggy processor will still run > correctly on a fixed processor. In other words, they hope that no > one has written code that *depends* on buggy behavior. > > To summarize, code written to the specifications of a processor will > work correctly on all implementations, *except* where an implementation > is faulty. Code written to work around a fault can still be written > to the specifications, but avoiding the faulty case(s). A classic example of this from the real 6502, is the Indirect Absolute JMP bug. It's trivial, once you know it's there to work around it. But if you pick a workaround that exploits the bug, your code won't work on any of the later parts. Did anyone actually do this? I certainly hope not Matt
From: mdj on 19 May 2006 00:28
John Selck wrote: > Best case: 21 vs 11 clock cycles (almost 2x speed with illegal) > Worst case: 25 vs 15 clock cycles (still 1.67x speed) Nice... It would be amusing to see a game title on the Apple II+ running faster than on the IIe :-) Of course, the point remains though that your would never do this on the Apple II series, as you'd limit your target market to the earliest machine, rather than just the lowest common denominator of all machines (64k, 6502 code that's documented and unbuggy) If I were coding on a different 6502 platform, I might consider using these. But then, I'm very much a 65C02 coder these days, as pretty much everything I write is intended for a IIe/IIc and wouldn't run on an older Apple II anyway. Michael will probably shoot me down for saying this, but when I mean BRA, I write BRA. It's clearer code, and I really wish that anyone who writes code specifically for the earlier processors would comment their unconditional branches accordingly. But then I'm also pretty carefree about not bumping into the old 6502 bugs either ;-) Matt |