I'm all in with dropping the bit-fiddling instructions. Dropping column 2 seems sound too, if there's some advantage to be had from the tradeoff.

One point often missed: a slight decrease in instruction set efficiency or interrupt latency (as measured by cycle count) may well be more than offset by a higher clock rate. We're so used to cycle-counting at 1MHz that we sometimes miss the impact of going up to 50MHz (or even just 14MHz)

Cheers
Ed

Thanks, all, for the discussion and links.

I guess I will just bite the proverbial bullet and implement all of WDC's 65c02 opcodes. That way I don't have to "worry" about it. I was just hoping to free up some single-byte opcode space and...those Branch if Bit Set/Reset instructions just don't have the same flavor of the rest of the instruction set; they seem an obvious tack-on by WDC or Rockwell or whomever.

Anyhoo, this project is just for my edumacation [sic] and not towards the end of being fit for any particular purpose.

_________________
Thanks for playing.
-- Lord Steve

I would just implement the basic 65C02 extra opcodes (i.e. STZ, PHX, PHY, PLX, PLY, INC A, DEC A, TSB, TRB, the addtional BIT addressing modes, BRA, JMP (ind,X), and the non-indexed indirect addressing mode. The additional ones available on the Rockwell variants and the WDC W65C02S (i.e. RMB, SMB, BBR and BBS) take up a lot of opcode space, and I don't think were so widely used.

I agree with RichTW and others that the instructions for the original 65C02 are the best. I only added four Rockwell instructions and two WDC instructions (WAI and STP) after getting all of the original instructions working first, and then only to be compatible with the current 65C02 processor from WDC.

The Rockwell instructions are not particularly difficult to implement, but I did shoe horn them into my implementation. WAI and STP are also not particularly difficult to add. Neither WAI nor STP are easily tested with a functional test program such as Klaus', but some simple test logic in your FPGA should suffice.

Note that eliminating column 2 instructions, as BigEd refers to them as, you will also eliminate the LDX #imm instruction. I think that all of the original 65C02 instructions are useful and should be implemented. I can't provide any data on the utilization ratios of any instruction. I've looked and have found no published studies on the average usage rates for the various 6502/65C02 instructions.

Garth pointed me to the datasheet for the 65SC02. In the datasheet there's a table that tabulates the differences between the NMOS 6502 and the 65SC02. I reconstructed the table in the spreadsheet to which I provide you a link earlier. I've printed it out and attached it below. It's one of the few places that explains how many bytes and processor cycles are used by the unimplemented opcodes of the 65C02.

From your comment regarding finding enough single byte opcode space, I imagine that you are looking to extend your core with specific instructions. The table shown below indicates that the opcodes 03...F3, 07...F7, 0B...FB, and 0F...FF are all treated as single byte, single cycle NOPs. Eliminating the 32 opcodes used by the four Rockwell instructions will give you 32 single byte opcodes.

Although, I've not taken the time to implement the necessary changes yet, I think that the '816 stack relative mode implemented using 03...F3 is also a good extension to include. I will likely tack those instructions on to the instruction set of my 65C02 core in the near future, and pull the Rockwell instructions out.

_________________
Michael A.

(oops - I'd not want to lose LDX #imm, of course. Perhaps it could be relocated)

All,
I will consider omitting BBS, BBR, RMB, SMB, but they appear easy to implement and my plan allows for more opcode space via prefix bytes anyway.

MichaelM,
Thanks for the attachment. Do you have a Verilog core of your own?

_________________
Thanks for playing.
-- Lord Steve

Yes, but don't let that dissuade you from your effort to create your own core.

There are several of us on the forum with Verilog cores for the 6502. The designers have all had different approaches, so each core stands on its own. The core from Arlet has been extended by BigEd and ElEctric_EyE (EEye) into a 16-bit core: 65Org16. The 16-bit 65Org16 core is being actively used by EEyE in his video projects which you can read about in the Programmable Logic topic area. Arlet's core is also being used by enso on his CHOCHI development board. Rob Finch also has a core, and it appears that he's extending that work and creating a 32-bit version of the 6502. fpga_is_funny also has a 6502 and and a 65C02 core.

There are several others on the forum that have 6502 cores using that other language whose name I just can't seem to remember. fachat comes to mind with his 65k project.

_________________
Michael A.

I've got the feeling 'fpga_is_funny' == Jens Gutschmidt? Creator of a cycle accurate 6502 core on Opencores.org.

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

_________________
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?

Have you considered the choices made in the 65EL02 design? Having an added R-stack in address $0200 and the instructions to use it makes it apparently particularly suited for FORTH.

_________________
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 "EL" in 65EL02 refers to Eloraam whi made the processor as a virtual computer in Minecraft. Her blog has a lot of information: http://www.eloraam.com/

More technical information on the system: http://integratedredstone.wikispaces.co ... er+Control

65EL02 overview: http://integratedredstone.wikispaces.com/65EL02
The instruction set, highlighting her extensions in yellow: http://www.eloraam.com/nonwp/redcpu.php