Pervasiveness of 65c02 instruction set versus the original.

[BigEd]

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

[lordsteve]

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.

[RichTW]

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.

[MichaelM]

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.

Comparison of NMOS 6502, 65SC02, and M65C02. Partially reproduced from the 65SC02 datasheet.

[BigEd]

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

[lordsteve]

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?

[MichaelM]

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.

[ElEctric_EyE]

MichaelM wrote:

...fpga_is_funny also has a 6502 and and a 65C02 core...

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

[GARTHWILSON]

SMB, RMB, BBS, and BBR are mainly for I/O. If we make our own I/O ICs (which I suspect is much easier than making a microprocessor), the bit instructions can be integrated into the address of store instructions, since we typically have a lot more address space alloted for I/O than it needs, which we do to simplify address decoding. Obviously the I/O IC will need more address input bits. Example possibilities:

Code: Select all

    STA  PA              ; Port A output bits take on the value the processor puts on the data bus.
    STA  PA + %00000001  ; Port A disregards the data bus and sets bit 0 in the output registers.
    STA  PA + %00000100  ;  "   "     "       "   "    "   "   "    "  2 "   "    "        "
    STA  PA + %00000101  ;  "   "     "       "   "    "   "   "   both bits 0 and 2 in the output registers.
        <etc.>

    LDA  PA              ; Port A's value is put on the bus and read normally.
    LDA  PA + $100       ; PA<0> is put on bit 7 of the data bus for subsequent BPL/BMI.
    LDA  PA + $101       ; PA<1> "   "  "   "  " "   "   "    "   "      "       "   "
    LDA  PA + $102       ; PA<2> "   "  "   "  " "   "   "    "   "      "       "   "
        <etc.>

It wouldn't have to be done exactly this way, and more could be done with it too, but it gives the idea. The LDA's above could be replaced with BIT or LDX or LDY if we don't want to alter A, because what we're really after is to branch on the flags without having to first load A for a BIT instruction or AND-out the bits we're not testing. The bit-test-and-branch part is not quite as slick as the BBS and BBR instructions, but accomplishes most of the purpose without taking the space in the instruction table or adding the complexity to the processor itself. Indexing could be used to choose a bit we want to alter or test, so the same op code can be used for different ones, unlike SMB, RMB, BBS, and BBR.

[Alienthe]

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.

[GARTHWILSON]

Alienthe wrote:

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.

What is the 65EL02? I've never heard of it. ZP works great for Forth's data stack on the '02 though because of the extra addressing modes, and the hardware stack (page 1) works great for Forth's return stack. It's almost like it was planned that way.

[Alienthe]

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