In general most instructions on the 6500 series take as many cycles as there are memory accesses, with a lower limit of two. This means no instruction will execute in less than two cycles (*1).
The mentioned ADC gives a nice example, as it offers almost all addressing modes:
Mode Example Length
| | No. of Memory Access
| | | Code Access (Read)
| | | | Pointer Access (Read)
| | | | | Internal (Dummy Read)
| | | | | | Data Access (Read or Write)
| | | | | | |
Immediate ADC #imm 2 / 2 / 2 -> 2
Zero Page ADC zp 2 / 3 / 3 -> 2 / / / 1
Zero Page,X ADC zp,X 2 / 4 / 3 -> 2 / / 1 / 1
Absolute ADC abs 3 / 4 / 4 -> 3 / / / 1
Absolute,X ADC abs,X 3 / 4+ / 4 -> 3 / / o / 1
Absolute,Y ADC abs,Y 3 / 4+ / 4 -> 3 / / o / 1
Indirect,X ADC (zp,X) 2 / 6 / 6 -> 2 / 2 / 1 / 1
Indirect,Y ADC (zp),Y 2 / 5+ / 5 -> 2 / 2 / o / 1
For example the entry of Indirect,Y is read as:
- Addressing mode Indirect,Y
- Written as ADC (zero page address),Y
- Length of the instruction in bytes is 2
- Cycles it takes to execute is 5
- Number of memory accesses needed to perform the instruction is 5
These memory accesses are as follow (and in sequence)
- 2 cycles to fetch the instruction bytes
- 2 to fetch the two bytes of a pointer
- 1 cycle to to fetch the data byte
So far the 6500 is like a textbook implementation of a RISC CPU. Every operational cycle is a memory cycle. Except for two situations:
- Indexing instructions that need to add an index to an 8 bit base address (*2).
- Indexing instructions whose indexing result crosses a page (*3).
The first will always happen and is noted under the Internal header with a '1', while the second only happens when the data processed requires it, marked with 'o' (*4). They will, as well, always be inserted in sequence before the data access.
The reason for this is the target to make the 6500 as simple (and thus cheap) as possible. It uses the single 8 bit wide ALU as adder for all address calculations. The first case could have been removed by implementing a second adder, just for address calculation, while the second would need this to be a 16-bit adder. Without such a dedicated 16 bit adder, these instructions need to take another round through the ALU.
At this point it's quite important to remember that back then the task wasn't about squeezing out the last possible bit of performance, like today, but everyone was happy to have a CPU at all. And the 6502 in particular was meant as a low price offer way below all competition. The 6502 was introduced at 25 USD, a 7th of the directly comparable 6800, which was sold at 175 USD. To reach this price point, there was simply no case to throw hardware at the issue, as is done today.
Of course, there are special issues with other, less regular instructions, but they all come down to the same mechanic - an instruction takes as many cycles as there are memory accesses done plus address calculation cycles due to its 8-bit nature.
For more details there is the good old instruction list and its 65C02 sibling at 6502.org - which is always a great first stop about all things 6502. If you want to dig really deep into the internal workings of how and why, then a first look at Hanson's diagram will help to understand - plus of course the wonderful Visual 6502 site and its quite intriguing emulation - just be aware that this is maybe way above the level of someone tackling these issues for the first time.
*1 - This is due to the way instruction fetch works. Rockwell (R6500) and CMOS (65C02) versions removed that in part.
*2 - I.e.
(zp,X). Here the 8 bit base address is fetched from instruction (
zp,X) or zero page (
(zp,X)) and a cycle is needed to do the indexing.
*3 - When the 8 bit instruction
*4 - Also noted with a '+' after the number of cycles, which is the standard notation to show this.