9

My understanding of ISA bus is that the CPU places an address on the bus and any expansion card is free to respond to that address by taking control of the data bus. I presume that tri-state buffers are used. So my question is, are there any arbitration mechanisms in ISA and/or PC/XT-bus to prevent two cards from responding to the same address? My understanding of tri-state logic is that if this were to occur the tri-state buffers would likely get fried. Perhaps there was some sort of lesser mitigation to prevent such damage in the case of contention?

Looking online I see no mentioning of arbitration or damage mitigation, and yet I also know no stories of people with fried ISA expansion cards due to address overlaps.

Chris_F
  • 193
  • 1
  • 5
  • 4
    The term "arbitration" with respect to buses is used to mean something else entirely. What you're asking about is something like plug-and-play functionality. – David Schwartz Dec 28 '19 at 00:07
  • 7
    PCs used to have a big red front switch to resolve unrecoverable bus contention issues :) – rackandboneman Dec 28 '19 at 00:38
  • 1
    Nope, anyone could answer, and this is what lead to the over-engineered PCI solution. Built ISA cards for years, never fried any, address space was not too hard to sort out, there were some folks with autodetection solutions (that would interfere with other folks autodetection solutions), interrupts were the PITA... – old_timer Dec 29 '19 at 05:48
  • 1
    some items which still have the same legacy addresses today were lets say hardcoded going back to the original. then for items other than that it would become a free-for all, there werent standards for that. You normally used jumpers, some folks hardcoded and you might not be able to use that card, and as mentioned some had autodetection schemes. – old_timer Dec 29 '19 at 05:50

5 Answers5

15

PC and XT

The original IBM PC simply extended the Intel chipset bus to connectors using buffer drivers. The clock rate on the card bus was the exact same as the clock rate used for a CPU cycle. So with approximately \$4.77\:\text{MHz}\$ (derived by dividing by 3 a \$14.31818\:\text{MHz}\pm 5\:\text{ppm}\$ crystal rate) on the PC's CPU, this meant that a typical 6-cycle, 8-bit I/O bus transaction would take about \$1.26\:\mu\text{s}\$. This was consistent with the technology at the time, so boards could decode and latch addresses using middle-of-the-road (in terms of speed) and reasonably-priced devices. IBM would eventually published a fairly complete set of documentation on the IBM PC, XT, and PC/AT that included detailed schematics that were well laid out and understandable and a complete listing of their BIOS source code (in assembly), as well.

The PC and XT simply used the bus design that reflected Intel's chip design, without extension features (that I'm aware of.) If you tried to increase the clock rate of the CPU, then the clock rate of the bus would also increase and this put pressure on the boards. But I don't recall many attempting to do this, so it wasn't an issue.

AT

With the advent of the PC/AT and the 80286, a new 16-bit I/O transaction and 16-bit memory transaction became available. Intel also changed over to the new 82284 clock gen chip and the 82288 bus control chip. Additional DMA channels and interrupt signal lines were added by IBM and an arbitration transaction was added so that add-on cards could replace the platform CPU as the bus owner. (A little more on that, later.)

The new standard limit for the CPU was now \$6\:\text{MHz}\$. The bus rate was similarly increased and newer boards needed to keep up. IBM also introduced a number of new cards for the system.

The 80286 had four more address lines (going from 20 to 24) and could now enter a new protected mode of operation to gain access to these new lines. While Intel was able to allow the transition from real mode operation to protected mode using appropriate software instructions, they were rushed to get the chip out to the marketplace and did not manage to successfully field the new CPU with the ability to switch back to real mode. As a result, the only way back from protected mode to real mode was through a processor reset. IBM handled this problem through the keyboard interface, using the keyboard (and memory in the calendar IC they used) to force a hardware reset when instructed to do so. The BIOS supported transitions back and forth between modes and was able to hide the fact that the keyboard needed to reset the CPU each time a request was made to get back to real mode operation.

Wider bus transfers on the PC/AT bus now also supported faster bus cycle rates; a "byte swapper" was used to port around low order and high order bytes on the bus; and the new refresh cycle logic used discrete circuits.

The rush for more CPU speed

