6502.org

So you're saying 4 when not taken, and 5 when taken?

Doc for the Rockwell 'C02 says BBS and BBR are 5 cycles (branch not taken), 6 for branch taken, or 7 for branch taken with a page crossing. It's always possible the doc contains an error, but Rockwell doc is usually very good.

We know it'll take 3 cycles just to fetch the instruction bytes. We also need to fetch the zero-page location referenced, and apparently there's at least one more cycle (to isolate the desired bit, perhaps).

-- Jeff

ps- Whenever possible I avoid WDC doc and refer to Rockwell doc instead. Of course that's no good for stuff like AC timing specs (the fastest Rockwell chips are only 4 MHz), but for many details including instruction cycle counts it's fine -- I'm sure the cycle counts are identical (overlooking the fact Rockwell has no STP and WAI instructions). I've even observed that the undocumented NOP's are identical.

If optimising for performance, I think 3 cycles in the not-taken case is possible. You would not need to actually read the branch target offset byte, just increment the PC to point to the next instruction and read that.

sorry i guess i kinda miswrote that, for BBR and BBS it's 3 cycles when not taken and 4 when taken, regular branches are 2 when not taken, and 3 when taken.
i which is exactly 1 cycle more.

sadly I cannot shave off more cycles without using a 16 bit data bus or something.
oh i didn't know that the original BBR/BBS instructions had different cycles count.
i used this site for the cycle counts: http://6502.org/tutorials/65c02opcodes.html
and it says: i didn't even know the WDC Datasheet had any cycle counts in it... i only used it to look up all instructions the CPU had.

Original post:

well i guess i finished the 65C02V, i didn't test every single instruction yet though.
but i was able to finish the Timing/Opcode table! * the speed difference between the 65C02 and 65C02V is around 20% (on average of course)
it would be interesting to see some kind of benchmark program or something that tries to guess the clock speed of the CPU without using interrupts, and see how it would do with a regular 65C02 and this one.


*
though i still got a few questions before i call this "finished enough for now"

1. about WAI, what is the cycle count supposed to mean? i just assumed it's the amount of cycles it needs in order to get into it's stable "waiting for interrupts" loop... that is also how my version of WAI is a 1 cycle instruction, as once it read the Opcode it directly starts checking for interrupts.
2. about STP, what is the cycle count supposed to mean in this one? is it like WAI but checking for Resets instead?
3. i still need to make a circuit for BCD Addition/Subtraction and i have no idea how to do it.

If you mask interrupts, trigger one, then execute WAI, it will execute without pausing in 3 cycles. Without a triggered interrupt, it will pull RDY low on the third cycle, then let it go high again when an interrupt arrives. When that third cycle completes, the interrupt is taken if unmasked. Apparently the hard-core 65C02 has separate output and input signals instead of the combined RDY pin.

STP probably reuses the microcode of WAI, but actually disconnects the internal clock instead of just pulling RDY low. It simply takes 3 cycles to reach that point.

The 6502 did BCD in a decidedly different way to most other CPUs. I believe there's a patent (long since expired of course) which you could consult for inspiration, and explains why the 6502 doesn't have a "half carry" flag nor a "decimal adjust" instruction, and didn't take any extra time for a decimal operation relative to a binary one. (The 65C02 does take extra time, but that's done only to generate the correct status flags.)

But to get the essential function right (ignoring performance concerns and implementation complexity) is that you do a normal binary addition, then from the least significant end check each nybble (including the carry to the next nybble) to see whether that digit exceeded 9; if it did, you add 6 in that position, including carrying to the next nybble if required. For SBC decimal, you need to subtract the operand from $99 instead of $FF, then proceed as for addition.

oh i forgot about the RDY pin stuff, but yea it seems like the cycles are as i expected, just the time from the start of the instruction to when it loops.
I'm sorry, but why do i sometimes see people write "nibble" as "nybble"? it's quite rare but still happens from time to time. same with people who write "tyre" instead of "tire".

anyways i looked up the circuit for BCD Addition/subtraction and it's similar to Binary but not exactly the same. LINK to the site i used as refrence

now i just need to build this into my CPU. but one question about that. the Carry in and out are easy to hook up, but what about the Overflow output? is it used at all while decimal mode is active?

"Tyre" is a correct British spelling for "tire". "Nybble" is, apparently, spelled that way because "byte" is spelled as it is.

(I've always used 'nibble' but I notice with a little surprise that Knuth uses 'nybble' in Vol4 Fascicle 2)

I believe the US standard is 'nybble' to match 'byte' but the UK standard is 'nibble' unless like me you grew up reading too much US literature and prefer 'nybble'.

It also matches with 'tydbit' ... (two bits).

As a Brit myself, I always saw "nybble" and find the "nibble" spelling decidedly odd in this context.

I had a nibble for lunch today, in between working with nybbles.

besides weird language things (in german it's also "nibble")

the question still stands, what does the overflow flag do while Decimal mode is enabled? i mean there is no signed overflow since BCD is unsigned only.

I have: …where A and B are the operands and s is the result. This is sufficient to pass Klaus' test suite, which checks all valid BCD combinations, for both ADC and SBC. It might not match the behaviour of a real CPU for invalid BCD operands, but that already varies across the family.

In essence, it still represents a carry from bit 6 to bit 7, which corresponds to signed overflow in two's complement binary. The fact that signed overflow is not really meaningful in BCD is incidental.

Bruce Clark has written many good documents on 6502 behaviour: here are two for this case
http://6502.org/tutorials/vflag.html
http://6502.org/tutorials/decimal_mode.html

to be honest that is a lot more complex than i would've liked it to be.
can't i just use the binary V flag output and call it a day, since barely anyone would use it anyways? because that is exactly what my design is currently doing.
so for example 0x50 + 0x50 sets the overflow flag in both binary and BCD mode though the actual output is different (0xA0 in binary, and 0x00 in BCD mode)