Gutschmidt, Jens

cpu65c02_tc - R65C02 Processor Soft Core with accurate timing

Any chance of getting the VP added to this core? Other than that it works very well.

- WR cycles are not delayable (like 6502)
- not all internal cycles are delayable

Behavior of "RDI" like 6502 and not effect all cycles

Hi Jens, 

Are you still interested in bug reports for the 65C02 True Cycle core? 

Here is bug 3 of 3: 

I've been debugging the JMP page crossing bug with my 6502 Bus Analyzer. This will flag errors where it spots a behaviour that is inconsistent with its own internal model of the 65C02. 

I think there are a few issues with the interrupt sequence, as seen here:

<Cycle number> <Data> <Sync> <RnW> <nRST>

0 2c 1 1 1
1 fa 0 1 1
2 fe 0 1 1
3 7f 0 1 1
F980 : 2C FA FE : BIT FEFA       : 4 : A=F8 X=FF Y=00 SP=FD N=0 V=1 D=0 I=0 Z=0 C=1
0 10 1 1 1
1 fb 0 1 1
2 ad 0 1 1
F983 : 10 FB    : BPL F980       : 3 : A=F8 X=FF Y=00 SP=FD N=0 V=1 D=0 I=0 Z=0 C=1
0 ba 0 1 1
1 f9 0 0 1
2 80 0 0 1
3 61 0 0 1
4 f2 0 1 1
5 fc 0 1 1
FCF2 :          : INTERRUPT !!   : 9 : A=F8 X=FF Y=00 SP=FA N=0 V=1 D=0 I=1 Z=0 C=1

The first issue is that the interrupt sequence should be 7 cycles, with cycles 0 and 1 being the aborted opcode fetch, cycles 2,3,4 being the write back, and cycles 5,6 being the vector fetch. In your core it is only 6 cycles.

The second issue is that cycle 0 of the interrupt sequence should have sync asserted. It doesn't.

The third issue is that the address output in cycles 0 and 1 should be PC, PC + 1. I don't believe the address being output is PC or PC + 1 (as the data in this case would be 0x2c and 0xfa).

This and the preceding branch bug are the only cases flagged as incorrect so far by my 6502 Bus decoder.

Many thanks again for your excellent core! 

Dave (hoglet on 6502.org and stardot.org.uk)

Interrupt sequence issues

Hi Jens, 

Are you still interested in bug reports for the 65C02 True Cycle core? 

Here is bug 2 of 3: 

I've been debugging the JMP page crossing bug with my 6502 Bus Analyzer. This will flag errors where it spots a behaviour that is inconsistent with it's own internal model of the 65C02.

It flagged the following branch as having the wrong number of cycles:

2EFB : 6A       : ROR A          : 2 : A=4C X=00 Y=A3 SP=F7 N=0 V=1 D=0 I=0 Z=0 C=1
0 66 1 1
1 19 0 1
2 0c 0 1
3 0c 0 1
4 86 0 0
2EFC : 66 19    : ROR 19         : 5 : A=4C X=00 Y=A3 SP=F7 N=1 V=1 D=0 I=0 Z=0 C=0
0 90 1 1
1 02 0 1
2 65 0 1
3 4d 0 1
2EFE : 90 02    : BCC 2F02       : 4 : A=4C X=00 Y=A3 SP=F7 N=1 V=1 D=0 I=0 Z=0 C=0
0 6a 1 1
1 6a 0 1
2F02 : 6A       : ROR A          : 2 : A=26 X=00 Y=A3 SP=F7 N=0 V=1 D=0 I=0 Z=0 C=0

My understanding is a branch incurs the extra page crossing cycle if the target is on a different page than the instruction AFTER the branch instruction. So a branch at xxFE should only take three cycles.

Many thanks again for your excellent core! 

Dave (hoglet on 6502.org and stardot.org.uk)

Branch takes incorrect number of cycles

Hi Jens,

Are you still interested in bug reports for the 65C02 True Cycle core?

Here is bug 1 of 3:

When a JMP instruction straddles a page boundary, e.g.

10FE 4C 03 00 JMP 0003

The third byte is fetched from the wrong page. So in the above example, it would be fetched from 0x1000 rather than 0x1100.

This bug causes Acorn Tube Elite to crash when F6 is pressed. It also causes the call command in BBC Basic IV to crash. It is not picked up by the Dorman tests.

I can provide a GHDL simulation of this.

I believe this is the fix:
https://github.com/hoglet67/CoPro6502/commit/d283556ab75efa09f14a1da53514b1fb34b6aa26

It simulates correctly, and resolves the above issues on Tube Elite and BBC Basic. The Dormann tests still pass.

Many thanks for your excellent core!

Dave (hoglet on 6502.org and stardot.org.uk)

JMP page crossing bug

(Found by user)

The flag "Overflow" / "V" (Bit 6 in the Processor Status Register) is computed wrong in op codes "ADC" and "SBC".
This flag was not 100% tested in my test environment in the past. Also this flag is rarely used by available software e.g for APPLE}{.
The erroneous code segment lies in the block "fsm_execution_unit".

Will be corrected in the next upcoming production release as soon as possible.

ADC & SBC: Overflow Flag wrongly computet

I've discovered an infinite loop with the Verilog version when processing the opcode $69.  This happens with both iverilog and ModelSim.

Single-stepping with ModelSim shows the code enters the always block at line 5008 of fsm_execution_unit.v, satisfies the condition on line 5994, then loops back to 5008. I think this is due to setting the register zw_ALU  (zw_ALU <= {1'b 0, q_a_i} + {1'b 0, d_i} + reg_F[0];) as this register also appears in the @always block.

I have only just started learning Verilog, and I have no clue whatsover about VHDL, so my ability to debug this issue is limited.

Infinite loop with opcode $69 (ADC)

The computation of the return address work wrong for "NMI" and "IRQ" (same error like in cpu6502_true_cycle).
It is fixed in the upcomming new release.

NMI & IRQ works wong

just an idea: 100+ states usually means you code very bad.

The RTI instruction pulls the wrong data from the stack. Instead of pulling the Stack Pointer + 1, Stack Pointer + 2, and Stack Pointer + 3, it pulls Stack Pointer - 1, Stack Pointer - 2, and Stack Pointer - 3. This causes the wrong data to be put into Processor Status Register and the processor to continue execution at the wrong location.

+++ CORRECTED +++
RTI referenced to parts of the ALU section which was removed in earlier versions. So the direction control for the stack pointer was hard wired to "-" by RTI.

RTI instruction

The finite state machine was re-worked to fix this bugs (little changes - silly failure...)

Because of a failure in the interrupt stage the R65C02_TC will crash by using any type of internal/external interrupt source or command.
So don't use BRK, IRQ and NMI with the current version!
The errors are fixed in the upcomming new version of the R65C02_TC.

BUGS found in interrupt stage

Hello,

Why not add SWEET16 into the 65C02? The design, by the Woz, is as clean as the 6502 itself and has a few slots for further expansion.

Is true timing a must? If not I'd suggest making the zero page a on chip two port RAM, one port for zero page mode, the other for absolute mode. That way the zero page becomes the register file it should have been from the start.

Browse

cpu65c02_tc - R65C02 Processor Soft Core with accurate timing