PC compatibles in the 1980s were often advertised as having zero, one, two, or sometimes more "wait states". Zero wait states was the best.

Basically, the wait-states I am asking about are due to the main system DRAM being too slow for the CPU, so extra bus cycles were added to make up for this latency. This reduced the overall processing speed. I'm not asking about cases where a CPU is blocked from accessing main system RAM by some peripheral doing DMA, for example. Obviously, that's a feature for improving performance.

But I don't recall this being an issue on comparatively-priced machines with 16 or 32-bit Motorola processors, and running at similar clock speeds.

What was the cause of the wait states, precisely, and how come other low-cost home computers were able to avoid this performance problem?

  • 3
    Brian, this question is rather wide. It's almost like asking why TTL chips need current and why don't they use all the same. It might be a good idea to narrow it a bit down.
    – Raffzahn
    Commented Apr 22, 2019 at 20:53
  • Many processors have had some notion of variable memory timing that can be configured one way or another. Some dynamically, some by data driven configuration, others by simply hard-coding one specific timing. See, for example, retrocomputing.stackexchange.com/questions/9562/…
    – Erik Eidt
    Commented Apr 22, 2019 at 21:17

5 Answers 5


It was an issue on all machines — wait states resolve any situation in which the part a processor needs a response from isn't yet ready to respond — but only in the commoditised world of the PC was it a variable and therefore worth putting in the advertising.

In the Atari ST, wait states are inserted if the 68000 tries to access RAM during a video slot (two of every four cycles), or when it accesses some peripherals (e.g. there is a fixed one-cycle delay for accessing the sound chip).

The Amiga differentiates chip RAM and fast RAM. Chip RAM is that shared with the coprocessors and in which the CPU may encounter wait states. Small Amigas like the unexpanded A600 have only chip RAM.

Conversely, on the PC processors scaled in processing speed much more widely, the underlying reasons for potential waits were much more variable, and one manufacturer would likely do a better job than another. So it warranted boasting about if your machine has a good number rather than a bad one.

  • I was referring to wait states introduced by DRAM latency, not contention with DMA devices sharing the bus. I'll try to clarify...
    – Brian H
    Commented Apr 22, 2019 at 21:47
  • 8
    There's an obvious reason for that, in that the Apple II and VIC-20 have CPUs running at 1MHz, while the RAM is faster. As such the CPU can access the RAM on without any wait states; it's even fast enough for the video hardware to have a go on alternate cycles usually without contention. Once you've got a CPU that's faster than its RAM, wait states are inevitable though. Commented Apr 22, 2019 at 22:23
  • 1
    Also: the sound chip example on the ST is exactly the same phenomena, I'd argue. There's no contention, just a memory-mapped area where the underlying device is slower than the processor, so the processor is made to wait.
    – Tommy
    Commented Apr 23, 2019 at 0:38
  • 1
    @BrianH As used in advertising, it was little more than your usual marketing ploy, like listing the frequency of the CPU. Ignoring all the complications, it only means a synchronization between the CPU and a particular device - RAM, or things like sound cards, graphics cards, network cards... so a higher amount of wait states could mean slower devices or slower bus, but it could also mean the exact same computer with a faster CPU. Graphics cards were notoriously slow to access, and this was quite important for games (some graphics cards advertised their low wait states, that made more sense).
    – Luaan
    Commented Apr 23, 2019 at 5:40
  • 5
    The first paragraph is key in this answer. The PC was a commodity, available from many manufacturers, and wait states therefore became one of the differentiators that allowed you to describe how your system was different from everyone else's while still being "PC compatible". Other systems with a CPU faster than the RAM had wait states as well (sometimes for DMA, sometimes for other reasons) but they were incidental differences and not worth pointing out compared to other differentiators like the choice of CPU, video chip, sound chip, or the amount of RAM.
    – Ken Gober
    Commented Apr 23, 2019 at 12:57

