Sfdwhf

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?

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.

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.

Preface 1: The way it is asked, it's way to broad that any answer can make any sense. Especially making some assumtions at the same time as widening it across all different CPU memory interface technologies there where.

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 close, 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 rally. It's way 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 seams to be 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 quite some nifty structure to enable the full use of these two cycles for memory operation, like address pipelining, which offers a stable address already before the first cycle. Using this requires non trivial circuitry.

IBM did choose 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 ns 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 to 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 important, 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 did go with zero wait states. Maybe they became more confident.

Then again, it's as well possible that the whole system was already designed to run at 8 MHz from start on 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. Similar 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 well work 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 way 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 concurrent CPUs as only data access was synchronous. Code was read ahead of time by asynchronous BIU operation, resulting in way less unused cycles compared to like a 68k. Eventually 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 full 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 where hit by the same problem when clock speed did increase. A 68k used at minimum two cycles per access, resulting, which means that 200 ns is fine for a 8 MHz 68000 (assuming a simple decoding circuit). Anything faster than that will as well 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 did run at 'only' 6 and 10 MHz. It wasn't until the 68020 based SUN 3 reached 15 MHz - enabled due the 68020's cache, as memory access was done with three wait states.

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

The PC machines where made as modifiable/expandable system so you can have different CPU, memory, peripherial configuration on per machine basis. That leads to problem with interfacing different speed busses, peripherials, ICs ... So wait states makes 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 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 where used for different than slow down reasons (like resolve sharing conflicts etc...)

So when even a more recent and or complex system does not have any wait states configuration it does not mean it does not use them. It just suggest 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 machines even on PC platform.

LAPTOPs are not expandable so much so its very hard or even impossible to change its core parts meaning no need to change the wait states configuration and even if it does need to change its usually done by flashing the firmware instead of direct user configuration.

If you want 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 ...