Just looking at some 6502 stuff, and the program counter notes at http://www.6502.org/tutorials/6502opcodes.html#PC say: "When the 6502 is ready for the next instruction it increments the program counter before fetching the instruction." ... which seems to imply that T-cycle 0 of an instruction first increments PC, then fetches the opcode from the memory location pointed to by PC. Which seems nuts, as it would also mean that either jump addresses would have to be off by 1, or at the start of T0 the CPU would have to determine what the _previous_ instruction was and then either increment PC or leave it alone accordingly. And all of this would have to happen before the address is placed on the address bus approximately 1/4 of the way into T0. I expect that what actually happens is that PC's contents are latched onto the address bus during the clock-low half of T0, R/W is asserted, and *then* PC is incremented. During the subsequent clock-high half of T0, the data bus will reflect the contents of [PC] as it was at the start of T0, and the PC increment will complete, so that at the end of T0 PC is pointing to either an operand byte for the current instruction, or the next instruction in the sequence (if the current instruction has no operands). Can anyone confirm? Although technically I suppose the text on the site would still be accurate, because the increment would actually have begun before the fetch had entirely completed, but the way it reads to me is that the opcode fetch happens at [PC+1], not [PC]... The text then goes on to say: "Once it has the op code, it increments the program counter by the length of the operand, if any." 6502 operands can be 1 or 2 bytes in length; the above seems to imply that for a 2-byte operand it would add 2 to PC - meaning it would have to fetch the first operand byte from PC-1 (and there's no PC-decrement logic in sight). I expect that what it really does is fetch the first byte from PC (which will have been incremented during the opcode fetch cycle), increments PC by 1, fetches the second byte, and increments PC again. Right? :-) Now, someone on the BBC micro list said they think that the 6502 might always do an operand byte fetch immediately after an opcode fetch, even if that instruction doesn't have any operand data - simply because it takes time for the CPU to decode the instruction. If it turns out that the instruction doesn't have an operand, it avoids doing the PC increment that would have been done if an operand were present (which means that at the next cycle, which the CPU will perform as an opcode fetch, the same byte is re-read from memory and interpreted as an instruction). Does anyone know if this "always read" is what happens? Or is the instruction decoding actually quick enough for the CPU to know by the end of T0 that there's no opcode data (and so it can reset its cycle counter and perform the next cycle as an opcode fetch)? cheers Jules