From: Anders Carlsson on 18 May 2006 16:21
"John Selck" <gpjiweg(a)t-online.de> writes:
> STA $12
> STA $FE00,Y
> LDA $12
> SBC $10
> BCS .skip
> ADC $11
I don't know the circumstances, but why the TAX?
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
> "John Selck" <gpjiweg(a)t-online.de> writes:
>> STA $12
>> STA $FE00,Y
>> LDA $12
>> SBC $10
>> BCS .skip
>> ADC $11
> 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
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
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 ;-)