>I thought it worth a mention here, in case anyone is actively using Jens core. As far as I'm aware, it is unique as the only true cycle 6502 core out there.
>
>Dave

My core doesnt count as a true cycle 6502?

https://forums.xilinx.com/t5/Xcell-Daily-Blog-Archived/MCL65-open-source-6502-processor-core-now-powers-Atari-2600-VCS/ba-p/800565

Ah, I wonder if Dave meant to say 65C02... Jens offers one of each.

Still, good to have a reminder of your core - I've added it to the big list.
http://6502.org/homebuilt#HDL

Sorry about that Ted, I had somehow managed to miss your MCL65 core.

And Ed, I wasn't specifically thinking of just the 65C02 when I wrote that.

I possibly have a stronger definition of cycle-accurate in mind than most: not only should it match the original device in terms of clocks ticks for each instruction (warts and all), but it should also match the original device's use of the bus, on a cycle-by-cycle basis.

For example a JSR instruction should look like:
- Cycle 0 - Opcode fetch (0x20)
- Cycle 1 - Operand fetch (low byte of target address)
- Cycle 2 - Dead cycle
- Cycle 3 - Push high byte of (instruction address + 2)
- Cycle 4 - Push low byte of (instruction address + 2)
- Cycle 5 - Operand fetch (high byte of target address)

Why is this important to me? It's because my 6502 bus cycle decoder makes use of this knowledge. And JSR was one of the unexpected (to me anyway) cases that I encountered.

Does the MCL65 meet this definition as well?

Are there any other cycle-accurate cores that people know of, 6502 or 65C02?

Dave

Hi Dave,

I know exactly what you mean... Yes, the MCL65 is CPU cycle exact as well as bus-cycle exact. It performs the exact same bus fetches, over-fetches, interrupts, and other sequences to match the original 6502. This was necessary to be able to use the core inside of an actual Apple II, Atari 2600, and Commodore computer. All signals/pins going to the 6502 are supported by the MCL65.

I also think that the true test of the "correctness" of a CPU core is to run it on actual vintage hardware where it can execute all of the programs used at the time. It it can run operating systems, games, and utilities on multiple systems, some of which are very cycle/bus timing dependent, then you can be sure the core is an accurate clone of the original CPU.

This was on my mind when designing the MCL65 and as far as I know it is the only 6502 core that can run timing/bus exact on vintage hardware.

Thanks,
-Ted

In fact, here is my JSR microcode routine which matches the cycles you described:

// -------------------------------------------------
// -------------------------------------------------
// 0x20 - JSR - Jump to Subroutine
// -------------------------------------------------
@470 277F_0001 // PC = PC + 1
@471 4A7F_0000 // ADDRESS_OUT = PC
@472 4DFF_0001 // SYNC=0, RD_WR_n=1

@473 1033_0000 // Wait for CLK to be high
@474 1034_0000 // Wait for CLK to be low
@475 32BF_00FF // r2 <= data_in AND 0x00FF -- Fetch ADL
@476 4A8F_0000 // ADDRESS_OUT = SP OR 0x0000
@477 4DFF_0001 // SYNC=0, RD_WR_n=1

@478 1033_0000 // Wait for CLK to be high
@479 277F_0001 // PC = PC + 1
@47A 1034_0000 // Wait for CLK to be low
@47B 3FBF_00FF // Dummy <= data_in AND 0x00FF -- discard data
@47C 4DFF_0000 // SYNC=0, RD_WR_n=0
@47D 4BF7_0000 // Data_Out <= 0x0000 OR PC_Byte_Swapped
@47E 288F_FFFF // SP <= SP - 1

@47F 1033_0000 // Wait for CLK to be high
@480 4DFF_0004 // Dataout_Enable=1, SYNC=0, RD_WR_n=0
@481 1034_0000 // Wait for CLK to be low
@482 4DFF_0000 // Dataout_Enable=0, SYNC=0, RD_WR_n=1 -- Push PCH
@483 4A8F_0000 // ADDRESS_OUT = SP OR 0x0000
@484 4B7F_0000 // Data_Out <= 0x0000 OR PC

@485 1033_0000 // Wait for CLK to be high
@486 4DFF_0004 // Dataout_Enable=1, SYNC=0, RD_WR_n=0
@487 1034_0000 // Wait for CLK to be low
@488 4DFF_0000 // Dataout_Enable=0, SYNC=0, RD_WR_n=1 -- Push PCL
@489 4A7F_0000 // ADDRESS_OUT = PC
@48A 4DFF_0001 // SYNC=0, RD_WR_n=1

@48B 1033_0000 // Wait for CLK to be high
@48C 288F_FFFF // SP <= SP - 1
@48D 1034_0000 // Wait for CLK to be low
@48E 31BF_FF00 // r1 <= data_in AND 0xFF00 -- Fetch ADH
@48F 4712_0000 // PC = r1 OR r2
@490 4A7F_0000 // ADDRESS_OUT = PC
@491 4DFF_0003 // SYNC=1, RD_WR_n=1
@492 1000_0102 // Jump to main loop

Hi All

Today (10-Sep-2018) an updated release v1.52 of the r65c02_tc was uploaded to opencores.org repository.
State "RELEASE CANDIDATE" was changed to "READY - PRODUCTION".

Because of the missing feedback since 2014 all work around this core has been canceled.
With Dave's and Ed's very good help and great on-the-fly support all hidden issues for cycle accuracy and instruction bugs since April 2014 are now solved/fixed.

Here an overview of the improvements:

Revision 1.52 2018/09/10 12:14:00 jens
- RESET generates SYNC now, 1 dead cycle delayed

Revision 1.52 RC 2018/09/09 03:00:00 jens
(never submitted to opencores)
- ADC / SBC flags and A like R65C02 now

Revision 1.52 BETA 2018/09/05 19:35:00 jens
(never submitted to opencores)
- BBRx/BBSx internal cycles like real 65C02 now
- Bug Fix ADC and SBC in decimal mode (all op codes -
1 cycle is missing
- Bug Fix ADC and SBC in decimal mode (all op codes -
"Overflow" flag was computed wrong)

Revision 1.52 BETA 2018/09/02 18:49:00 jens
(never submitted to opencores)
- Interrupt NMI and IRQ processing via FETCH stage now

Revision 1.52 BETA 2018/08/30 15:39:00 jens
(never submitted to opencores)
- Interrupt priority order is now: BRQ - NMI - IRQ
- Performance improvements on-going (Mealy -> Moore)

Revision 1.52 BETA 2018/08/23 20:27:00 jens
(never submitted to opencores)
- Bug Fixes All Branch Instructions
(BCC, BCS, BEQ, BNE, BPL, BMI, BVC, BVS, BRA)
3 cycles now if branch forward occur and the branch
instruction lies on a xxFEh location.
(BBR, BBS) 6 cycles now if branch forward occur and the
branch instruction lies on a xxFDh location.
- Bug Fix Hardware Interrupts NMI & IRQ - 7 cycles & "SYNC" now
- Bug Fix Now all cycles are delayable (WR and internal)

Revision 1.51 RC 2014/04/19 14:44:00 jens
(never submitted to opencores)
- Bug Fix JMP ABS - produced a 6502 like JMP (IND) PCH.
When the ABS address data bytes cross the page
boundary (e.g. $02FE JMP hhll reads hh from
$02FF and ll from $0200, instead $02FF and $0300)

Good luck to all of your projects!
Jens

Thanks for posting your hard work Jens! I see it on opencores

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