If it seems pretty dead here it's because the discussions have moved to the forum that is now part of www.6502.org
. I just came here to look at something in the archives. The 6502.org forum is doing well and growing, and the website has a lot of exciting additions in the works.
Western Design Center, who is still advancing the 65 family, has a table of several pages showing what happens in each cycle of any given instruction. Their website is www.westerndesigncenter.com
. The 6502 has minor pipelining that allows it to do several things in one clock cycle, so it takes few cycles to complete an instruction. In the case of LDA# for example, the op code is fetched in the first clock. The next byte is fetched in the second clock while the op code is being decoded. By the third clock, the processor knows that the second byte was an operand for the first byte and that it needs to put it in the accumulator, so it does that while fetching the op code for the next instruction. IOW, the LDA# only takes two clocks' time. In the case of LDA ZP, the op code is fetched in the first clock, the operand (which is the address in ZP) is fetched in the second, and the content of that ZP address is fetched in the third. The op code of the next instruction is fetched in the following clock. For absolute addresses with 16-bit operands, you add another clock. If it's indexed, the addition to the low byte takes place while the high byte is being fetched. (This is partly why it's low-byte-first.) If a carry out of the low byte does not require incrementing the high byte, no extra time is taken before the effective address is read. Indirects add another operation requiring an additional fetch before they're done.
We're glad to be able to answer questions; but if you have more, you'll get much faster response by just going directly to the forum on www.6502.org