An important innovation for dynamic RAM was multiplexing address lines, so a 2^N-bit chip only needs N/2 address pins, which helps keep cost down.

Why didn't CPUs match this?

Setting aside e.g. the 6502 which was often used with small static RAM chips, looking at e.g. the 68000 which was always going to be used with 16k or 64k DRAMs. It has 24 address pins. Presumably extra circuitry is needed to convert this to multiplexed form for the DRAMs.

Why not have the CPU provide the multiplexed signals directly? This would achieve the same result but save money twice, fewer pins on the CPU, less supporting circuitry.

  • 1
    What was the size of the total address space? You don't need 24 bits to store a 64K address. Commented Jun 5 at 15:42
  • 1
    So what happens when the 68000-or-whatever strays into a part of memory backed by ROM? Or a peripheral? Why is it simpler to demultiplex there than to multiplex while it's in RAM?
    – Tommy
    Commented Jun 5 at 15:50
  • 1
    @Tommy Err, ROM etc. chips could as well be multiplexed. So
    – Raffzahn
    Commented Jun 5 at 21:46
  • 2
    @JessFuckett The 68000 could address 16 Megabytes.
    – JeremyP
    Commented Jun 6 at 8:51
  • 1
    @Tommy No. the point is that type of memory doesn't make a difference in your scenario. The multiplexing with DRAM is that it uses those parts in sequence due the stages nature DRAM access works. Thus multiplexing can be done without loss of access speed. In case of ROM it would slow access down. That's why everything except DRAM grew by adding one pin per address bit, while DRAM does so one pin per two bits.
    – Raffzahn
    Commented Jun 6 at 11:28

7 Answers 7


TL;DR: It's all about when which information is needed

DRAM uses addresses differently to other components, due to the way it's organized. To access a memory cell, DRAM needs to address first a row and only after that a column within that row (*1). Thus DRAM naturally never needs the whole address at once, but one after the other. Having it delivered in two parts saves pins without giving up speed.

DRAM address-in is a different use case than CPU address-out.

In contrast, a CPU should provide all address lines at once as external address decoding might need all of them. Splitting in turn would always slow down access, by needing two cycles instead of one. Not to mention that address decoding might need more than just a part of the address before being able to forward it to any device.

There are of course CPUs, like the mentioned 1802, that multiplex address lines, but their multiplexing is usually defined by the way the CPU is organized. More well relevant to the case you're making might be Intel's 8008 which was really about saving as many pins as possible- It multiplexed 14 bit address and 8 bit data over a single 8 bit bus. For any memory access the CPU first outputs in T1 the lower 8 address bits, then in T2 the higher 6 plus two bits marking the access, followed by T3 for reading or writing the addressed data. All using the same 8 pins (*2)

Bottom line: It doesn't make much sense to multiplex address output of a CPU.

What in turn does make much sense is multiplexing address and data - and it does for much of the same reason as with DRAM: Any device being addressed to provide data will need time to fetch and provide that data after receiving an address - aka access time - thus providing an address ahead of (reading) data is needed anyway.

Bus design is as much about access sequence as it is about pins or signals needed.

But just for a moment let's assume multiplexing would be a generic use case for CPUs address-out:

Just imagine a CPU with 64 KiB address space using an 8 pin address bus. Its 16 address bits would be delivered as A8..A15 and A0..A7. Now let's connect some 16 KiB (4116) RAMs. They require 14 Address bits over 7 address lines, delivered as A13..A7 and A0..A6.

To select the 4116's 2x7 address bits from the 2x8 CPU address lines it would need to take 6 bits from the upper 8 plus the lower 8 and rearrange them into 2x7. So a whole cycle of demultiplexing and remultiplexing is needed - a transfer of a single CPU address would thus need 4 steps instead of one.

Now imaging other memory sizes as well ... each needing its own multiplexer type ... not exactly helpful, or is it?

So, beside the basic considerations, multiplexing only makes sense if both sides are using the same number of pins and address chunks. With any other, the effort would double compared to the way it is.

