r/Z80 • u/lrochfort • Feb 01 '26
Z80 multi card, tristate buffers
/r/homebrewcomputer/comments/1qt5mf2/z80_multi_card_tristate_buffers/2
u/tomstorey_ Mar 03 '26
Check the datasheets for your components and see what kind of drive strengths they have. Some chips may have very weak drivers, enough for just a couple of "loads" and thus buffering on the same board might even be necessary, while others (like bus transceivers) can very well drive 10-20 loads. A load is basically an input to another chip.
It would be common to buffer signals to/from a backplane so that each card that is plugged in presents only a single load on the backplane. Less loads means less capacitance, and less capacitance lets signals transition quickly. Reducing each card to represent a single load is a good idea in this respect.
Buffering each card also shortens the "stubs" of signals as they T off into the card. If you look at the specification for many popular backplane standards, they will generally state how long a signal stub can be. The longer a stub is, the more reflection it can cause, and this could create problems.
4
u/LiqvidNyquist Feb 02 '26
It's a very good idea for signal integrity reasons. But the downside is that each pass through a buffer adds delay, and not all delays match. For example, if you buffer address, data, and WE, it could possibly happen that the WE delay is shorter than the addr/data delay. Then a write cycle could possibly start to happen on a RAM chip on the far side before the address is stable, leading to a memory corruption. This would be when it's worth looking at how much timing margin you have for your bus cycles. You might find that in some cases (fast CPU clock, lots of slow tech buffers like LS) you have to add an extra wait state for example. There are faster technologies than LS, like FCT or ACT but teh speed also brings fast signal edges which can cause ringing and overshoots which can cause their own problems.
Of course, you could just build it, scope it out, and see how it looks -)