Preface 1: The way it is asked, it's way too broad for an answer to make any sense. Especially making some assumptions at the same time as widening it across all different CPU memory interface technologies there were.

Preface 2: Design decisions for wait state design and application is a topic for a whole course on system design. It's next to impossible to give a satisfying answer to this in general within a single unspecific RC.SE question.

PC compatibles in the 1980s were often advertised as having zero, one, two, or sometimes more "wait states". Zero wait states was the best.

It looks like, at first sight, but looking closely, systems without are more often than not the slower ones.

Basically, the RAM was too slow so extra bus cycles were added to make up for this latency. That reduced the overall processing speed.

No, not really. It's much more complex than that, so it may be a helpful to restrict this to the core of wait state usage on IBM and compatible machines of the 80286 area where the question was most prominent and seems to have originated.

To start with, a wait state isn't an issue of memory but of the CPU. It's the CPU design requiring memory access to be synchronized with the clock speed used. An 8086 class CPU always takes four clock cycles per memory access, while it is two with a 80286. For the following we go with the 80286, as it's a quite different timing than on the 8088.

For an AT running at 6 MHz this two cycle structure would make a basic access time of 333ns per bus cycle, but the structure is a bit more complex. The first cycle is a setup cycle where all control signals are presented (called TS), while the second is called command cycle (TC) and contains the operation itself and handshaking. This cycle will be extended as long as there is no acknowledge from the memory system (called Ready). Intel added some quite nifty structure to enable the full use of these two cycles for memory operation, like address pipelining, which offers a stable address before the first cycle. Using this requires non-trivial circuitry.

IBM chose a more simple approach. The decoding waits for the raising edge of ALE, when all signals (status like direction and memory/IO) are valid, simplifying decoding a lot. ALE becomes valid a few nanoseconds after the first half of TS, reducing the time available for decoding and memory access to somewhat less than 250 ns. The AT was designed to run with 200 ns RAM access time, so already tight, especially when considering that RDY needs to be assigned by the memory system before the second half of TC, effectively reducing the timing to less than 133ns. Way too short.

For the AT (5170 Type 139), IBM decided to be better safe than sorry, adding a wait state. In addition, it also made sure that access time for I/O cards would stay within the limits set by the PC. Equally importantly, with a wait state, they could be sure that there is no chance a less than perfect charge of RAMs would screw the quality. Considering that the AT was about three times faster than the PC, there was no need to take any risk.

With the later PC-XT 286 (5162), with basically the same design (and the same 200 ns memory), IBM went with zero wait states. Maybe they became more confident.

Then again, it's also possible that the whole system was already designed to run at 8 MHz from the start and has been only slowed down to 6 MHz for company policy reasons. In that case, the wait state does make a lot more sense, as an 8 MHz design (as IBM did) can only run with 200 ns RAM by implying a wait state. Similarly to keep the slots compatible. The difference between 6 MHz AT (type 139) and 8 MHz (type 239) is basically just the clock chip.

Bottom line: It all comes down to design decisions. With a more sophisticated decoder circuitry, 200 ns RAM can work well with a 8 MHz 80286 without wait states - as many other 80286 machines of the same time showed.

Now, then there was the race to more MHz, cranking 80286 machines up from original 6/8 MHz past 12 or 16 MHz. At that time there was no memory fast enough to support this speed. Even adding a more sophisticated decoding, as for example NEAT boards added, couldn't help at the higher end.

It might be important to remember that memory access of the 8086 family is different from next to all previous or contemporary CPUs, as only data access was synchronous. Code was read ahead of time by asynchronous BIU operation, resulting in fewer unused cycles compared to a 68k. This is the reason why Intel CPUs performed quite well in comparison.

But I don't recall this being an issue on comparatively-priced machines with 16 or 32-bit Motorola processors, and running at similar clock speeds.