*1 - This two step access is because the row needs to be loaded into the read/amplify/refresh buffer before a bit can be selected from there and presented at data out

*2 - IN and OUT was even more wierd. With OUT the CPU first outputs the data (content of A) and then the port address (in form of the OUT instruction used). IN does as well first output A, then the port address followed by reading data (into A). A nice order that may allow reading and setting of a port in a single instruction, or handing over a selector first.

  • 2
    +1 for your last section; it's the issue that came to my mind when reading the question. Memory chips have always been getting bigger, so any choice for the number of address lines per cycle will quickly become obsolete, requiring the remultiplexing scenario you describe.
    – DrSheldon
    Commented Jun 6 at 9:45
  • 1
    The last section sets up a straw man that's easy to knock down: While it is conventionally done, there's no particular reason that the memory row addresses and column addresses need to come from contiguous parts of the CPU's logical address. Use A[14:8] as the row address, use A[6:0] as the column address, and use A[15] and A[7] to determine which bank of chips to enable onto the data bus.
    – Dave Tweed
    Commented Jun 6 at 12:06
  • 2
    @DaveTweed Are you sure it is? Have you thought about systems where not all address space is filled with RAM? Your configuration with just 16 KiB populated would split each 256 Byte block of memory between 0h and 7FFFh into 128 bytes of RAM and 128 bytes of nothing. Seems less than great, or does it? Not populating the whole address space is still a common situation. :)
    – Raffzahn
    Commented Jun 6 at 14:04

Many CPUs did multiplex address pins in a variety of ways. Multiplexing address pins with each other, as was done on e.g. the CDP1802, means that unless the CPU multiplexes things in the exact same way as necessary to operate the memory, a memory cycle generally won't be able to start until after the CPU has output both halves of the memory address. If one wanted to design a CDP1802-based system with a bank of 64K DRAMs, or with two banks of 32Kx8 DRAM, then the multiplexing could work out favorably (start a row address in both banks during the first half of each cycle, and use the second half to select both the bank to use for column access and the column within that bank) but in general such multiplexing would slow things down since a DRAM row address would normally involve some bits from the lower half of an address.

Multiplexing the address bus with part of the data bus as was done on the 8088 may often work out better, since the data bus is only needed during the latter part of an address cycle, but may still introduce delay because the CPU can't start a new cycle after a read after whatever is driving the bus has released it. When using asynchronous DRAMs, this isn't as much of a problem as the delay when starting a cycle since DRAMs need some time to finish up each operation before they can start the next one, but when using newer memory technologies such a design will slow things down.


Many CPUs did have a multiplexed bus, but not in a way compatible with DRAMs that mux the address bus.

CPUs that had multiplexed bus usually multiplexed half of the 16-bit address bus bits with 8 data bits. This makes it faster as you can set up a 16-bit address to bus first in first phase and latch the 8 bits with a simple IC and then switch the 8 bits for data read or write transfer for the second phase - no overlap there and the address on the bus can't anyway change during the bus cycle.

If the address bus were muxed like how DRAMs worked, it would have needed to anyway set up the 16-bit address in two phases and yet use third phase for the data after address has been stable for long enough.

To use any standard ICs with unmuxed address bus, the muxed address bus would have needed to be available in an unmuxed fashion for them anyway.


This is for the 6502 and 68000 days you're asking about...

For a microprocessor (MPU), using multiplexed address lines slows memory access down. MPU performance was a/the major selling point for the MPU manufacturers. They preferred to pin-out their highest-performance bus, then provide bus slow-down input pins that add wait states during a read/write.

If the MPU has internal address muxing, that would need to include the refresh logic too, and have the muxing scheme the DRAM's using. All that is tied to the DRAM architecture and DRAM was advancing quite rapidly at that time, with different schemes like Fast Page Mode (FPM) and Early Data Out (EDO) coming along.

It seems the manufacturers preferred to implement a general-purpose performance bus and leave external circuitry to provide the particular interface to the particular memory it's using. That must have seemed a much safer route than second-guessing what DRAM interface might be cheap and plentiful in the years ahead. Or what other memory technology might have come along. Chip design and evolution was expensive and time-consuming. They wouldn't want to end up wasting the precious few gates they had in those ICs on a special memory interface that might not get used in the future.

