On this page about "An S-100 68000 CPU Board" it is said:

From a hardware perspective there are some very significant differences how Intel and Motorola CPU's talk to the world. Somewhat oversimplifying, one could say that Intel CPUs assume that external devices are ready to talk to them immediately unless told otherwise (adding wait states). While Motorola CPU's assume the opposite, they wait for a "I'm ready to talk" signal unless they are told otherwise -- so called synchronous communications.

This is a difference in the CPU families that I didn't know about before.

What were the reasons for Intel and Motorola making their respective design decisions in this regard? Was a consensus ever reached on which approach is best? Or even, best for a general-purpose computer versus embedded systems?

  • 1
    As for what the best approach, in the modern day, I'd say it's a mix/doesn't-apply/maybe-Motorola. Modern desktop CPU interfaces are a lot more complex, and consist of a lot more than RDY, ~WAIT or ~DTACK pins. I'd say that the active acknowledgement is better because it doesn't rely on having to decode the address in time to provide the wait signal. Nov 14, 2020 at 3:51
  • There are usually two reasons for arriving at a certain design: Engineers take an older design and modify it, or they develop a particular solution that works, and are usually unaware of alternative solution (because the one solution they came up with took long enough, they don't have time to investigate alternatives as thoroughly). But that's again a question that is impossible to answer, unless you happen to find some people that were involved in the design process.
    – dirkt
    Nov 14, 2020 at 4:27
  • 1
    And as for "which approach is best", look at modern bus systems (ARM SoC have a veritable zoo, PCIe is also interesting). If there's an observation here, it's probably "busses become more and more like networking protocols", so the answer is probably "neither". Or at least "modern requirements are just different".
    – dirkt
    Nov 14, 2020 at 4:29
  • 1
    There isn't really such a fundamental difference in semantics when peripheral devices that are ready for a transfer signal this with "NOT wait" rather than "ready".
    – tofro
    Nov 14, 2020 at 9:52
  • 1
    Keeping it squarely on 'those days', the 80s-ish heyday of the 68000 and 8088/8086: the downside of the 68000 data transfer scheme is it needs one more signal (RnW, /DS, /DTACK) than the Intel (/RD, /WR) for a full-speed transfer. This need one more connector pin on an expansion bus. I know the pros and cons of both schemes, and think the 68000's /DTACK and /BERR is more elegant, but it is a connector overhead. Backplane pins were usually precious when we designed back then and we usually went full speed with our sub-10MHz-odd CPUs.
    – TonyM
    Nov 15, 2020 at 10:39

1 Answer 1


[While having a twist in its own, I got a feeling this had be answered already some time ago, in context about the ways to mark bus cycles on 8 bit CPU, but can't find it right now]

To start with, the page mentioned compared kind of Apples and Oranges, as it's about Intel 8080 vs. Motorola 68000 (*1). These were complete different CPUs designed at different times in different environments.

This is a difference in the CPU families that I didn't know about before.

It's called bus protocol, here asynchronous memory handling, and is the most fundamental behaviour about a CPU. It all comes down to what philospohy a designer/design team follows/creates when looking at the interaction of CPU and other components.In fact, these protocols changed even between CPU's of the same manufacturer, Motorola being a good example.

What were the reasons for Intel and Motorola making their respective design decisions in this regard?

Because they liked it that way? Serious, it's arbitrary to do it either way and I doubt there was a high level decision taken at all. It might be how one approaches the issue, what image he had about the workings and who's the 'boss'. So your opinion is as good as mine - or the designers fwiw.

In essence they are the same. Logically the 68k's /DTACK (*2) signal has the same semantics as the 8080's /READY (*3).

  • In both cases it's about the peripheral (or some decoder) to set it in time to extend a bus cycle - or not.
  • Both could be fixed to one state (Low for 'DTACK', High for '/READY') to make the CPU work synchronous.

So unlike the paragraph makes it look, the differences aren't that big. Of course it gets way more complicated in detail when attaching a 16 bit CPU to an 8 bit bus, as there is a lot of wait state generation and bus holds to be generated. But that's most definitely not the fault of these innocent signals.

Was a consensus ever reached on which approach is best?

There is no best, they are equal in all practical aspects for board design.

Well, if at all, it's possible to see Motorola's addition of /DTACK as kind of an acknowledgement/adoption of Intels /READY. The 6800, Motorola' genuine first CPU didn't have any handshake for asynchronous memory, but relied on Clock stretching for slower memory. Only the 68000 added /DTACK, while the 6809 got MRDY (*4).

Or even, best for a general-purpose computer versus embedded systems?

Again, no.

It is like left hand driving vs. right hand. Of course we all know driving on the left side is morally wrong and against the natural order, but one has to acknowledge that it works fine on certain islands :)

If at all, modern (really modern) consensus is to drop the multi purpose bus and add STT interfaces for each purpose. Where classic CPU's do use a generic memory mapped (*5) bus system, modern ones have shifted to separate interfaces like Memory, USB, PCI, etc. Not to mention that modern CPUs are rather SoC's in them self than a classic CPU only CPU. Embedded meets thousands of pins.

*1 - While not stated explicit, it's about 68K on S100, which is simply the 8080 bus.

*2 - Data Transfer ACKnowledge - made famous by DTACK Grounded.

*3 - In fact, one could argue that Intel's naming is almost poetic, after all /READY can well be read as Not-Ready. Given, it's bad practice to name that way, still it tickles a certain nerd sense.

*4 - MRDY is in fact more of a signal to control a build in clock stretching. unlike /READY or /DTACK it's timing is rather critical. in return it allows to strech wait stats by partial clock cycles. Now that's what I'd call unusual.

*5 - for this, the difference between address spaces, like for IO and memory, are irrelevant.

You must log in to answer this question.

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