Re: 6502 illegal opcodes questions

["Michael J. Mahon" <mjmahon@aol.com>]

Jim Brain wrote:
> Michael J. Mahon wrote:
>
> > Not so.  The logical elements of the NMOS design are not present in
> > the same form in CMOS.  And the instruction decoding was clearly
> > redesigned, as was the control section (changed timings and bus cycle
> > patterns, new instructions).
>
>
> I guess we'll agree to disagree on the point.  I say all the design 
> elements are there (the 8 bit ALU, decimal mode, the 16 bit instruction 
> pointer, etc.)

I was referring to the precharge and transfer gates in the NMOS process.
Different gate designs are preferred in a CMOS process, and so different
circuits.

>  As for the instruction decoding, Bill just cleaned up 
> the don't cares, as I see it.  Hardly a huge new design.  The physical 
> elements changed, yes, but the logical perspective stayed the same. When 
> I interviewed him back in 1995, he said as much.  He simply wanted to 
> clean up the design and lay it out so he could take advantage of not 
> only the CMOS process but the ability to shrink the feature size every 
> so many years.  He hasn;t changed his design since the original.  He 
> just shrinks the design using the newer process and re-fabs.  That's how 
> he stated he got his speed increases.

The term "logical design" when applied to a processor means the
circuit diagram at the level of gates.

If the same circuit design is implemented in a different process,
the processor behavior will be identical, since it is the same
logical design (same signals, flows, timing, etc.).

If the same *architecture* is re-implemented with a new circuit
design, then only the *documented* behavior is likely to be
identical, since everything else is formally a "don't care".

> > That kind of behavior is of a completely different kind than random
> > bus clashes as multiple data sources are unintentionally gated onto
> > a bus!
>
> I'll agree they are different, but the point was that they are both 
> undocumented behavior.  Intel found the undocumented behavior was used 
> all over, so they had to build in support for it.  Therefore, every new 
> Intel CPU supports this "undocumented behavior".  Of course, it is now 
> documented, so it becomes legitimate by virtue of so many people 
> exploiting it that it became the std.

*All* undocumented behavior includes both "well-behaved but
undocumented", "wierd but predictable undocumented behavior",
and "weird and unpredictable undocumented behavior".

The well-behaved stuff obeys the principle of least surprise,
and may be candidates for documentation and full support.

The rest is *never* such a candidate.  ;-)

And for a designer to be "forced" to support previously undocumented
behavior because it is "used all over" is *exactly* the point I've been
trying to make all along--this is *almost always* a bad thing.

The only exception I can think of is when a sensible design behaves
sensibly in some situations that the designer somehow neglected to
document, but should have.  Of course, the only real problem then is
correcting the documentation, since any "reasonable" design will be
likely to support the behavior in any case.

Even in this case, the matter should be broached publicly and an
agreement reached about what part of the originally undocumented
behavior will become documented, and thus sanctioned by the designer
in any future implementations.

> > Long after the 65C02 design was available, lower power, faster, and
> > cheaper to make, the CBM line could not easily make use of it.
>
>
> If it had made economic sense, CBM would have tasked Mensch to add the 
> errata into the C02.  Apple got Bill to change the 816 timings, and CBM 
> had more clout with Bill, since they originally helped set up WDC.

Possibly, but clout is usually dependent on the promise of orders,
not good feelings...  ;-)

If WDC didn't get money from CBM, they wouldn't have much influence.

I'm guessing that CBM just kept turning the crank on their proprietary
6502 implementation(s), and were not motivated to pursue the 65C02.

> But, I'll concede the point that it would have required more cash and 
> time than the Apple II line needed.
>
> I guess, in priciple, I agree with you that undocs fly against the rule 
> of programming.  HOwever, in the CBM environment, the rules are a bit 
> different.  As well, regardless of how one views the use of undocs, I'm 
> not willing to be harsh on the MOS folks for what they did.  They made a 
> $20 CPU and got Woz and the Bushnell interested in using CPUs, which 
> brought all of us to where we are today.  I won't let a few space and 
> time saving details that made perfect since in the early 1970's cloud that.

I don't fault them for what they did, either--I was just pointing out
that we don't do things that way anymore, and for good reason: we
found out by (sad) experience that programmers cannot be trusted
to "keep off the undocumented grass".  ;-)

And I also agree that for any platform with a single, unchanging
implementation, as most retro platforms are today, the use of
stable undocumented behavior is not a practical problem.

My whole point is that it is a *very* bad idea for an evolving
platform, since it can seriously hamper evolution by causing
compatibility breaks.

-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."