Some MPUs used muxed address/data buses but not many of the high sellers. The few that did include the 8088/8086 and 80186/80188 MPUs. The 8051, a microcontroller, did but it traded performance for versatility, with the pins saved by muxing being used for I/O instead.

  • 1
    8018x even there, derived emedded versions had the possiility to have demultiplexed busses. The AMD Am186EM for example could work in classical multiplexed mode or could also be wired to give a separate data and address bus. Commented Jun 6 at 8:48

Most modern CPUs do indeed do this -- they have memory interfaces that connect directly to DDR SDRAM, and can be configured to match the specific memory chips in use. The transistors required to do this are a tiny fraction of the billions of transistors already on the chip, and the logic delay within the CPU chip is swamped by the relatively large access time of the external memory.

So taking your question in the context of retrocomputing, you're asking why didn't they do this back in the day? The answer is pretty much the same — transistor densities and clock speeds were not high enough to justify doing it.

Interestingly, some of the earliest CPUs (4004, 4040, 8008) did multiplex their addresses over the same pins used for the data bus, but not for the purpose of optimizing DRAM access. They simply wanted to keep the pin count as low as possible. As a result, the 4004/4040 required 8 clock cycles per machine cycle, and the 8008 required 4 or 5 clock cycles.


By way of an aside, IIRC, all of Digital's single chip VAX processors multiplexed the 32 bit address and data busses onto one set of 32 pins (the Data and Address Lines, or DAL).


As others noted, the 1802 (which I used to wire wrap my first computer) multiplexed the high and low address bytes.

But it was slow, even compared to CPUs of its day, using eight clocks per machine cycle. (it was generally clocked at 1-2mhz, so 125-250k cycles/second).

Memory chips of the time were far faster than the 1802. So a couple of early clocks put out the address, and the separate data bus would be used on a later clock.

On more mainstream 8 bit machines, such as the 8080 and 6502, there was still enough time, but they were using either two-phase (8080) or single phase (6502) clocks, so far less "notches" for actions to take place. The 6502 popped out address early and read late in the cycle, I want to say (but don't hold me to it) that the 8080 wrote address on clock 1, and read or wrote data on clock 2. It would have need another to write high_adr, low_adr, and then data.

Also, the drams were drastically smaller than today's--the 4k was introduced the same year as the 8080 (1974); the largest was 1k while it was designed. 16k was on the horizon.

but for 1k, 4k, and 16k, you had 10, 12, and 14 bit addressing. Multiplexing the address would have meant not just latching, but shifting bits from the high_adr by 6, 4, and 2 to feed the dram, upping chip counts.

By the time of the 8086/8, the CPU addressed more than 16 bits of memory, and some of the practicalities changed. However, CPU clock had increased enough that early models barely got memory in time. Somewhere around 10mhz or 12mhz, "wait states", stalling the cpu for one or more clocks while waiting for memory, became necessary. Spending an extra clock wasn't worth the pins it would save for most applications.

Fastforward to today, and you have insane number of pins, and the processor executing several full cycles during the time it takes for a single cycle of main memory, and multiplexing is a thing of the past.

nifty tidbit: the 8086 and 8088 were almost identical; the 8088 was an 8086 with an 8 bit data bus. No built in way of telling them apart. However, you could do a little dance with the four word (yes, four words!) cache by putting something in, and retrieving from memory, that would still be in the 4x16, but not the 4x8!)

  • 1
    Note that the 6502 is actually a two phase clock, although the second phase is generated internally on the processor for simplicity. The second phase is an output from the CPU for bus synchronization purposes. The Z80, on the other hand, is a pure single phase design
    – occipita
    Commented Jun 7 at 21:30
  • Thanks. I think I knew that years ago :) In some form or another, clock edges, hi's, and lows are needed for things to happen on--put out address, read or write to bus, etc. And internally generated works just as well as external for this.
    – hawk
    Commented Jun 7 at 23:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .