Buffers and latches... when and how do I use them?

[GunPilot]

I'm still unclear on exactly when to use a buffer or a latch, or a transceiver in a typical 6502 design. I don't really understand the difference between a buffer or latch, or how they work. Can some of you smart experienced guys give a rookie a primer?

[BigEd]

In a very small design you probably don't need any of them, but:
- a buffer will add drive to a signal. You'd use one when you are driving a lot of loads, or a long distance, or both, and your signal is unidirectional, like an address bus or the clock. You might use a buffer to delay a signal but that's not robust and needs care.
- a tristate buffer acts as a buffer and can also not drive the output (that is, let the output be driven by something else.) This is good for time-sharing a bus, for example the CPU needs to drive the addresses of a RAM chip, and so does the video chip. (But not both at the same time.) Both drivers can use a tristate buffer to drive a shared bus.
- a transceiver acts as a bidirectional buffer: it drives in one direction or the other, depending on a control input. That's useful for a long distance or highly loaded data bus, where the CPU might need to read or write data to the RAM
- a latch has a clock input and can hold a value. One use is to hold the top 8 bits of the address value in a 65816 system, where the databus drives this value for just the first half of a clock cycle, and then reverts to normal bidirectional data mode for the second half.

For a simple design, see http://searle.hostei.com/grant/6502/Simple6502.html

The later CMOS versions of the 6502 have pretty high drive, and we rarely build multi-board RAM systems these days, so buffering of signals is done less than it used to be.

[BigDumbDinosaur]

Good synopsis, Ed.

Since you mentioned use of a latch with the 65C816 to capture the bank bits, I will mention that a transceiver is also used on the data bus so that the latter itself does not see the bank bits during Ø2 low. It appears that this is an essential requirement if any of the WDC periperhals (6521, 6522 and 6551) are part of the machine.

[Dr Jefyll]

BigEd wrote:

You might use a buffer to delay a signal but that's not robust and needs care.

Right -- using a buffer to delay a signal is not a robust solution (because the amount of delay is variable, rather than exactly predictable). Hope you don't mind me clarifying, Ed.

BigDumbDinosaur wrote:

It appears that this is an essential requirement if any of the WDC periperhals (6521, 6522 and 6551) are part of the machine.

If you're not sure, perhaps your post would've been better framed as a question, BDD. Can you explain why any peripherals, 65xx or otherwise, mustn't see the bank bits which an '816 outputs on the data bus during Ø2 low? Although 65xx peripherals are somewhat quirky in that they need their address inputs, chip selects and R/W valid upon the start of Phase 2, that's irrelevant to goings-on of the data bus.

cheers,
Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

BigDumbDinosaur wrote:

It appears that this is an essential requirement if any of the WDC periperhals (6521, 6522 and 6551) are part of the machine.

If you're not sure, perhaps your post would've been better framed as a question, BDD. Can you explain why any peripherals, 65xx or otherwise, mustn't see the bank bits which an '816 outputs on the data bus during Ø2 low? Although 65xx peripherals are somewhat quirky in that they need their address inputs, chip selects and R/W valid upon the start of Phase 2, that's irrelevant to goings-on of the data bus.

During the 65C816's Ø2 low cycle, and as soon as the address is valid (VDA || VPA is true), selection of a peripheral device is possible. If, say, a 65C22 is selected during what is a write cycle, it isn't in the high-Z state and hence will see the bank bits as data. The timing diagram doesn't really make it clear as to whether such a condition is an issue. Use of the bus transceiver as depicted on page 46 of the 65C816 data sheet would assure that the 'C22 can't be confused by the bank bits. Hence my use of "It appears..."

This should not be a matter of concern with peripheral silicon that has separate /CS, /OE and /WE control inputs, as the latter two can be gated by Ø2 so the device doesn't connect to the data bus when Ø2 is low. That is how I arranged it in POC.

[Dr Jefyll]

BigDumbDinosaur wrote:

The timing diagram doesn't really make it clear as to whether such a condition is an issue. Use of the bus transceiver as depicted on page 46 of the 65C816 data sheet would assure that the 'C22 can't be confused by the bank bits. Hence my use of "It appears..."

This should not be a matter of concern with peripheral silicon that has separate /CS, /OE and /WE control inputs, as the latter two can be gated by Ø2 so the device doesn't connect to the data bus when Ø2 is low.

Now I see what you're getting at. You're contrasting the Ø2 and R/W interface used on 65xx peripherals with the /RD and /WR (aka /OE and /WE) arrangement used on many non-65xx devices. And it's the peripheral datasheet you need to be looking at, not the '816 datasheet.

It's true there'd be a problem if a peripheral device connected to the data bus when the '816 CPU's Ø2 is low. And, as you say, with peripheral devices featuring the /RD & /WR interface the problem can be avoided by gating those signals with Ø2 (externally, as on the POC).

The same principle applies with 65xx peripherals. However, with 65xx devices the gating is internal -- no external gates are required. They will not input or output data when Ø2 is low. The 65c22 datasheet spills the beans.

from page 46 of WDC's 65c22 datasheet

w65c22 data sheet 2010 Sep.pdf

(727.44 KiB) Downloaded 102 times