Deleted 6502timecodes.txt: content moved to the visual6502 wiki.

Documentation is more appropriately stored there instead of the repository.
It is also further developed there:
http://visual6502.org/wiki/index.php?title=6502_Timing_States
This commit is contained in:
mmfoerster 2017-10-25 11:39:23 -04:00
parent c1409b78cb
commit 76edc1186a

View File

@ -1,126 +0,0 @@
6502 Time codes.
There are two things that are critical for correct instruction execution in
the 6502 (indeed, for any CPU chip): the pattern of bits in the instruction
register AND the pattern of "time code" bits from the timing control block of
circuits.
Both sets of bits (IR and time code), in combination, control the output
bits of the PLA block of circuits. PLA outputs, in turn, affect the RCL block
of circuits, and their control outputs directly operate the connections among
the registers, busses, and ALU on the other end of the chip die to actually get
the instructions' work done.
The 6502's timing control has ten states (effectively) and six explicit
output bits. Only the explicit output bits affect the PLA. The output bits are
labelled T0, T+, T2, T3, T4, and T5. The bits are considered active when their
logic states are low. There are two states where two of these explicit output
bits are active at the same time. There are also two states where none of the
explicit output bits are active. All other states have only one output bit
active at a time.
The two states with two bits active together are T0 with T+, and T0 with T2.
The two states with all explicit bits inactive are referred to as T1 and T6.
Those two states can only be distinguished within the timing control block of
circuits by paying attention to a logic node that is responsible for clearing
(making inactive) the explicit output bits T2 through T5. The clearing node
at logic high (active) corresponds to the T1 state, and low corresponds to the
T6 state. For the visual6502, this is node 1357.
The notation developed for trace/debug output, and the notation presented
hereafter in this document, lists the explicit output bits in numeric order
followed by square brackets around the non-explicit internal state of T1 or T6.
When one or more of the explicit bits is active, the square bracketed label will
be blank.
Wherever one of the explicit bits is inactive, a blank placeholder of ".."
is present for it. This also applies to the bracketed label.
For example, the T0 state is presented as:
T0 .. .. .. .. .. [..]
...and the T1 state is presented as:
.. .. .. .. .. .. [T1]
The low-profile "blank" notation of ".." assists visual examination of
trace/debug output by keeping consistent placeholders for bits when they are
inactive, with minimized visual clutter. Aligning everything in fixed positions
contributes to rapid recognition of changes.
Time codes seen around instruction execution
All instructions, with a few exceptions, always end with T0 in their time code
for the last cycle. The presence of T0 indicates, "last cycle".
The strictly 2-cycle instructions always end with the time code:
T0 .. T2 .. .. .. [..]
All other instructions end with the time code:
T0 .. .. .. .. .. [..]
The mentioned exceptions to last-cycle T0 time codes are the conditional branch
instructions. When they do not take the branch, their last cycle time code is:
.. .. T2 .. .. .. [..]
When they do take the branch, and the branch does not cross a memory page, their
last cycle time code is:
.. .. .. T3 .. .. [..]
When the branch instructions take the branch, and the branch crosses a memory
page, they end with a T0 last cycle just like all the other instructions do.
Instructions that vary in the number of cycles required to execute, other than
the conditional branch instructions, end with a T0 cycle for both the minimum
and maximum execution duration. This covers instructions that use indexed
addressing modes that require one more cycle when page crossing is required to
access the correct memory address. This situation is already covered by
statements above ("All instructions ... always end with T0..."): it has been
specifically (re)stated here for such instructions for reassurance emphasis.
For all instructions, if the previous instruction's last cycle was a cycle with
T0 in it, its opcode fetch cycle will be a time code of:
.. T+ .. .. .. .. [..]
If the previous instruction's last cycle did not have T0, its opcode fetch cycle
will be a time code of:
.. .. .. .. .. .. [T1]
Restated, instructions begin with T1 instead of T+ after a conditional branch
instruction that did not branch, or that branched without page crossing.
Instructions appear to work equally well either way. This is because a new
instruction's first actions do not begin during opcode fetch. Their earliest
effect can be only in the first half of the next cycle, T2, when the IR is set
from the predecode register.
This implies that an instruction's actions may extend as far as the second half
of the opcode fetch of the next instruction, in concert with the T+ time code
bit. Not all instructions may necessarily use this: it could be an unused
constraint for some instructions.
Branch instructions definitely don't use T+ or T0 (since two cases out of three
don't even cause those time codes to arise).
In sequence, all of the possible time codes during normal instruction execution
are:
.. T+ .. .. .. .. [..] OR .. .. .. .. .. .. [T1]
.. .. T2 .. .. .. [..] OR T0 .. T2 .. .. .. [..]
.. .. .. T3 .. .. [..]
.. .. .. .. T4 .. [..]
.. .. .. .. .. T5 [..]
.. .. .. .. .. .. [T6]
T0 .. .. .. .. .. [..]
The time code:
T0 T+ .. .. .. .. [..]
arises when RES is down when a T0 phase 1 clock state is clocked in. This can
be either the T0 that is usually scheduled for an instruction's last cycle, or
the T0 caused by instruction abort (later caused by the RES).