Why did some CPUs use two Read/Write lines, and others just one?

Question

Many 8-bit processors, such as Motorola's 6800 and MOS Technology's 6502 make use of a single pin to indicate to the rest of the system whether the CPU wishes to read from or write to a memory location (e.g. logic high = read, logic low = write). Other contemporary processors, including National Semiconductor's SC/MP and Zilog'z Z80 used two pins, one each for read and write operations.

This difference lead to some interesting design combinations, such as Acorn's System 1 computer, which used a 6502 CPU and National Semiconductor INS8154 I/O chip (originally designed for the SC/MP). The 6502's R/W pin was inverted and gated by the CPU clock to generate the separate NRDS and NWDS signals required by the INS8154.

I can appreciate why it would be desirable to combine the read and write signals onto a single pin, especially as you wouldn't have more than 40 pins per chip. I don't see any clear advantages of keeping them on separate pins instead, though.

What reasons would CPU designers have for choosing these different approaches?

Answer 1

What reasons would CPU designers have for choosing these different approaches?

It depends on what the designers intended to mark a valid bus cycle, which is the 'leading' signal for decoding. In a more general way, it's the design view of the bus.

Common ways (*1) are:

• The 8080 way - Marking a cycle by a one of several (*2) dedicated signals marking the type of cycle as well as its validity. RD and WR mark a read or write cycle as well as the validity of all other signals.

• The 6800 way - A dedicated signal marks the validity of an access cycle, putting all other in context. VMA (Valid Memory Address) is used to indicate a cycle. R/W defines the direction of this cycle.

• The 6500 way - Each and every clock cycle is a valid access cycle. No dedicated signal is needed, the clock signal can be used for this purpose. R/W defines the direction.

So while there is a basic difference in the way a bus is viewed between the 8080 and 6800 way, both need two signals to create a valid cycle and direction. The 8080 solution is more simple to decode in peripherals, especially if built up from general TTL, while the 6800 got a more abstract view. Both have the advantage that I/O and memory does not need to be clocked. And both offer support for DMA/bus-sharing, as well. The 8080 maybe more so than the 6800, as it includes a bus request protocol, while the 6800 only supports bus separation by tristating its signals.

The 6500 way is a simplification of the 6800 bus design (*3). By making each and every clock cycle a bus cycle (and having the CPU output a valid direction and address during that), one pin on the CPU could be saved. On the downside, non-6500 peripherals had to incorporate the clock signal into their enable decoding (*4). Then again, the latter isn't as much of an issue as it also hits the other schemes at some point as well, depending on the peripheral used.

Even more cumbersome is the fact that this simplification made DMA/bus-sharing hard, requiring external buffers and logic (*5).

---

It may be worth noting that there were many more variations that these three - as there were many more microprocessors.

