I've looked at several 65C02 documents, but they all seem to disagree on the instruction timings. Today I got bored and wrote code and counted cycles. Attached is a document formatted to my preferences with my findings.
This was run on real HW, a Teensy 4.1 simulating memory and controlling a brand new W65C02S6TPG-14. The Teensy spits out a log containing address, data, r/w and opcode fetch. Some manual work to read the log and transcribe to the document, but worked very well.

EDIT: updated the document to v0.2.1

_________________
/NollKollTroll

Nice document...

I think there is an error with the flags on BIT <immediate> (opcode 89).

This only updates the Z flag; the N/V flags are unchanged.

Dave

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for the report, I'll make sure to test it on my setup and update the doc. I've read 3 different versions of WDCs docs and 5-6 other, and they all seem to think that BIT imm DOES transfer bit 6 and 7.
Trying to get proper docs for the 65C02 has been such a frustrating exercise, the only upside was that I KNEW the info was flawed since the different sources disagreed on so many points.
Since I started my project with simulating an NMOS 6502, I'm begining to wonder if a simulated CMOS 65C02 is possible to get right with the level of messy documentation? I'm glad I now run a real CPU, which gets it right no matter what

_________________
/NollKollTroll

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

A test showed that it is indeed correct that BIT immediate only changes the Z-flag. Updated doc added to first post.
I'll have a look at that book, I only read summary documents which was what I needed. Will be interesting to see how the book matches my findings

_________________
/NollKollTroll

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

(In the case of 6502 I prefer to call the processor status register P. That matches the opcodes PHP and PLP. And avoids confusion with S, the stack pointer register.)

BDD: you are correct. I'll have to think about how to phrase it better.

_________________
/NollKollTroll

A related document can be found in this post.

6502 Dead Cycles.pdf obviously has a bearing on timing. But this detailed listing also explains what addresses appear on the bus during the dead cycles. Besides being of general interest, this matter has relevance in regard to "rogue read" and other problems that can arise in regard to use of certain certain IO devices if they're mapped to an address which can be erroneously touched.

The title mentions 6502, but the 'C02 is also covered. And the 65C816 supposedly produces the same dead-cycle addresses as the 6502, although we didn't verify this. (The 816's VDA signal is always low during dead cycles. Therefore the problems can be prevented if the glue logic requires VDA high in order for the IO device to become selected.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, we agree on that point. As well as during dead cycles, VDA is also low during program fetches other than opcodes fetches. In other words, VDA being low is ambiguous. It could mean either a dead cycle or a Program Fetch Other than an Opcode fetch. (In case anyone needs a reminder, every 65xx instruction includes one opcode byte and zero or more PFOO's, aka operand bytes. And, the 816's VPA/VDA signals vary according to four categories of bus cycle I'll call opcode fetch, PFOO fetch, data fetch/store, and dead cycle. )

Now here's the thing. VDA being low is ambiguous. But for an IO device, the ambiguity doesn't matter. I suggested the glue logic should require VDA high in order for the IO device to become selected, and that means dead cycles will result in de-selection, just as we require. De-selection will also result from PFOO's... but this is not a problem! The ambiguity doesn't matter as long as we're dealing with IO devices only.

I think the confusion arises when the go/no-go signal is applied at a point (such as a decoder) which controls both IO and memory... and I believe your POC's fit this description. Now you do need a go/no-go signal which identifies dead cycles unambiguously. A moment ago I said it's alright for IO to be de-selected during PFOO's, but the same isn't true for memory! And if IO and memory are both subject to a single go/no-go signal, then the logic generating that signal does need to consider both VPA and VDA. So we agree on that, too.

But with different design decisions the circumstances become more relaxed. If the go/no-go signal is applied at a point which only controls IO then VPA can be ignored, and that makes things faster and simpler. For example, 65xx peripheral chips can be effectively protected, with no extra gates and no added propagation delay, simply by driving their active-high Chip Selects with VDA.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!