Comparatively-priced is a more than vague term, considering that fully-fitted PC could well outprice high end workstations. And neither is clock speed an issue, as clock speed is only marginally related to memory speed. As mentioned before, it's all about memory access (and cycle) time. Other CPUs were hit by the same problem when clock speed increased. A 68k used at least two cycles per access, which means that 200 ns is fine for a 8 MHz 68000 (assuming a simple decoding circuit). Anything faster than that will also require wait states.

What was the cause of the wait states, precisely, and how come other low-cost home computers were able to avoid this performance problem?

Because they where fricking slow :)) Considering RAM speed of the time, it's obvious why even upper end machines, like a SUN 1 or 2 ran at 'only' 6 and 10 MHz. It wasn't until the 68020-based SUN 3 reached 15 MHz - enabled by the 68020's cache, as memory access was done with three wait states.

Even many, many years (1992) later, Commodore's Amiga 4000 (A3640 CPU card) used 3 wait states by default to adapt the 25 MHz CPU to slower memory.

  • No way a zero WS system will run slower than one with same clock and more wait states. As simple as that. If not, show specific examples and explain the reasoning please. Commented Mar 13, 2020 at 15:53
  • @ReinstateMonica True, but were did I state anything about clock speed or it being the same?
    – Raffzahn
    Commented Mar 13, 2020 at 22:28
  • Well, if you're allowed to change anything, if there are no constraints, then the statement is meaningless - it doesn't tell us anything useful. You probably should give concrete examples of when a system with wait states is faster than one without. I'd also say that wait states being "a CPU issue" is disingenuous even if technically correct: it is about the memory or other bus-attached devices being unable to keep up with the CPU. Commented Mar 15, 2020 at 16:15
  • 1
    @ReinstateMonica It is (as usual) to be read withing the setting of the question, PCs of the 80s and their advertized race for customers. Here it's simply the fact that an 10 MHz 8088 with one wait states is usually faster than a 8 MHz with zero. Both will need the same time to access memory, but the 10 MHz will gain a (small) advantage during non memory cycles.
    – Raffzahn
    Commented Mar 15, 2020 at 16:42

The DRAM chips used for memory needed a certain memory access cycle length, for example 1000ns. Also CPUs needed several clock cycles to perform a memory cycle, so for example a 8086 could take 4 cycles to access memory. If the CPU is running at 5 MHz, the memory access takes only 800ns which is too fast for the memory. Therefore one wait state is needed to get 1000ns memory cycle. Lowering the CPU speed to 4 MHz would allow it to run with zero wait states. Basically wait states were needed because memory speeds were slower than what CPUs could access. Advertising does tell something about system performance. For example, if one system has 1000ns memories and another has 800ns memories, a 5 MHz 8086 is able to run at 0ws with faster memories and at 1ws with slower ones. In theory the 0ws machine can transfer data 25% more in same time than the 1ws machine can. Surely faster memories were more expensive so maybe it was important to advertise why two identical looking systems had a significant price difference.

  • Nitpick: 1000ns memory is getting close to core memory territory. At the same time, ECL RAM had 50ns cycles contemporary with when PCs got released. But that was expensive and power hungry. Imagine 512k of RAM populated out of 1024 bit chips… Commented Mar 13, 2020 at 15:57

The PC machines were made as modifiable/expandable systems, so you can have different CPU, memory, peripheral configuration on a per-machine basis. That leads to problem with interfacing different speed buses, peripherals, ICs... So wait states make sense.

If I recall older 8 bit machines like Z80-based ZX Spectrum, or i8080-based PMD did not have configurable wait states (but that does not mean they do not have wait states if you take a look at ULA in ZX it actively stops the CPU clock, which can be seen as a form of wait state). However on such old systems the memory was usually faster than the rest of the system and wait states were used for different reasons than slowing down access (such as to resolve sharing conflicts etc...)

So when a more recent and/or complex system does not have any configuration option for wait states, it does not necessarily mean it does not use them. It just suggests they are either set automatically or are non-changeable (limiting expandability). For example, just compare the SETUP utility on a laptop and on a DESKTOP machine, even on PC platform.