(For everyone's sanity I skip the bus state controlled cycles of an Intel 8008 :))

• From a historic point of view ,the 6800 way is the most versatile and similar methods are found many mini computers as well as other microprocessors - like TI's 9900 (here called MEMory ENable).

• The Signetics/Valvo/Philips 2650 was somewhat similar, but featured in addition to a valid address line (ADRess ENable) a WRitePulse line, only triggered during write cycles - which were also announced by R/W being high. So a kind of mixture of 6800 and 8080 - satisfying both protocols for most parts. The CPU also featured a quite fine-tuned framework for bus sharing.

• Nationals SC/MP takes this a step further by using a multi-master bus protocol by default. Only when the bus is granted a bus cycle is indicated by NENOUT, followed by an address strobe (NADS) and then followed by a write or read strobe (NWDS/NRDS) (*6). Using this, and taking the many internal cycles without bus access into account, two SC/MP could be coupled in a system with almost no performance penalty.

• Speaking of weird, the RCA/Intersil CDP1802 does feature a bus design somewhat like the 8080, with separate read and write lines (MRD/MWR); these do not validate other signals, but only indicate direction ... and to some extend 'alert' components ahead of time - 5 cycles for read and two for write. The transfer itself is initiated by the TPB signal validating the lower address half - which at that point is already valid for more than 3 cycles.

  In fact, it isn't really weird, but far far away from the simplified and abstract bus designs we are used to see later.

• Even Zilog's Z80 isn't as simple as many assume. Where the 8080 signalled the type of a bus cycle during the first clock of each machine cycle (marked by SYNC), the Z80 offers separate signals to main memory (MREQ) or I/O access (IORQ), resulting in 4 pins dedicated to framing and signalling where 3 would have done been sufficient. Looks like a less than optimal middle way to keep 8080 compatibility.

• In this context Intel's 8085 changes/simplifies the 8080 bus, as now IO/M is a dedicated signal to be decoded during RD or WR. No more 8224/8228 combination needed. It's eventually the most simple form of the 'two signal' variation. Except now the address bus is multiplexed and a latch for the half transferred on the data bus (and signalled by ALE) is to be added. 40 is a fricking low number of pins anyway.

• The 8086 then continued along that way, combining both worlds: Separate RD/WR/IOM signals and multiplexed address bus with the multiplexed status signals of the 8080 ... plus even more creative encoding in maximum mode.

Bottom line, there were way more than just two ways to access memory (and even more if I/O is separate).

---

*1 - Processor names are used for simplicity of explanation and will not mark any invention or origin claim.

*2 - For the raw CPU it's only two dedicated signals RD and WR, as the split into memory and IO is only communicated by THREE status signals multiplexed on the data bus during SYNC. This word needs to be latched before decoding. A function the 8228 Bus-Driver/System controller provided - which in a clean system would as well need by the 8224 clock generator combining its PHI1 and the CPU's SYNC into a usable strobe signal (STSTB). Quite a mess, understandable the Zilog changed that part - and so did the 8085.

*3 - The 6500 development history becomes quite clear when looking at a minimum 6800 system, here Motorola suggests to combine PHI2 and VMA to create a generic Enable signal. With the 6500 design as a simplified, cost reduced 6800 focused on embedded application, having this combination already by default and saving a signal to be outputted was a clear plus - not at least by freeing up pins to make the integrated clock generator work and save even more.

*4 - On the plus side, complex 6500 I/O units will have a clock signal already present, which comes handy for any kind of timer/counter application.

*5 - Something various later spinoffs eased - all the way to the WDC65C02 reintroducing a 6800 compatible interface.

*6 - Unlike in the question implies, it's only as simple as with the 8080, when there is no other bus user and the CPU always gets its way ... and even on its own, there's the multiplexed bus and NWDS/NRDS being non-overlapping with the NADS address strobe.

Answer 2

There are three common control-signal patterns for devices that can read and write information:

1. The three-pin control pattern: /CS, /OE, and /WE. Any time chip-select is high, all other pins will be ignored. If chip-select and write-enable are low, /OE will be ignored and the device will write to the indicated address. If chip-select is low, write-enable is high, and output enable is low, the device will read the indicated address and output it onto the bus.

2. The /CS,/WE pattern behaves as above, but with /OE strapped low.

3. The /OE,/WE pattern behaves as above, but with /CS strapped low.

If all devices use pattern #1, the preferred system design will be to feed some portion of the address bus into a decoder which can start generating a /CS signal for one device before the CPU has signaled that it's ready to actually perform a read or write. The /OE and /WE signals can then be shared among all devices to indicate when a cycle should actually be performed. The downside to approach #1 is that every device would need to dedicate pins to three control signals, making those pins unavailable for other purposes.

If all devices use pattern #2, and if speed isn't critical, the encoder can be gated so that it is disabled except during the active part of a memory cycle. This can be accomplished most easily if the CPU has a single pin to indicate where the active part of a cycle is. The downside of this approach compared to #1 is that it will be necessary to either delay decoding until the active part of a cycle, or else use a dedicated gate to prevent /CS from being activated until the active part of a cycle.

Approach #3 may be useful in a system that contains many read-only devices and many write-only devices, and a limited range of address space to accommodate them. In that case, it may be helpful to have one address decoder which is active only during reads and another which is active only during writes. If there are a few peripherals that support both reading and writing, the /OE and /WE pins could be taken from the appropriate decoders. For this approach, it's probably most convenient if the main CPU has separate read and write lines.

I personally favor having the CPU provide an R/W signal and a "perform cycle now" signal. In some cases, it may be useful to have advance notice that the CPU is about to perform a write cycle (e.g. to disable any buffers that might be driving the CPU bus from an outside bus), but deriving such a signal is apt to be difficult if a CPU doesn't provide it. Generating any other kind of memory signals if one has those ones in advance will be simple by comparison.