# Why do these resistors decouple the two databuses?

The ZX Spectrum is a computer with a Z80 accessing ROM and two separate areas of RAM, one of which is also accessed by a ULA which generates video. If the Z80 wants to access the video RAM, it may be slowed down to fit in with the timing imposed by the ULA.

This means

1. The Z80 has a bus connecting it to the three areas of memory.
2. The ULA has a bus connecting it to the video RAM.
1. These two buses are connected.
2. These two buses are independent.

According to this web-page there are resistors decoupling the buses. I need to understand why this is possible.

The ULA with the lower 16K of RAM, and the processor with the upper 32K RAM and 16K ROM are working independently of each other. The data and address buses of the Z80 and the ULA are connected by small resistors; normally, these do effectively decouple the buses. However, if the Z80 wants to read or write the lower 16K, the ULA halts the processor if it is busy reading, and after it's finished lets the processor access lower memory through the resistors. A very fast, cheap and neat design indeed!

By my understanding, these resistors somehow mean that the ULA can read a byte from the memory (the video RAMs are driving the bus) at the same time as the Z80 is reading or writing the bus (i. e., the Z80 or the DRAMs are driving the bus).

So let's take some examples:

1. The CPU wants to read from the memory. The ULA determines that this read is not going to interfere with the ULA (perhaps the read is for a different area, the upper 32K or the ROM, to which the ULA has no access) so the ULA does not assert /WAIT, and the read goes ahead.
2. The CPU wants to read from the memory. The ULA determines that this read will interfere with video generation, so it asserts /WAIT and the read is delayed.

In the first case, the CPU has put an address on the bus, and the ULA must see this to determine whether or not to assert /WAIT. Why doesn't this interfere with the fetching of the video data?

If the ULA did not assert /WAIT, it's either because the bitmap is not being fetched at this time (maybe horizontal retrace or something) so that case is not interesting, or it could be because the CPU wanted to access the ROM or another memory. In this latter case, both video memory and either the Z80 or the ROM or the DRAM are driving the databus. Why don't these subsystems interfere with each other then?

Maybe my whole question boils down to "how does decoupling work?" because when I've seen decoupling in the past, it's involved capacitors not resistors.

First, note that the ZX Spectrum ULA doesn't drive the Z80A MPU's /WAIT pin. Instead, the ULA drives the Z80A CLK pin and holds that HIGH to stop the Z80A.

The series resistors weaken the drive current from the Z80A output pins to the RAM ICs. The ULA drives the RAM address pins directly, with a much stronger current capability than that from the Z80A series resistors.

So:

• When a Z80A resistor drives a pin HIGH, the ULA can also drive the pin HIGH or sink the resistor current to GND to drive the pin LOW.
• When a Z80A resistor drives a pin LOW, the ULA can also drive the pin LOW or source the resistor current to VDD to drive the pin HIGH.

Effectively, the Z80A has been disconnected from the bus briefly and is sleeping.

And when the ULA is not using the bus, it takes its own pins to high-impedance and effectively disconnects itself from bus driving.

Remember that the ULA needs CLK-immediate RAM access for display-synchronised memory reading with no read FIFO. So the Z80A /WAIT pin cannot be used. /WAIT doesn't just stop the CPU whatever it's doing. It only works during a data transfer i.e. an instruction read or a read/write to memory or I/O. Too much of the time isn't during a transfer.

Equally, the Z80A /BUSRQ and /BUSACK pins cannot be used. /BUSRQ requests that the Z80A tri-state and relinquish its bus then assert /BUSACK but this will happen at the end of the current instruction. This may be over 20 CLKs after the /BUSACK.

• Oh you're right. The ULA does not assert /WAIT, but instead drives the clock. But some clones use /WAIT instead. Thanks for the great answer. Apr 9 at 11:46
• @OmarL, you're very welcome. Remember though that /WAIT only works during a data transfer i.e. an instruction read or read/write to memory or I/O. /WAIT it doesn't just stop the CPU whatever it's doing. The ULA needs CLK-perfect access to the RAM so /WAIT would be no use, too much of the time isn't during a transfer. Apr 9 at 12:23