LAPTOPs are not expandable so much, so it's very hard or even impossible to change their core parts. That means there's no need to change the wait states configuration; even if it does need to change, it's usually done by flashing the firmware instead of by direct user configuration.

If you want a non-PC example of wait states use, simply look at AVR32-like AT32UC3 MCUs. They have configurable SRAM wait state to slow down the memory interface in case the MCU core runs on higher clock than the internal SRAM speed. Unless you set it correctly prior to switching to higher speeds the system will be unstable and freeze, or worse.


Wait States are Old

Wait states were not just a thing with IBM PCs and compatibles; they were used in many systems long before the PC appeared (as well as appearing in 68000 and similar systems, as Tommy's answer explains, and which I also touch on below).

Most early microprocessors, including the 8080, 6800, 6502 and Z80, have a "READY" or similar line that can be de-asserted to ask the CPU to pause operation in order to make it wait while a slow device (memory or otherwise) makes data available on the data bus. When a designer sets up a system to deassert READY for this reason, typically the number of system clock cycles during with READY is deasserted is referred to as the number of "wait states."

One of the more frequent early uses of wait states was when accessing ROM memory as early ROM (especially PROM and EPROM) devices could be quite slow (considerably slower than the RAM available at the time). For example, the Intel 1702A had an access time measured not in nanoseconds but in microseconds, ranging from 0.65 μs for the faster versions up to 1.5 μs for the slower ones. Thus, one of the first microcomputer PROM boards ever produced, the 1976 MITS 88-PMC 2K PROM Board, had options to add anywhere from 0 to 3 wait states to each access depending on how slow your particular PROMs were. (The 1.5 μs 1702A PROMs would require two wait states.)

In some cases wait states may be inserted even if the designer does not ask for them. For example the Z80 CPU automatically inserts a wait state on any access to the I/O address space.

DTACK Grounded

As an interesting side note, the 68000 has a H̅A̅L̅T̅ signal similar to an inverted version of the READY signal on earlier CPUs, but it also has a separate input signal called D̅T̅A̅C̅K̅ which is dedicated to introducing wait states. Rather than arbitrarily stopping the CPU, D̅T̅A̅C̅K̅ is checked only after the address for a memory access is placed on the bus and (full cycle) wait states are inserted until D̅T̅A̅C̅K̅ goes low. (Thus, this would generally be used only for adding wait states, whereas READY was used for other purposes as well, such as stopping the CPU using a front panel control in order to read or write memory using the front panel switches.)

Dealing with D̅T̅A̅C̅K̅ and other associated signals (including "bus errors") can be very complex, and because of this the Motorola 68000 was seen as a CPU for high-end machines such as Unix workstations, rather than a CPU for hobbyists. Hal W. Hardenberg of Digital Acoustics, Inc disagreed with this assessment and started a newsletter called DTACK Grounded,, explaining in the first issue that,

Because the acknowledgements from all of the various devices connected to the bus must converge on pin 10 [the D̅T̅A̅C̅K̅ pin], a very large percentage of the available application information on the 68000 published by Motorola covers the circuitry to generate DTACK.
Motorola is not worried about the complexity of this process because they are, for reasons known only to Motorola management, promoting the 68000 exclusively as the "engine" for very complex systems.

...it is possible to build very simple systems using the 68000 if you ground DTACK. Naturally, you can then tie BERR to +5, since the data is always acknowledged. Now you have a SYNCHRONOUS data bus, and you can throw out about 93% of Motorola's application information on the 68000.

So, ironically enough, though wait states were usually a method of allowing you to use slower (and thus cheaper) devices, getting rid of wait states became the core idea for making small, cheap 68000 system, with this idea embedded in the very name of the most popular 68000 newsletter of the early 1980s.

  • 2
    Fine answer. Especially for mentioning DTACK Grounded magazine :)
    – Raffzahn
    Commented Mar 12 at 12:25

You must log in to answer this question.

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