Proper 65C02 core

[Windfall]

Anyone know of a properly working 65C02 core ? Freely available, preferrably Verilog.

So far I tried (opencore's) cpu6502_tc and T65 (65C02 mode). Former seemed to work okay, but goes pear shaped on interrupts (took me half a day to find out, and apparently it's a known bug, and has been for two years ... thanks man !). Latter doesn't seem to work at all for me, even after some creative variations in interfacing, and I don't fancy debugging that one as well, especially as it has no pretenses of completeness, 65C02-wise.

Have looked around quite a bit. Only commercial alternatives. Anything I've missed ? Thanks.

[ElEctric_EyE]

I've looked in the past, like last year, and I've not found any... Were you looking for 100% compatibility? or which opcode additions do you need?

[BigEd]

We catalogued many cores in this thread - there are a couple of late arrivals on the last page but I think the table in the head post is mostly complete. Verilog isn't as popular as VHDL, and I think the full 65C02 instruction set is probably not there, but that's the best list I know of.

Cheers
Ed

Edit to update: MichaelM now has a 65C02 core here (microprogrammed, verilog, no dead cycles) - see below

Much later edit: Alan Daly has extended an existing core to 65C02. See
https://github.com/hoglet67/CoPro6502/b ... R65Cx2.vhd

Even later edit: Dave Banks and I have extended Arlet's core to 65c02. See
viewtopic.php?f=10&t=4224

[Windfall]

ElEctric_EyE wrote:

I've looked in the past, like last year, and I've not found any... Were you looking for 100% compatibility? or which opcode additions do you need?

Just correct execution, i.e. all instructions, interrupt handling. Cycle accuracy, efficiency, etc. don't concern me.

I do fancy writing my own core, very much so, but as a final step, certainly not the first one. Alas, it seems I may have to do it now, iff I want to continue this project. I could fix someone else's core, but that may take days, and I'd rather put that time into writing my own, using my own approach.

[Windfall]

BigEd wrote:

We catalogued many cores in this thread - there are a couple of late arrivals on the last page but I think the table in the head post is mostly complete. Verilog isn't as popular as VHDL, and I think the full 65C02 instruction set is probably not there, but that's the best list I know of.

Thanks, I'll have a look.

[MichaelM]

Hello All:

I apologize but I messed up my email address yesterday when trying to point it to another account and deactivated my account on this forum as a consequence. Therefore, I've re-registered, and the old MichaelA is the new MichaelM. I will still sign any posts as Michael A.

EE threw down the gaunlet, and rightly so, that I should post any code that I may have. Therefore, I have pulled together the source files for my first core which I briefly described yesterday. I have placed a LGPL license header on all of the source files. I was going to release the attached code through OpenCores, but I don't have what I would consider a self-checking testbench for the core, and I've not completed a detailed design description of the core.

I have included all of the testbenches that I used in the development of the core, but the testbench for the ALU is not up to date. In the process of getting the core's microcode working correctly, I made some changes to the ALU which have not been incorporated into its testbench. Prior to integration of the core's components, the ALU testbench was developed as self-checking. For my second core, which is derived from the first, I spent most of this morning getting the ALU testbench in line with the implementation.

I would appreciate it if someone (EE, BigEd, Arlet) would put it into a repository that the members of the forum may access. I will continue improving the documentation for this core because it will apply to both cores that I am working on.

The following is an abbreviated list of the files that I've put into the attached ZIP archive:

M65C02_Core.v - top level file for a WDC 65C02 compatible core
M65C02_MPC.v - Microprogram Controller for the M65C02 variable microprogram (my re-implementation of the F9408 MPC)
M65C05_ALU.v - ALU core for the M65C02 (contains the A, X, Y, S, and P registers and implements the ALU functions and register transfer logic)
M65C02_BIN.v - Binary mode adder for the ALU
M65C02_BCD.v - BCD mode adder for the ALU
M65C05.ucf - User constraints file setting the clock period constraint for PAR and locking the core module ports to I/O pins of an XC3S200-5FT256 FPGA
M65C02.tcl - TCL file with all project settings for the Xilinx ISE 10.1i SP3 Synthesizer, Mapper, and Place and Route tools