People quickly discovered that they could increase the clock rate of their expensive IBM PC/AT to about \$8\:\text{MHz}\$ by simply replacing the clock crystal. I did this and found that I could successfully push the system and the boards I used to about \$8.5\:\text{MHz}\$ before things started to get iffy. (I couldn't reach a consistent \$9\:\text{MHz}\$ on my system, so I settled in at \$8\:\text{MHz}\$ and left it there.)

The level of skill needed (and tools required) to design a motherboard was relatively low at the time. Almost anyone could find inexpensive parts and do decent layout that would work fine at these frequencies. And a lot of "mom and pop" motherboard makers soon began to enter the scene. (IBM's price point was very high for most people.)

Perhaps the first truly successful (able to emulate the IBM hardware with 99% compatibility) PC replacement was Kaypro's 286i product. Before this, there were usually too many "issues" to make the products sufficiently acceptable to the business market (though hobbyists were often okay.) Kaypro's entry was about US$2k cheaper than IBM's, so it very quickly rolled out.

As more and more competitors solved the compatibility issues and began to compete, Intel started to roll out faster spec'd 80286 CPUs, too. Board makers would incorporate these newer CPUs, include faster logic chips so the bus could run faster, and we began to see \$8\:\text{MHz}\$, \$10\:\text{MHz}\$, and even \$12\:\text{MHz}\$ offerings. But this almost immediately put pressure on the add-on cards. Older cards simply couldn't be used and newer ones were too few, too far between, and consumers faced buying a faster system that greatly reduced the number of add-on cards they could buy and successfully use.

While a few companies attempted to isolate the add-on card bus rate from the internal Intel bus rate with discrete chips (with some success), the sheer number of "mom and pop" motherboard makers and the need to separate the clock rate of the CPU from the cycle time of the bus opened the door for a new company, Chips and Technology (aka C&T), to produce an ASIC that got this job done. Very quickly after, new motherboards entered the market allowing the ISA bus cycle time to be kept (relatively) independent of the Intel CPU clock rate. Since Intel was meanwhile continuing to increase the maximum CPU frequency, this was a godsend to the many competitors, who didn't have the internal horsepower or financing to develop ASICs but who could certainly use them in new products.

As a result, the "frequency wars" started in earnest and there was hardly a month going by where there weren't new motherboard offerings with increasing CPU clock rates. The decoupling of CPU frequency from bus frequency was a huge win for C&T, too, who did quite well in the process.

Just as a note, I believe the decoupled ISA bus operated asynchronously to the platform CPU with one exception: the RESET line to the platform CPU.

I/O and Memory and DMA

The I/O and memory bus transactions are distinct, but in most ways quite similar to each other. It's just that different boards would respond. The original 8-bit I/O transaction, for example, was 6 bus cycles long. But with the PC/AT a newer, wider bus a 3-cycle I/O was included.

It was the job of each add-on board to latch and decode the address and associated signals they were interested in (IOR or IOW, for example, for cards responding to I/O bus cycles.) They then had a certain number of clocks to respond for a standard transaction. An I/O card could, however, assert IOCHRDY if it wanted added bus cycles to complete its transaction.

With the advent now of both 8-bit and 16-bit transactions with the PC/AT ISA bus, a few issues arose. For example, a 16-bit I/O slave add-on could not force the bus master (which may or may not be the platform CPU) to execute a 16-bit access when the owner only wants an 8-bit. Similarly, a bus owner intending on a 16-bit access cannot order an 8-bit slave add-on to perform a 16-bit access. So there are added signal lines to aid in these circumstances.

The DMA access cycles were a little different from the other two in this sense: DMA would use simultaneous activation of I/O and memory command signal lines to allow data to be placed onto and retrieved from the bus during the same cycle. Here, for example, the address placed onto the bus is for memory and NOT for the I/O card (which should not use it.) (The AEN is activated to indicate to the I/O card not to use the address.)

Add-on boards responding to I/O addresses were set at unique locations to avoid conflict. IBM provided guidance about this for important cards (video display, serial port, parallel port, interrupt controller, and so on), but many add-on board makers would also include means to adjust the I/O address so that if you used two or more of their boards, they would work okay together. In general, the system worked pretty well and there were few problems. (Most issues related to the graphics memory required for various types of display controller boards.)

Arbitration

Technically, there actually IS an arbitration cycle. It's just not what you are asking about. Instead, it is a means by which another bus master (presumably residing on an add-on card) can claim ownership of the bus as the master. This cycle actually starts out looking like a DMA transfer cycle and it is the DMA controller which first responds. The would-be bus master then has a fixed time in which to assert MASTER and obtain ownership. The DMA controller then tri-states its own address, command, and data signals. (I worked with a team on a MIPS R2000 add-on card for the IBM PC/AT, circa 1986.)

Community
  • 1
jonk
  • 77,059
  • 6
  • 73
  • 185
  • _"An I/O card could, however, assert IOCHRDY if it wanted added bus cycles to complete its transaction."_ so theoretically an I/O card could hold onto the bus **forever**? With no **I/O address** arbitration two cards on the same address could drive the data lines at different logic levels continuously. Even TTL buffers like the 74LS245 are not rated for this. – Bruce Abbott Dec 28 '19 at 19:02
  • @BruceAbbott No. An I/O card cannot hold the bus forever. There are some confusing issues (DMA has different rules -- 2 waits only) but there are specified limits. IBM in its documentation specified a maximum wait of \$2.5\:\mu\text{s}\$ but the ISA specification (which wasn't only IBM writing it) allowed for a longer period of \$15.6\:\mu\text{s}\$ to avoid conflicting with DRAM cycle periods that were in practice at the time. I don't recall ever seeing more than three bus clocks for a wait. I used one clock a few times but usually tried "to keep up." – jonk Dec 28 '19 at 19:33
  • 1
    @BruceAbbott What's sad for me is that the ISA was easy to understand and that IBM provided beautiful, expensive-looking (and performing) empty protoboards designed to slip right into an ISA slot. Lots and lots of plated grid holes to place and wire-wrap or just solder up your own circuits. And the boards were cheap, besides. (Very much less than anyone else would make them for me, at the time -- about $40.) Full slot sized. They also included all of the standard decoding wiring using the usual 7400 series parts, so it was really easy to do the address decoding. PCI killed that. – jonk Dec 28 '19 at 19:53
  • 1
    @BruceAbbott There is no equivalent now for any machine. You can't get access to I/O at MHz bus rates with an interface that is "doable" by hobbyists. Instead, everything is Bluetooth, USB, etc. And given the 1 ms period for USB, for example, it's just NOT THE SAME THING. I'd like to see ISA returned. But Intel REALLY wanted to kill it. The south bridge was the source of more than half their silicon bugs on every spin of the chipset. So it was a continuing thorn they really wanted to kill. – jonk Dec 28 '19 at 19:56
  • I agree that the ISA bus is much nicer for hobbyists. I haven't worked with it myself but I did interface an ISA bus MFM hard drive controller to the Amiga and it was pretty easy (the Amiga has 'Autoconfig' to allocate hardware addresses, but you can still use fixed addresses if you want). It had to go though because it was too limiting. Modern PCs have little in common with the original XT/AT architecture. – Bruce Abbott Dec 28 '19 at 20:53
  • 1
    @BruceAbbott They do have very little in common, now. (I worked on BX chipset.) But the IBM PC was a hobbyist device. IBM documented the bus, provided the schematics, listed their BIOS source code, and made it completely open to all. It was a very good time for us hobbyists. The PC has now left all that behind and it's no longer accessible to a hobbyist. The tools are too expensive (reflection wave test equipment is a lot more expensive and knowledge-intensive than incident wave.) It would be nice to still have a hobbyist bus while using modern programming tools and a PC. I'm just sad, is all. – jonk Dec 28 '19 at 20:57
  • According to the 1989 Intel ISA spec IOCHRDY should not be asserted for longer than 15us or DRAM refresh will be compromised. So cards _shouldn't_ hold onto the bus forever (though there's no hardware to prevent it). Some of the fears we had about damage caused by I/O bus conflicts were probably unfounded (most faults were more likely caused by static discharge or just crappy cards). – Bruce Abbott Dec 28 '19 at 21:03
  • @BruceAbbott Did you READ my comment above???? I already mentioned numbers. \$15\:\mu\text{s}\$ is very close to my \$15.6\:\mu\text{s}\$ figure I mentioned (which I remember quite well.) Are you saying that my figure is off by \$600\:\text{ns}\$? Also, IBM's specification (which I have on my shelf in a three volume set I bought when it first came out) gives \$2.5\:\mu\text{s}\$. But that was back around 1984. – jonk Dec 28 '19 at 21:05
  • _"Did you READ my comment above???? I already mentioned numbers."_ - sorry your comment is not showing any numbers here (appears to be cut off after "allowed for a longer period of"). Perhaps my Firefox is not recognizing something you embedded in the comment? (that would be my fault for sticking with XP). – Bruce Abbott Dec 28 '19 at 21:13
  • @BruceAbbott Oh. That's odd. I can see it just fine and I'm also using Firefox, as well. But XP??? Wow!!! Yeah, that could be it. I wonder what else you are missing, then. Might be a lot. – jonk Dec 28 '19 at 21:23
  • @BruceAbbott The remaining portion is: *"IBM in its documentation specified a maximum wait of 2.5μs but the ISA specification (which wasn't only IBM writing it) allowed for a longer period of 15.6μs to avoid conflicting with DRAM cycle periods that were in practice at the time. I don't recall ever seeing more than three bus clocks for a wait. I used one clock a few times but usually tried 'to keep up.'"* Hope that helps. – jonk Dec 28 '19 at 21:24
  • 1
    Interestingly, C&T's first chipset (in 1986) did not separate the ISA bus clocks as you describe. Of course, their second one did. – Yuhong Bao Jun 22 '20 at 07:48
  • @YuhongBao I didn't recall the difference. But it makes sense, when you say it. All earlier boards I'm aware of prior to C&T, such as the KayPro 286i, were heavily populated with socketed 7400 series and other 14-pin, 16-pin, and larger ICs. And the moment anyone came up with a simplification chipset, it was an obvious "must do" for everyone designing newer boards. Thanks for the clue. Appreciated. – jonk Jun 22 '20 at 16:53
  • Good article on the history: https://zirblazer.github.io/htmlfiles/pc_evolution.html?ver=123#chapter-5.2 – Yuhong Bao Jun 28 '21 at 06:44
  • @YuhongBao I've bookmarked it for reading at a later time. Thanks!! – jonk Jun 28 '21 at 06:46
9

No there is no sanity check for addresses. If you set two or more cards to same address, they all get written with same data. Reading will cause a conflict where one card pulls low and another high. But it mainly uses LSTTL era chips where the chips can survive this, and the period/duty of the conflicting read is so short.

Justme
  • 127,425
  • 3
  • 97
  • 261
  • 2
    There most certainly **IS** an arbitration cycle for ISA! Boards can become bus master. And not only for DMA. But you are right about the address response issue. – jonk Dec 27 '19 at 18:48
  • 1
    Logic high isn't that weak on an LS245... you'd stress the hardware. – rackandboneman Dec 28 '19 at 00:37
  • I changed the word arbitration away as this question was about address conflicts, not arbitration for becoming bus master. And indeed the LS245 has much stronger drive strength than standard LS logic. But the chips still don't immediately break up when there is an address conflict. – Justme Dec 28 '19 at 17:11
  • 1
    Won't burn them out instantly, true... I'd expect a 245 to slow cook, though, if driving 8 channels straight into a conflicting buffer... or worse, a group of conflicting buffers.... – rackandboneman Dec 29 '19 at 05:46
4

There is no mechanism to prevent more than one card from responding to an address from the bus master. It is not a significant issue and I don't know of any computer buses that had such a mechanism. Even if multiple cards did get enabled simultaneously the chance of damage is very low and the buffer devices are usually designed to survive such shorts.

Arbitration is the term used for allowing a bus master to own the bus where there is more than one that requires access. In the case of the ISA bus this arbitration is performed by the DMA controller on the motherboard. When access is granted the address can be supplied by the DMA controller or by the new bus master.

Kevin White
  • 32,097
  • 1
  • 47
  • 74
0

In general, for any computerized communications scheme, end points need to have unique addresses. Telephones (or at least telephone lines for landlines) have unique phone numbers, computers have unique MAC addresses (and get assigned unique Ethernet addresses, or all h*** breaks loose), etc.

So in general, not just for ISA and PCI, endpoints have unique addresses. The only place where you can get away with not giving a specific piece of hardware a unique address is when its address is derived from where it is in the system (i.e., the designers of the ISA bus could have chosen to give each card slot a unique number which would be appended to the card's address. For the sake of flexibility and reducing design time, they clearly chose not to).

TimWescott
  • 44,867
  • 1
  • 41
  • 104
-1

To answer your question simply and accurately, there is no arbitration on the PC/XT bus. If you do an I/O or memory read and there are more than one adapters with the same address, both will drive the bus with their respective data. As to damage, I can't remember ever damaging a card or motherboard and I configured and built dozens of PC/XT computers and designed and built 3 adapter cards. Having two tristate drivers drive a bus in different directions will cause the chips to run hot and generate large Vcc and ground transients, but generally causes no long-term damage.

Grumpyoldgeek
  • 1
  • 1
    This seems to add nothing over answers previously posted which made the same points – Chris Stratton Dec 29 '19 at 05:59
  • I did add to the answers. If you don't see it, you didn't read it or understand it. My post was something of a test post to see if StackExchange was as full of itself as I have read. You proved that indeed, it is. – Grumpyoldgeek Dec 30 '19 at 06:17