4

In general, different CPUs don't use the same bus protocol. A 16-bit CPU would not in general be expected to use the same protocol as an 8-bit CPU. For example, the 68000 would not be expected to use the same protocol as the 6809, just because it's a successor made by the same company.

But 8-bit ISA cards made for the IBM PC, were still usable with the 16-bit PC AT (using the 8-bit subset of the bus on the latter).

Did the designers of the 286, specifically go out of their way to stay compatible with the 8088 bus protocol, in order to make this possible? (Reminiscent of the specific effort to keep the instruction set compatible, but the two are orthogonal; the new chip could've kept instruction set compatibility with a different bus protocol, or vice versa.)

  • 2
    You might note that the 8088 was itself fairly compatible with peripheral chips intended for the 8080. But things aren't as distinct as you might think, typically in that era some glue logic was needed anyway and often covered for even more substantial differences. – Chris Stratton Mar 27 at 2:45
  • 1
    @Raffzahn I am not suggesting they have to be different, only that in general they don't have to be the same e.g. retrocomputing.stackexchange.com/questions/5280/… – rwallace Mar 27 at 3:04
  • 2
    Why would a company change anything significantly that has proven to work? The Motorola 68008 and its later successors up and beyond the 68020 use the same (or, at least, very similar) bus protocol. – tofro Mar 27 at 6:25
  • 1
    @rwallace That question compares two families from two different manufactureres - both based on their previous families, evolved with different bus strategies. Not the same case as one manufacturer adding a new CPU/CPU Family. – Raffzahn Mar 27 at 10:35
  • 1
    @Raffzahn So generally speaking, CPUs developed independently by different manufacturers are likely to have different bus protocols, but a manufacturer having settled on a protocol, is likely to want to stick to it for some time. Okay, that makes sense. – rwallace Mar 27 at 10:51
5

In general, different CPUs don't use the same bus protocol.

Why not? Sure, different manufacturers defined different bus designs - but more often than not, used them across various CPUs and CPU families.

A 16-bit CPU would not in general be expected to use the same protocol as an 8-bit CPU.

Again, why not? The number of data lines doesn't inherently ask for a different protocol.

For example, the 68000 would not be expected to use the same protocol as the 6809, just because it's a successor made by the same company.

Except it's the other way. The 68k bus is, on purpose, designed to be compatible with the 6800 bus. It follows the same workings, plus extensions for asynchronous operation and half-word access.

  • With DTACK grounded it operates exactly as the 6800 bus, with AS working as VMA

In fact, designers of a new CPU do need to have a quite good reason to change a bus design in an incompatible manner from its predecessor or other CPUs of the same company. It's never about the CPU alone. The CPU is part of a whole set of components. Changing the way these components interact (aka the bus protocol), would mean that each and every other chip also needs to be modified. This means introducing a dozen or more chips instead of just the CPU. That'll be financial suicide.

When Motorola created the 68000 it was mandatory to make the bus protocol compatible with their huge family of interface chips.

Intel acted similarly with the 8086 (and 286) bus being a compatible implementation of the 8080 bus. Where Motorola offered a few new I/O Chips for the 68k CPU, Intel only provided a new DMA controller. And IBM ignored even that offering and went along with the 8237 and its 64 Ki address range. All because the buses where compatible. A 8259 Interrupt Controller could manage the interrupts for a 8086 just as for a 8080 and a 8237 could drive an 8086 bus the same way as it did for a 8080.

But 8-bit ISA cards made for the IBM PC, were still usable with the 16-bit PC AT (using the 8-bit subset of the bus on the latter).

Because IBM added circuitry to operate that way. The selection for 8 or 16 bit transfers and the according timing are done by external logic, created by IBM. Keep in mind, the PC/PC-AT Bus is not the 8088 bus. It's a separate design by IBM, based on Intel's CPU bus, but not the same.

Did the designers of the 286, specifically go out of their way to stay compatible with the 8088 bus protocol, in order to make this possible?

Not at all. The 80286 bus is exactly the same as the 8086 bus. The main difference is that more address lines are available. Otherwise it's exactly the same bus as with the 8086 - why make a new bus design, and throw away all I/O, when nothing relevant changes?

Implementation-wise, the 80286 came in a package with more pins, so it could support non-multiplexed signals, making latches and bus controllers obsolete (8282 latch and 8288 bus controller - think of these as being integrated into the CPU).


It might be worth to reflect that 'bus' is a quite loose used term, usually denoting nothing more than that it connects several devices for 'some' purpose.

[The following is only in regard to microprocessors; Mainframes and even Minis evolved along different lines]

Here it's about CPU bus and I/O bus - and more so about the way it has been in the 1970s to 1990s. Such classic CPUs expose a CPU bus, intended to integrate several components to work together as a single computing system. They are tied to the philosophy the designer chose. Not least due to the quite limited pin count available, these buses had to handle a multitude of functions, all the way from fast memory and multi processor to slow I/O ports. Most importantly, most of these use cases are about CPU extensions: think DMA or FPU, that may even replace the CPU (DMA) or extend its inner workings (FPU).

I/O buses in contrast did start out as buffered CPU buses (think Altair) maybe with some little additions for arbitration (think Multibus), still following the needs of CPU extension and memory. The PC bus is a great example of an extension that evolved away from the CPU. While the 8 Bit is, much like S100, a rather simple buffered version of the (full decoded) CPU-bus, the AT bus now added MEMCS16 and IOCS16 signals not found on the CPU-bus to handle 8 bit cards on a 16 bit CPU, moving it away into a separate system, while still being tied to it and able to serve many of the components a CPU bus is meant for.

Nowadays CPU have next to all the components that were add-ons back then integrated, so the need of CPU buses is more or less an issue of the past. This goes along with way larger packages - in terms of pins at least - offering room for dedicated interfaces instead of a cramped bus.

Now there is usually a dedicated memory bus offered while I/O buses have evolved to be complete different beasts, relieved from the memory-like access and optimized to asynchronous block transmissions (think PCIe).

Thus thinking about classic CPU buses is truly an RC.SE task, isn't it :))

  • Looks like you referenced a footnote (*1) but didn't include it; can you check?? – Wilson Mar 27 at 12:22
  • Oh yes, that's meant to be a tongue in cheek reference ... well, I guess it may work better by being resolved for everyone, not just oldtimers. – Raffzahn Mar 27 at 12:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.