Not long ago in a town not unlike yours....

A 6502 was replaced with a 65C02. Things look good until a game was loaded, whereupon it fell over unceremoniously. I hadn't considered it an issue at the time of replacement but there are obviously to me now (but not then) good reasons why this wouldn't necessarily work.

I'm still very much a Newby when it comes to getting down to the nitty gritty of the 6502 and it's brothers so my educational question is:-

What's the least obvious incompatibility between the 6502 and the W65C02?

The behavior of the undocumented instruction opcodes of the 6502.

Some of the unused opcodes can actually perform useful operations for the 6502 programmer. The way the 65C02 expanded the instruction set, meant that some of the undocumented instructions were used, and the behavior of the remainder was modified so that no side effects on the registers (A, X, Y, S, and P) were allowed. This eliminated all of the undocumented behaviors of the 6502 from the 65C02.

_________________
Michael A.

Now that's the one that bit me as far as I could tell then. It's also the one that inspired the topical title.

For educational purposes I suggest you study Table 7-1 of the datasheet for the WDC 'C02. Bear in mind that not all differences are incompatibilities.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Extra points for any differences not noted in that table! (It's on page 30)
Funny how they also tabulate some non-differences - perhaps means they once had other plans.

We did discuss one CMOS part which pushes the PC and status byte to the stack during reset, which the NMOS part doesn't:
viewtopic.php?f=4&t=2967
(But it seems the WDC part does not push values during reset: viewtopic.php?p=33327#p33327)

I see both behavioural AND timing differences in table 7-1. I know some copy protection systems used in old games would have decrypted the code incorrectly if the timings weren't cycle perfect so there's an Un - obvious one right there. The thing with BRK and interrupts is intriguing. I still get the impression there's a juicy nugget for me to find mind.

What about differences incorrectly noted in that table?

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Good catch, as ever!

(We linked to a number of copy protection system discussions in our G+ post "copy protection on the 6502" - should be interesting reading if you like that sort of thing.)

Edit: fix link rot

Just looked at the incorrectly documented timing mentioned. That's goOOOod. Never would've spotted that in the life of this thread without making a mission of it or coming a cropper. That said I suppose I could have fired up the logic analyser and just played till something showed it's head.

I seem to recall that way back when the NMOS 6502 was current production and multiple sources were producing them to keep up with the demand, it was discovered that some unsupported opcodes behaved differently depending on whose version of the 6502 was in use. Much of the information about what unsupported opcodes did was based upon experimentation with the genuine MOS Technology (later, Commodore Semiconductor Group) 6502. As the "illegal" opcodes were officially unsupported, other 6502 vendors were not obliged to make their 6502s behave exactly like MOS/CSG 6502s when an unsupported opcode was encountered in a program. It's the usual caveat emptor...

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

From a wider (engineering) perspective it's clear that it was poor practice to use the undocumented instructions - on the other hand, game code is necessarily very platform specific, is expected to have a short life, and squeezing size or performance can be very important. So it's not too surprising what we find. It would be nice to think that the modern 6502 enthusiast can appreciate the wider perspective, even though their interests might be narrow enough that undocumented instructions are still something they want to use.

Amstrad's machines very deliberately pulled the rug from underneath developers who called direct into the ROM, by moving things around, unapologetically. In principle that left Amstrad free to improve their implementations so long as they preserved the official interface.

Commodore did the same thing and made sure programmers knew it by relentlessly telling them to utilize the "kernal" jump table to call ROM routines. The jump table was stable from inception to the final days of eight bit Commodore production, but the routines themselves were frequently relocated as new ROM revisions were developed. If new routines were added, as was the case when the C-128 went into production, their entry points were tacked on to the bottom end of the jump table so none of the previous table entries were relocated. Hence, for example, a call to BSOUT was guaranteed to work no matter which machine was in use, as BSOUT was always at $FFD2 and maintained the same parameter requirements in all cases.

Prior to the C-128, no Commodore machine had a BASIC ROM jump table, so it was every man for himself when it came to utilizing BASIC subroutines from within user-written assembly language programs, e.g., calling the floating point math functions. The C-128 had a formal BASIC jump table which was fully documented, but was tricky to use due to memory mapping acrobatics. The C-128's resident M/L monitor also had a formal jump table.

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

Acorn made a valiant effort to guarantee a solid programming environment by having known jump vectors and defined ways of using them. This was done so that programs would run from across the Tube amongst other reasons. It became apparent to me that I could patch some of these vectors to make my computer generate funny sounds each time A key was pressed. My first assembly language program. I'm not aware of any Acorn firmware using illegal opcodes but the Repton series do (Electron/BBC games I played as a kid).

What of the broken rotate instruction in very early parts?

I was really impressed when I first realised the abstraction offered by Acorn's OS - not only can you run on any machine, you can also run on a coprocessor.

There's a sort of incompatibility between the NES core, which lacks decimal mode support, and any other. On the NES, you could use the D bit as a flag (using PHP and PLP and some bit-twiddling) and that wouldn't work on other cores, in the sense that it would perturb some ADC and SBC actions. I bet this never bit anyone!