Date   : Mon, 05 Nov 2012 19:07:08 -0600
From   : jules.richardson99@... (Jules Richardson)
Subject: 6502 timing and zero-page instructions

On 11/05/2012 05:06 PM, Ed Spittles wrote:
> On 5 November 2012 20:19, Jules Richardson<jules.richardson99@...>
>   wrote:
>
>>
>> Hmm, so potentially PC might be incremented twice in a single cycle:
>>
>>     cycle0: increment PC if previous instruction didn't modify PC directly
>>             and previous instruction had an operand
>>             fetch opcode
>>             increment PC only if opcode has an operand
>>
>>     cycle1: fetch operand
>>             increment PC only if operand takes 2 bytes
>>
>>     cycle2: fetch operand
>>
>>     ...
>>
>> ?
>>
>
> Hmm, I think it has to be more like
>
> cycle 0: fetch opcode, increment PC
>
> cycle 1: increment PC unless we need no operand.  Read memory anyway.
>
> cycle 2: depends on the opcode.  Could be a fetch of the next one.

Oh, I think I follow. In a bit more detail, cycle 1 is then presumably:

   clock-low: - latch PC into address latches
              - assert R/W
              - increment PC if current instruction has an operand
   clock high - memory at location dictated by address latches appears
                on data bus

... 'increment PC' can start as soon as the address is latched during the 
first half (clock low) of the machine cycle, and so it doesn't matter if 
it's hardly instant - it's not actually needed again until about the 
corresponding time during the next clock cycle.

cycle 2, in the two-byte operand case, is also the same, except the PC 
increment test is against the instruction having two bytes of operand.

cycle 0 is also the same, except that the data bus contents get transferred 
to the IR rather than the DL, and there's no condition on the PC increment 
- it always happens. (and yes, there's other stuff goes on here to do with 
hardware interrupts and single-stepping the CPU).

The only flaw I see is that it doesn't require any kind of pre-increment of 
PC as part of the opcode fetch, which seems to go against what the notes 
for the PC in the opcode list on 6502.org say. But maybe those notes are 
wrong... (after all, a pre-increment of PC, including any conditional tests 
to see if it was necessary, would have to complete in 1/4 of a clock cycle, 
as it's about half way through a clock-low period where the address lines 
go valid)

> The fact that the PC is a 16-bit increment is also probably a
> critical timing path, but I don't know if the two paths occupy the same
> cycle.

Yes, but if the above is correct then there's almost a full clock cycle in 
which to do it, which seems do-able.

I'll throw this out to classiccmp I think and just see if I can get someone 
to confirm that the CPU does indeed do a read from PC+1 immediately 
following an opcode fetch. If I've got my head around this right, a NOP 
takes two cycles but has no reason to access the bus during the second 
cycle - but a dummy read should still show up there.

cheers!

Jules