M65C02_Decoder_ROM.coe - Memory coefficient file for the fixed portion of the core's microcode (instruction decode - ALU operation control)
M65C02_Decoder_ROM.txt - Source file for M65C02_Decoder_ROM.coe

M65C02_uPgm_V3.coe - Memory coefficient file for the variable portion of the core's microcode (address mode control)
M65C02_uPgm_V3.txt - source file

tb_M65C02_Core.v - Testbench for the top level (Xilinx ISim Lite and/or ModelsimXE-III 6.3c)
M65C02_RAM.v - Synthesizable (not recommended) Distributed RAM (LUT) used by the top level testbench to simulate single cycle program/data RAM
M65C02_Core.xwv - waveform file for the core testbench

M65C02_Tst2.txt - Memory coefficient file for the M65C02 assembly language test program
M65C02_Tst2.a65 - source file
m65c02.bin - binary output file from the Kingswood A65 Assembler
BIN2TXT.exe - Helper function used to create the M65C02_Tst.txt file from the m65c02.bin file
BIN2TXT.c - C source file

1004-0001 W65C02 Design Description.pdf - Incomplete description of the W65C02 processor and its implementation in the M65C02 core: MAM65C02.zip.

Quote:

The orginally provided MAM65C02.zip file has been removed. An update has been made to the files, and a repository has been created on GitHub. Follow this link to download the latest files as a ZIP archive.

This post is getting to be too long, so I'll wrap up by saying that the core supports interrupts in a non-standard manner, and it expects a external interrupt controller to provide the core with an interrupt request and the full 16-bit vector. Thus, the core does not perform an indirect jump through one of the defined vectors of any of the 6502 processors. I make the assumption that it is a core, and that the vectors would normally not be variable, i.e. normally found in ROM. One other note, in the implementation I've provided, the objective is a core performance of 100 MHz in a Xilinx Spartan 3AN part. The core and the ucf achieves that goal, but that level of performance is not what can be achieved in a situation which uses external memory. I used this approach in order to get the microcode debugged. I believe that I've implemented the BCD arithmetic correctly. However, surfing around the web, I am no longer sure that I've correctly determined the overflow flag in the BCD mode. Finally, the BCD mode is implemented in such a manner that BCD mode ADC/SBC instructions stretch the execution cycle by one clock cycle to accomodate the BCD adjustment.

Overall, I am pretty confident that the core executes the WDC W65C02 instructions faithfully. In most cases, the core as implemented saves one clock cycle from most multi-cycle operations. The result is that the core, as implemented, will yield an improvement of approximately 40% for an average W65C02 program. I seem to have misplaced my working notes on this subject, but the Kingswood assembler can be made to output the expected number of clock cycles for each instruction, and that can be compared to the actual cycles that the core uses for each instruction.

I hope that the core I've attached will be useful to some of the forum members.

[ElEctric_EyE]

Welcome back and thanks for sharing your hard work!

I'm curious why it seems you have stayed with ISE10.1, according to your notes in the M65C02_Core file? I remember ISE10 was still supporting Spartan 2 generation.. I'm sure the optimization tools are improved in ISE13.4.

[MichaelM]

EE:

I do use ISE 13.4 for other architectures, but the performance of the Spartan 3AN family is better utilized by the 10.1i SP3 Mapper and PAR tools. It appears that 12.4 corrects some serious problems with the Virtex 5 family, but it performs far worse than 10.1i on the Spartan 3AN family.

I've run the core through the 13.4 tool and performance is much better if the target is changed to one of the Spartan 6 parts. I suspect that the 6-input LUTs of the Spartan 6 are a better match to the wide combinatorial equations in the address generator than the 4-input LUTs of the Spartan 3A.

