65C02 in verilog - extended version of Arlet's core

[BigEd]

Dave [hoglet] and I are pleased to announce the successful enhancement of Arlet's (small, fast) 6502 core to include all the normal 65C02 operations:

Quote:

additional 65C02 instructions and addressing modes:
- PHX, PHY, PLX, PLY
- BRA
- INC A, DEC A
- (zp) addressing mode
- STZ
- BIT zpx, absx, imm
- TSB/TRB
- JMP (,X)
- NOPs (optional)
- 65C02 BCD N/Z flags (optional, disabled)

The Rockwell/WDC specific instructions (RMB/SMB/BBR/BBS/WAI/STP) are not currently implemented

The 65C02 core passes Klaus Dormann's 6502 test suite, and also passes the 65C02 test suite if the optional support for NOPs and 65C02 BCD flags is enabled.

It has been tested as a BBC Micro "Matchbox" 65C02 Co Processor, in a XC6SLX9-2 FPGA, running at 80MHz using 64KB of internel block RAM. It
just meets timing at 80MHz in this environment. It successfully runs BBC Basic IV and Tube Elite.

It's not a lot bigger - about 10% - and not any slower - about 80MHz in our tests. But note that speed depends on which FPGA you choose and how you drive the tools, and what other bits you have in the design in addition to the CPU.

Here's the source:
https://github.com/hoglet67/verilog-6502

For compatibility the original core is still found in cpu.v and the new core is cpu_65c02.v

It was particularly satisfying, and a testament to Arlet's original implementation, that we were able to make successive simple changes to implement each type of new instruction incrementally. Although it looked like we might, it turned out we didn't even need to change the ALU.

(It's probably worth noting that there other HDL implementations of 65C02 - see the Homebuilt Projects section of the site, at http://6502.org/homebuilt#HDL
T65
cpu65c02_true_cycle
M65C02
R65C02
)

[Arlet]

Good job! I'm pleasantly surprised that only so few additional resources were needed.

[BigEd]

We were too - thanks for the excellent starting point!

[hoglet]

Hi Arlet,

Arlet wrote:

Good job! I'm pleasantly surprised that only so few additional resources were needed.

I also found it a great way to learn about your core.

On a slightly different topic, we did have problems using RDY to insert an additional wait state for ROM accesses.

You mentioned in this post that possibly this was an issue you were aware of:
https://github.com/Arlet/verilog-6502/i ... -136378964

After drawing a few timing diagrams, it seemed to be one superfluous level of pipelining in RDY1 that was causing the problem.

The fix was to update the DIHOLD logic from:

Code: Select all

reg RDY1 = 1;

always @(posedge clk )
    RDY1 <= RDY;

always @(posedge clk )
    if( ~RDY && RDY1 )
        DIHOLD <= DI;

assign DIMUX = ~RDY1 ? DIHOLD : DI;

to:

Code: Select all

always @(posedge clk )
    if( RDY )
        DIHOLD <= DI;
 
assign DIMUX = ~RDY ? DIHOLD : DI;

I wonder when you have a moment if you could have a think about this, and whether it's the right solution.

Dave

[Dr Jefyll]

Congratulations to all three of you!

[cbmeeks]

Awesome work!

[rwiker]

cbmeeks wrote:

Awesome work!

Indeed - and maybe that's what's needed for me to finally start playing with FPGAs. I have two of Enso's CHOCHI boards, and "upgrading" these may a simple starter task for me

[Arlet]

As an alternative idea, the STZ instruction and the (ZP) addressing mode could be implemented by adding a 'Z' register in the register file which is always zero. Not sure if that will be smaller or not, but may be worth a try.

[Arlet]

I just realized your 65C02 core does not add the extra cycle in decimal mode for ADC/SBC. It may be worthwhile to look into a modification that adds this cycle, not only for cycle accuracy, but also for performance.

Currently, the longest path in the design goes through the ALU, and the inclusion of the BCD logic is causing an extra slowdown, which is a shame for a feature that's rarely used.

To speed up the main path, we could remove all BCD logic from the ALU. In order to support decimal mode, we would add a parallel block that just does decimal add/subtract, using an extra register stage to keep it fast. It could even use some of the outputs from the regular ALU.

[BigEd]

That's a nice idea Arlet, thanks.

As it happens, in the present incarnation on an LX9 with all 64k of block RAM in play, it seems to be routing delays and address generation/decode which are dominant. Dave got close, I think, to 80MHz but pulled back to 64MHz. There's a fair chance this could be improved, with some effort. It's interesting that off-core functionality became the limiting factor.

[Arlet]

Keep in mind that the read data from your memory goes through muxes, into the DI port of the core, through the ALU, into the ADD register, all in the same cycle. Improving the ALU may reduce routing pressure on nearby areas.

I assume this is your 64kB memory ? You may be able to add an optimization in the form of a reset input that produces all-zero output. The Xilinx block RAMs have that input, so it doesn't cost any extra resources. Using the all-zero output, you can use an OR instead of a MUX. You can usually do the same thing with peripheral blocks (generate zero when not selected) for little to no extra cost.

[Arlet]

A simple first test would be to rip out the BCD logic, and see if there's any improvement in speed.

[BigEd]

Thanks - two good ideas there, to use OR-muxing and to try without BCD logic. Will see what we find.

[Braincell1973]

Will this work on grant searles multicomp ??

[BigEd]

Braincell1973 wrote:

Will this work on grant searles multicomp ??

I see the MultiComp uses the T65. While surely possible, it might take a little effort to interface Arlet's core, which is built primarily for synchronous memory. Another choice would be Alan Daly's work - see
viewtopic.php?p=19187#p19187