6502 interrupts page

[ulfalizer]

RichTW wrote:

ulfalizer wrote:

All reads/writes output the address during φ1+φ2 and perform the transfer during φ2 btw, and every cycle is either a read or a write cycle.

Another doubt though - if this is the case, then during a read cycle, why does the data bus already have the fetched value during φ1?

I think it's because the r/w line is held high (signifying a read) all the time during a read. That means that the external device being read from will output the value as soon as it can (it doesn't know that the 6502 will read the value during the second half of the cycle, and there's no harm in outputting the value earlier than that).

[RichTW]

Of course! That makes perfect sense - cheers!

ulfalizer wrote:

As an example, the pointless sequence LDA #0; LDA #1 would then be executed as

Fetch LDA imm opcode
Decode LDA imm opcode and fetch operand
Transfer operand to A and fetch LDA imm opcode
Decode LDA imm opcode and fetch operand
Transfer operand to A and fetch next opcode
...

That still doesn't explain why the final cycle is called T0 though.

Yep, I'd agree with that, but I can't really make it tally with the results in Visual 6502, in the sense that it's not clear to me what operation is performed in each of T0, T1 and T2 of LDA #imm. If it were simply:

T0 = fetch opcode
T1 = fetch operand
T2 = transfer to A

it would make perfect sense, but with T0 at the end, I'm stuck.

[ulfalizer]

Yeah, not sure about the numbering on those steps either.

[BigEd]

Just a quick note to point out another wiki page, which shows the sync pin (as we know it) labelled T1:
http://visual6502.org/wiki/index.php?ti ... atic_Notes

My guess would be this: T1 was called that because it is the first cycle of an instruction - even though the CPU doesn't see the instruction in this cycle, it has to put the right address out. T0 was called that because it is the cycle before T1 - the cycle in which the CPU has to determine the address of the next instruction in order to get it off-chip in the following cycle.

Possible a better method would be to look at which columns of the PLA respond to the T0 input... but I'm not sure about that. See http://visual6502.org/wiki/index.php?ti ... Decode_ROM

(As for the read data from off-chip arriving right at the beginning of the cycle in visual6502 - think of that as an artifact. It does indeed model a very fast peripheral.)

Cheers
Ed

[RichTW]

Thanks Ed.

Knowing that the opcode fetch happens in T1 gives me a new perspective, and I can kind of see how the state machine works with respect to 2 cycle instructions like LDA #imm which have this peculiar T0+T2 state.

In the following sequence:

Code: Select all

LDX #1
LDA #2
ADC #3
STA 41

We end up with the following operations:

Code: Select all

T1    Fetch LDX #
T0+T2 Fetch #1
T1    Store 1 in X   Fetch LDA #
T0+T2                Fetch #2
T1                   Store 2 in A   Fetch ADC #
T0+T2                               Fetch #3
T1                                  Perform A+3    Fetch STA zp
T2                                  Store 5 in A   Fetch 41
T0                                                 Store A in 41
T1                                                 --

I think the key is to realise that the opcode fetch doesn't count as part of that instruction - in T1, the IR still contains the previous opcode and so should be treated as part of the previous instruction. T2 is the start of a new instruction, as already stated in the document on the Visual6502 wiki.

Why do we need the T0+T2 state? My guess is that there are PLA lines which always fire for T0 and T2 to perform standard operations, e.g. poll IRQs for T0, and fetch the following byte for T2, both of which need to be done simultaneously in a 2 cycle op. How does it know that we need to go into this superposition of states? No idea.

In the case of LDA #imm, the only additional operation to be done is in T1, to load the accumulator with the value on the data bus.

The thing I can't figure out now is how, in the case of ADC, it gets its fourth operation decoded (to transfer the ALU result to A). By the time it gets there, the IR already contains the following instruction and is back on T2 again. Any ideas?

Edit to add: Looking at the PLA lines, it looks as if the operations which don't tie up the databus are triggered a cycle earlier than I expected, e.g. the transfer from DB to A in LDA #imm seems to happen in T0 rather than T1. Not sure how this is working if the value isn't actually there yet, but I guess it's relying on some kind of propagation delay or something. But at least that explains how ADC #imm is able to perform its final two steps in T0 and T1.

[ulfalizer]

That ADC imm example makes it look like some four-cycle instructions can be reduced to two cycles too if they don't need access to the data bus during the final two cycles, which is pretty cool. It probably uses some more internal state in addition to the State to make that work out right.

Like BigEd said, T0 might be the "determine what to do next" state (which can overlap useful work). It's where it decides whether to fetch an instruction or handle an interrupt.

I rephrased the interrupts page to talk about the edge and level detector btw. Hopefully clearer now.