[Windfall]

MichaelM wrote:

I hope that the core I've attached will be useful to some of the forum members.

Thanks Michael. I'll certainly have a look.

Just an observation, if I may : in any core, most users will be looking for a drop-in replacement for the real silicon. Any deviations are best relegated to 'optional'.

[GARTHWILSON]

Quote:

Just an observation, if I may : in any core, most users will be looking for a drop-in replacement for the real silicon.

Um, why, since the real silicon is still being made, with no end in sight?

[Windfall]

GARTHWILSON wrote:

Quote:

Just an observation, if I may : in any core, most users will be looking for a drop-in replacement for the real silicon.

Um, why, since the real silicon is still being made, with no end in sight?

Because the real silicon is not always convenient.

Why do you think WDC makes a core as well ? (And yes, I have experience with their silicon as well, see http://web.inter.nl.net/users/J.Kortink ... /index.htm. You see, that time it was actually convenient ... ).

[BigEd]

Hi Michael

MichaelM wrote:

I do use ISE 13.4 for other architectures, but the performance of the Spartan 3AN family is better utilized by the 10.1i SP3 Mapper and PAR tools. It appears that 12.4 corrects some serious problems with the Virtex 5 family, but it performs far worse than 10.1i on the Spartan 3AN family.

Thanks for this - excellent information!

Thanks also for your code, and for putting it under LGPL. Great that it's a 'C02.

If you're prepared for a bit of a learning curve I'd recommend hosting the project on github: I can help you over email or PM. (It's rather painful if you don't adopt a git client at your end - it's a push/pull model. EEye has been using it more as a website-based edit model which only works well for minor changes.) Github is free for projects which happen out in the open. Arlet, myself and André use it, as does Mike Naberezny (who owns this site). There are probably other users here too.

Cheers
Ed

[Arlet]

MichaelM wrote:

In most cases, the core as implemented saves one clock cycle from most multi-cycle operations. The result is that the core, as implemented, will yield an improvement of approximately 40% for an average W65C02 program.

How does that work ? Assuming you can only do 1 memory access per cycle, it looks like you can only save a cycle in implied (2->1), ZP_X (4->3), and IND_X (6->5) addressing modes.

[GARTHWILSON]

Windfall wrote:

GARTHWILSON wrote:

Quote:

Just an observation, if I may : in any core, most users will be looking for a drop-in replacement for the real silicon.

Um, why, since the real silicon is still being made, with no end in sight?

Because the real silicon is not always convenient.

Why do you think WDC makes a core as well ? [...]

You did say "drop-in replacement" though, which means it goes into existing boards. I would be very pleased if Microchip would put a 65c02 or '816 core in their PICs to replace their own decrepit core; but it sure wouldn't drop into any 6502 sockets, and since they would have their own ROM onboard and the I/O would be different from any implemented with 65c02's, the code would have to be changed anyway, so there's no need for backward compatibility.

[BigEd]

Arlet wrote:

MichaelM wrote:

In most cases, the core as implemented saves one clock cycle from most multi-cycle operations. The result is that the core, as implemented, will yield an improvement of approximately 40% for an average W65C02 program.

How does that work ? Assuming you can only do 1 memory access per cycle, it looks like you can only save a cycle in implied (2->1), ZP_X (4->3), and IND_X (6->5) addressing modes.

A two-cycle branch-taken would help... and indeed, we see Michael has given us both a test program listing m65c02_tst2.lst and a trace of activity M65C02_SV_Output.txt which shows a BRA taking only two cycles (line 36), but no other taken branches. We do see direct-page RMW taking only 4 cycles (for example, line 876). I suspect that has to incur some combinatorial penalty on the memory accesses, but it does save on cycles. (There might be some mis-counting in the 40% figure, as a lot of not-taken branches are marked up as 3-cycle but performed in 2. I don't know if that mark-up is used as a basis.)

Cheers
Ed