6502.org

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?

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

An alternative source which details cycle-by-cycle behavior is Appendix A of mcs6500 family hardware manual.

It should also be noted that data buses are bi-directional in most machine architectures, not just the 6502's.

(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.

What if the instruction requires parameters? Would it use multi cycle or is there any secret?

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.

Ah, I see. Thanks!

Thanks!

What's the point of having a Program Counter with a Von Neumann CPU like the 6502? I thought RAM was *RANDOM*.

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.

But then, how do you store the program and data?

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.

Ooh, I understand it now, thank you so much!

But what if the CPU needs to retrieve data from some address and then go back to the program line?