The 65c02 adds new mnemonics and addressing modes to the instruction set of the original NMOS 6502. The Western Design Center's datasheet for their 65c02 has a nice opcode matrix (on page 22) here: http://www.westerndesigncenter.com/wdc/documentation/w65c02s.pdf.

I am considering a Verilog FPGA project concerning a 32-bit, instruction-set-enhanced 6502, but I am not interested in all the new instructions.

I am not concerned with BBRn, BBSn, RMBn, SMBn, STZ, TSB, TRB, or the zero page addressing mode additions (see column 2 of the opcode matrix) unless they are very pervasive in 6502 software. Also how useful are WAI, STP, and BRA?

So, can anyone tell me what cross section of the 65c02 opcodes/mnemonics are considered "canon" for 6502 software? What are the "must have" opcodes?

Me love you long time.

_________________
Thanks for playing.
-- Lord Steve

Neill Parker has a very good opcode matrix that describes the differences between the various versions of the 6502. I used his matrix to define the opcodes that I would implement for my core. You can find his matrix here.

I have also created an Excel spreadsheet with the various opcodes mapped to the various instruction sets for the original 6502, the original 65C02, and the Rockwell 65C02. You can find it here. On the M65C02 tab, the opcodes in black are for the NMOS 6502, the opcodes in red are for the original WDC 65C02, and the opcodes in blue are for the Rockwell 65C02. The PDF is for the WDC 65C02, and only shows the NMOS 6502 (black) and original 65C02 opcodes (red).

You appear to be interested in only the opcodes in the black font shown in either of these two documents.

The original 65C02 by WDC is sometimes referred to as the 65SC02. Garth has placed a copy of the datasheet for this processor here.

Hope this helps.

_________________
Michael A.

Hi, MichaelM.

I want to do the 65c02 opcodes if they are heavily used in the 6502 software "repertoire". So, that's why I was wondering if I REALLY need to do, say, TRB, TSB, WAI, STZ, et al.

I remember seeing that Neill Parker page sometime back. I like the breakdown of the bit patterns. Thanks for the links!

_________________
Thanks for playing.
-- Lord Steve

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

The functionality lost by not implementing those instructions will be made up for in the 32-bit (orthogonal) extension to the instruction set. Plus, it would free those locations in the opcode map.

So, do those 65c02 instructions permeate most of 6502 software? That is what I would like to know. What is the distribution of the 65c02-only opcodes across the domain of 6502 software?

Thanks!

_________________
Thanks for playing.
-- Lord Steve

_________________
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 6502/65C02 instruction set hits the 'sweet spot' of the retro period. It's not great for compiling C or Forth, but is surprisingly satisfying. ARM instruction set is much more straightforward and regular, but for me it leaves an unpleasant taste in my mouth; 68K was more pleasant...

One of the joys of 6502 is the incredible compactness of code, and its surprising speed of execution.

I am somewhat suspicious of 32-bit versions... It's tempting to add registers which then must be constantly pushed and pulled to/from the stack, and the spirit of 6502 vanishes. 16 bits is probably plenty for most applications; fixed point can be better than floating point in many cases. I'd be more interested in adding instructions to support Forth, a larger stack space, and a larger memory space while keeping closer to 6502 (accumulator and a couple of index registers). 6809 seems to be more in the right direction than a full-blown 16-register 32-bit processor with a vague resemblance to the 6502.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Huh? Not the 65Org16.b. Extra accumulators/registers are awesome IMO, for a 6502 CPU like construct.
I would suspect also, that a 32-bit version would take a more full advantage of an Xilinx Spartan 6 FPGA without sacrificing a thing, compared to 16-bits.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

32 bit takes up a lot of room, though, both in your data path and program space. Impact on speed is less, although things like 32 bit ripple carry take a bit more time, as does increased routing congestion.

Things in the critical path often taken for granted like setting the zero flag also require wide logic, and several layers of luts.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Yes, the zero flag is a good one.

Is this because the Zero flag would have to be 1-bit wider than the data path?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

It's because it requires a 32-input OR to determine value of the Z flag. This requires 2 levels of logic on a Spartan-6. On a Spartan-3 it requires 3 levels of logic, because the LUTs only have 4 inputs.

Maybe I was thinking of the N flag, for BMI and BPL opcodes.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

For the C flag you need the carry out from the adder, and also for the V flag, because it requires C.

But the Z flag is the biggest/slowest to calculate.