Actually, the 65C816 can be described as a 65C02 on steroids. The implementation bugs in the NMOS part, e.g., JMP ($xxFF), are gone. Perversely, the 65C816 manipulates the address bus sort of like the 6502, but provides the signals needed to avoid trouble. The emulation mode is neither 100 percent 6502 or 65C02, and technically speaking, the 65C816 is not a direct replacement for either of the eight bit MPUs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think the 65CE02 better fits that description.

(corrected, thanks Garth)

A seemingly good source for these are the A2232 7-port RS232 cards. They also have a ton of other useful chips. But you have to be willing to cannibalise them, and, for all I know they aren't cheap and plentiful anymore.

I got a couple of 65CE02's (note: not EC, but CE) in the late 1980's IIRC. I tried them as a drop-in replacement on my workbench computer, but they did not work. I did not try to figure out why. The 65CE02 does however have a lot of nice attractions. (Unfortunately availability is not one of them.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The best approach to using the 65C816 is to purpose-design the system to use it. Unlike the 65C02, which (with some minor caveats, which are discussed elsewhere on the forum) is a drop-in replacement for the 6502 part, the 65C816 has significant electrical and software differences from the NMOS part, making drop-in replacement problematic. Also, the 65C816 can in some cases generate spurious address bus conditions during the intermediate stages of instruction execution, which if not properly accounted for in the glue logic, will cause trouble.

Electrically speaking, the big difference between the 6502 and 65C02 is the latter doesn't do "spurious accesses" during intermediate stages of instruction execution. For example, a read-modify-write (R-M-W) instruction using the 6502 will cause a double write on the affected address, the first one writing back the existing data and the second one writing back the changed data. Such behavior can trip up I/O hardware in some cases. R-M-W instructions on the 65C02 only "touch" the affected address once, which is when the modified data is written. Hence use of R-M-W instructions on device registers is not likely to cause trouble (although such programming practice is questionable).

In the 65C816, all 256 opcodes are valid instructions and are valid in both modes. This is in marked contrast to the 6502, in which many opcodes are undefined and either cause strange things to happen or outright fatality, or the 65C02, in which undefined opcodes are effectively NOPs of varying lengths and cycle times (Jeff Laughton, Dr. Jefyll, has documented ways in which to take advantage of undefined opcodes to do all sorts of cool things).

So in reality, the 65C816 is a different MPU, one which happens to know the 6502 machine language, but has a plethora of addressing modes and functions that have no analog in the eight bit MPUs. A 65C816 machine should be designed accordingly to get best results, and the software written for that machine should be developed around the 65C816 assembly language to extract the most performance and functionality.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Precisely why I think (my opinion only) that the 65CE02 better fits the "65C02 on steroids" description than the 65816.