cpu65c02_tc - R65C02 Processor Soft Core with accurate timing
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)
Arrgh, for some reason the bugtracker removed all line breaks! Let's try again....
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 in the next comment.
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)
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 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 F980 : : INTERRUPT !! : 9 : A=F8 X=FF Y=00 SP=FA N=0 V=1 D=0 I=1 Z=0 C=1 0 85 1 1 1 1 fc 0 1 1 2 f8 0 0 1 FCF2 : 85 FC : STA FC : 3 : A=F8 X=FF Y=00 SP=FA N=0 V=1 D=0 I=1 Z=0 C=1
Hi Dave
Your second trial is better to me ... ;-).
6 cycles instead of 7 cycles Yes, there are only 6 dedicated (visible) cycles for an interrupt sequence. "cycle 0" is wrongly covered by the pipelinig while completing the previous instruction => cycle 0 is "missing". The sequence of "3 Bytes to Stack", "Vector Read" and "Jump to vector" are correct. Minor effort to fix the "cycle 0".
Missing Sync signal in cycle 0 of interrupt It is intentionally to generate NO SYNC. In early development for the 65c02_tc I found a notice for this interrupt behavior of the R65C02. At this time I cannot find this document for reference. I havn't any REAl 65c02 hardware reference. Little effort if necessary to fix it.
Address output PC, PC+1 It is a result of the hidden "cycle 0" (see 1. obove). The current pipelined "cycle 0" for interrupts prepares the PC to "PC+1" only. So, "PC = PC" is not generated or outputted yet. See 1. for effort suggestion.
Notice: 1. "nmi_n" have priority over "irq_n" 2. "nmi_n" is edge triggered 3. "irq_n" is level triggered and must be held active until software generate an "ack" to the interrupting device. Please notice me if there are any other requirements for your project.
Thank you for the very clear explanation - easy to follow and understand!
- Missing Sync signal in cycle 0 of interrupt It is intentionally to generate NO SYNC. In early development for the 65c02_tc I found a notice for this interrupt behavior of the R65C02. At this time I cannot find this document for reference. I havn't any REAl 65c02 hardware reference. Little effort if necessary to fix it.
I'm very sure that the real 6502 asserts sync in cycle 0 of the interrupt sequence, and that the 65C02 does the same.
It's very obvious when using my 6502 protocol decoder if this does not happen, because it then looses sync and flags errors.