Memory and the data bus
Memory and the data bus
How do you load programs and data in the 6502? The bidirectional data bus confuses me and I don't understand how can you keep programs and data in RAM. What if the instruction needs to output some data? How do you prevent it from flowing back into the instruction decoder? What about the timing for the PLA?
Re: Memory and the data bus
It might help to look at the cycle-by-cycle activity. That's one level below the instruction-by-instruction activity. Visual6502 is one way to do that, so for example you could study the tabulation produced with
http://visual6502.org/JSSim/expert.html ... e&steps=50
http://visual6502.org/JSSim/expert.html ... e&steps=50
Re: Memory and the data bus
An alternative source which details cycle-by-cycle behavior is Appendix A of mcs6500 family hardware manual.
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
https://laughtonelectronics.com/Arcana/ ... mmary.html
-
BigDumbDinosaur
- Posts: 9428
- Joined: 28 May 2009
- Location: Midwestern USA (JB Pritzker’s dystopia)
- Contact:
Re: Memory and the data bus
It should also be noted that data buses are bi-directional in most machine architectures, not just the 6502's.
x86? We ain't got no x86. We don't NEED no stinking x86!
Re: Memory and the data bus
(Thanks for the tabulation reference, Jeff! I find it easiest to link to visual6502 because of my browser history and my mental context. But a tabulation is more accessible.)
Perhaps the thing to note is that a bidirectional bus is one which can carry information in one direction or another. In any given cycle, at any given chip interfacing to the bus, the chip is either driving the bus or is driven by the bus. The direction is controlled ultimately by the processor's control lines, in the case of the 6502, the RnW output.
When RnW is high, the 6502 will not be driving the bus, but will be sensing it, and one chip (usually) will be driving the bus, as directed by its chip select and output enable inputs. Those inputs being controlled by the system's glue logic which ultimately has inputs such as the RnW line, the clock, some address lines. This is a read cycle, as seen from the 6502 perspective.
When RnW is low, the 6502 will be driving the bus, and all the other chips have a chance to sense the bus. This is a write cycle. Which chip, if any, responds to the write will depend on their chip selects and other control lines.
You could think of the databus as half duplex, if that term is familiar to you: it operates in either direction, but only in one direction at a time.
Perhaps the thing to note is that a bidirectional bus is one which can carry information in one direction or another. In any given cycle, at any given chip interfacing to the bus, the chip is either driving the bus or is driven by the bus. The direction is controlled ultimately by the processor's control lines, in the case of the 6502, the RnW output.
When RnW is high, the 6502 will not be driving the bus, but will be sensing it, and one chip (usually) will be driving the bus, as directed by its chip select and output enable inputs. Those inputs being controlled by the system's glue logic which ultimately has inputs such as the RnW line, the clock, some address lines. This is a read cycle, as seen from the 6502 perspective.
When RnW is low, the 6502 will be driving the bus, and all the other chips have a chance to sense the bus. This is a write cycle. Which chip, if any, responds to the write will depend on their chip selects and other control lines.
You could think of the databus as half duplex, if that term is familiar to you: it operates in either direction, but only in one direction at a time.
Re: Memory and the data bus
BigEd wrote:
(Thanks for the tabulation reference, Jeff! I find it easiest to link to visual6502 because of my browser history and my mental context. But a tabulation is more accessible.)
Perhaps the thing to note is that a bidirectional bus is one which can carry information in one direction or another. In any given cycle, at any given chip interfacing to the bus, the chip is either driving the bus or is driven by the bus. The direction is controlled ultimately by the processor's control lines, in the case of the 6502, the RnW output.
When RnW is high, the 6502 will not be driving the bus, but will be sensing it, and one chip (usually) will be driving the bus, as directed by its chip select and output enable inputs. Those inputs being controlled by the system's glue logic which ultimately has inputs such as the RnW line, the clock, some address lines. This is a read cycle, as seen from the 6502 perspective.
When RnW is low, the 6502 will be driving the bus, and all the other chips have a chance to sense the bus. This is a write cycle. Which chip, if any, responds to the write will depend on their chip selects and other control lines.
You could think of the databus as half duplex, if that term is familiar to you: it operates in either direction, but only in one direction at a time.
Perhaps the thing to note is that a bidirectional bus is one which can carry information in one direction or another. In any given cycle, at any given chip interfacing to the bus, the chip is either driving the bus or is driven by the bus. The direction is controlled ultimately by the processor's control lines, in the case of the 6502, the RnW output.
When RnW is high, the 6502 will not be driving the bus, but will be sensing it, and one chip (usually) will be driving the bus, as directed by its chip select and output enable inputs. Those inputs being controlled by the system's glue logic which ultimately has inputs such as the RnW line, the clock, some address lines. This is a read cycle, as seen from the 6502 perspective.
When RnW is low, the 6502 will be driving the bus, and all the other chips have a chance to sense the bus. This is a write cycle. Which chip, if any, responds to the write will depend on their chip selects and other control lines.
You could think of the databus as half duplex, if that term is familiar to you: it operates in either direction, but only in one direction at a time.
Re: Memory and the data bus
Did you read Jeff's link for the tabulations of cycle by cycle activity? Every access takes a cycle, every byte needs an access. If an instruction is formed of an opcode and an operand, then yes, the multiple bytes will take multiple accesses which need multiple cycles.
Re: Memory and the data bus
BigEd wrote:
Did you read Jeff's link for the tabulations of cycle by cycle activity? Every access takes a cycle, every byte needs an access. If an instruction is formed of an opcode and an operand, then yes, the multiple bytes will take multiple accesses which need multiple cycles.
Re: Memory and the data bus
Dr Jefyll wrote:
An alternative source which details cycle-by-cycle behavior is Appendix A of mcs6500 family hardware manual.
Re: Memory and the data bus
What's the point of having a Program Counter with a Von Neumann CPU like the 6502? I thought RAM was *RANDOM*.
Re: Memory and the data bus
You misunderstand Random Access (and you're not the first to do so!) It is to be compared to the predecessor technologies: sequential (or cyclical) memories. Things like drums and delay lines, also tapes. With these technologies, non-sequential accesses are much more time-consuming.
I think pretty much any von Neumann machine has a program counter.
I think pretty much any von Neumann machine has a program counter.
Re: Memory and the data bus
BigEd wrote:
You misunderstand Random Access (and you're not the first to do so!) It is to be compared to the predecessor technologies: sequential (or cyclical) memories. Things like drums and delay lines, also tapes. With these technologies, non-sequential accesses are much more time-consuming.
I think pretty much any von Neumann machine has a program counter.
I think pretty much any von Neumann machine has a program counter.
Re: Memory and the data bus
I don't quite understand the question.
One common mistake, or confusion, which comes up from time to time, is confusing the Program Counter with the Address Bus. The Program Counter, from a software perspective, takes on successive values which are the addresses of successive instructions. Usually these are increasing by 1, 2 or 3, depending on the instruction. When a branch, subroutine call, jump, or interrupt happens, the PC value is updated accordingly.
Internally, the Program Counter can either increment or be reloaded. For a 3 byte instruction it will be incremented three times, in 3 of the cycles which the instruction needs. But you never see these intermediate values, from a software perspective.
The Address Bus always gives the address of the current access. That might be the read of an opcode, a read of an operand, a data read or write, or a dummy read or write. These addresses are not in general sequential or related. In the case of accessing the two bytes of a pointer in zero page, they will be, likewise in the case of multiple accesses to the stack, or the case of reading a vector from the top of memory. Probably other cases too.
One common mistake, or confusion, which comes up from time to time, is confusing the Program Counter with the Address Bus. The Program Counter, from a software perspective, takes on successive values which are the addresses of successive instructions. Usually these are increasing by 1, 2 or 3, depending on the instruction. When a branch, subroutine call, jump, or interrupt happens, the PC value is updated accordingly.
Internally, the Program Counter can either increment or be reloaded. For a 3 byte instruction it will be incremented three times, in 3 of the cycles which the instruction needs. But you never see these intermediate values, from a software perspective.
The Address Bus always gives the address of the current access. That might be the read of an opcode, a read of an operand, a data read or write, or a dummy read or write. These addresses are not in general sequential or related. In the case of accessing the two bytes of a pointer in zero page, they will be, likewise in the case of multiple accesses to the stack, or the case of reading a vector from the top of memory. Probably other cases too.
Re: Memory and the data bus
BigEd wrote:
I don't quite understand the question.
One common mistake, or confusion, which comes up from time to time, is confusing the Program Counter with the Address Bus. The Program Counter, from a software perspective, takes on successive values which are the addresses of successive instructions. Usually these are increasing by 1, 2 or 3, depending on the instruction. When a branch, subroutine call, jump, or interrupt happens, the PC value is updated accordingly.
Internally, the Program Counter can either increment or be reloaded. For a 3 byte instruction it will be incremented three times, in 3 of the cycles which the instruction needs. But you never see these intermediate values, from a software perspective.
The Address Bus always gives the address of the current access. That might be the read of an opcode, a read of an operand, a data read or write, or a dummy read or write. These addresses are not in general sequential or related. In the case of accessing the two bytes of a pointer in zero page, they will be, likewise in the case of multiple accesses to the stack, or the case of reading a vector from the top of memory. Probably other cases too.
One common mistake, or confusion, which comes up from time to time, is confusing the Program Counter with the Address Bus. The Program Counter, from a software perspective, takes on successive values which are the addresses of successive instructions. Usually these are increasing by 1, 2 or 3, depending on the instruction. When a branch, subroutine call, jump, or interrupt happens, the PC value is updated accordingly.
Internally, the Program Counter can either increment or be reloaded. For a 3 byte instruction it will be incremented three times, in 3 of the cycles which the instruction needs. But you never see these intermediate values, from a software perspective.
The Address Bus always gives the address of the current access. That might be the read of an opcode, a read of an operand, a data read or write, or a dummy read or write. These addresses are not in general sequential or related. In the case of accessing the two bytes of a pointer in zero page, they will be, likewise in the case of multiple accesses to the stack, or the case of reading a vector from the top of memory. Probably other cases too.
Re: Memory and the data bus
But what if the CPU needs to retrieve data from some address and then go back to the program line?