A PCI card does not have a fixed memory address, the PCI card specifies how much memory it wants, and the OS will assign whatever address it wants for this memory, and will set this address in the PCI card's BAR field (of course a PCI card can have many BAR fields).

But what about an ISA card, can the OS specify a memory address for the ISA card, or does the ISA card have a fixed address?

And if the ISA card have a fixed address, what happens if two ISA cards existed on the same computer with the same address?

  • 1
    Probably worth pointing out that with x86 architecture, cards are accessed via their I/O port address on the I/O bus, and are not memory addressable.
    – mnem
    Oct 23, 2017 at 2:36
  • 6
    @mnem Some yes, some no. A video card, for example, will overlay its video memory into the PC's memory address space.
    – tofro
    Oct 23, 2017 at 6:21
  • 3
    @mnem Whatever you think "card logic itself" is - The video memory is definitely tied to the memory bus. And that is the main access you need to have to a video card. There might be some initialisation to be done over the I/O bus, as you say.
    – tofro
    Oct 23, 2017 at 7:22
  • 3
    @mnem The distinction you're trying to make isn't helpful as far this question is concerned and only confuses the matter.
    – user722
    Oct 23, 2017 at 16:42
  • 1
    Cards carrying actual system memory existed in ISA PCs, so the required bus features were present beyond a doubt. Also, graphics cards were often programmed directly with what was definitely a normal memory access - eg textmode was commonly accessed by declaring a 4KByte array ABSOLUTE to 0xB8000 or 0xA0000 in turbo pascal... Nov 2, 2017 at 13:14

3 Answers 3


In general, yes, ISA cards have fixed memory and I/O addresses.

ISA inherently has the card decide to what memory and I/O addresses it reacts because address decoders are located on the cards. How that decision is being taken varied over time, however. Because the ISA bus in principle exposes the full system bus to cards with no isolation or address translation, a card might technically react to any address its designer wanted it to (This is more flexible than, for example, assign fixed address ranges to slot numbers like other systems did, but also potentially leads to more collisions)

Very early in PC history, a simple memory and I/O map had been designed and that specified, for example, an MDA card had to have its video memory at 0B0000h, and a CGA card was specified to live at 0B8000h. Similar for associated I/O addresses.

Cards that weren't standardized like that used to have jumpers or DIP switches that typically allowed you to choose between a (limited) set of memory (if needed) and I/O addresses.

Only much later, when memory and I/O address spaces started to become crammed with more and more peripherals, new approaches had to be invented.

This started with jumperless cards that could have their memory and address resources configured into non-volatile memory (which created some sort of chicken-and-egg-problem: In order to program that jumperless card to use some specific resource, you had to access it somehow. And if that "somehow address" was already taken by another peripheral, you ended up with a collision and either had to revert to jumpers again or had to remove cards to make the initialization for a new card possible).

Even later, ISA PNP tried to automate this process of allocating memory and I/O resources to cards by having the BIOS and the cards negotiate resource allocation during startup. (Even there, however, it is ultimately the card that decides what addresses it listens to and what potential resources it offers to the PNP BIOS for negotiation. And the resulting resource is fixed after the negotiation process). This approach somehow worked in theory but with PCs typically having a mix of legacy cards with fixed resource allocation and "new"-style PNP cards made that bargaining for resources very difficult, on heavily-equipped PCs sometimes even impossible. This (and other reasons like addressable space and bus speed) eventually led to the introduction of more advanced bus systems like MCA and PCI.

BTW: Even if your question doesn't ask for this, very much the same is true for the third type of resource typically needed by peripherals: The IRQs.

  • Huh, I didn't remember ISA PNP. I did remember that there was supposed to be a programming convention, frequently ignored (or incorrectly implemented), for chaining IRQs since those were even more limited than addresses.
    – davidbak
    Oct 23, 2017 at 23:57
  • Was there ever a modern implementation of ISA where each card is on a physically isolated single-device "bus" and the addresses on this bus have no relation to (or rather their relationship is dynamically configured) the main physical address space? I would expect a "PCI to ISA adapter" to work something like that. Nowadays maybe there are even "USB to ISA" adapters for legacy devices? Oct 24, 2017 at 1:18
  • AIUI you can buy programmable bridge chips that will map from PCI to an ISA-like bus with dynamic address mapping but the bridge chip needs to be programmed with the devices address requirements and the driver software needs to know about the bridge chip so it can address the drive properly. So it's a useful soloution for card manufacturers trying to put an old chip on a PCI card but it's not so useful as a generic adapter. Oct 24, 2017 at 4:44
  • @R.. PC/104 (an embedded bus standard) and its various enhancements combined PC, PCI and PCI Express features in one single bus - So, you could say it did implement resource isolation between slots.
    – tofro
    Oct 24, 2017 at 9:05
  • @davidbak That convention you are referring to was that if you used an interrupt vector to point to your own ISR you should be calling the original code from there (thus chaining ISRs) and restore the original ISR when done using the vector. This only worked when ISRs were removed in the exact same order they were created, so wasn't much help anyways. For DOS TSR programs using software interrupts it was a must, however, as it could lead to fatal crashes otherwise when TSRs were removed..
    – tofro
    Oct 26, 2017 at 9:08

If the ISA card is built to support it, it can have a BAR register (or the effective equivalent). This is kind of what the ISA Plug-and-Play (ISA PnP) standard did, and it also defined a standard way for the OS/BIOS to identify cards and program addresses at boot time.

Before ISA PnP, it wasn't uncommon for cards to have configurable addresses stored in non-volatile RAM (e.g. Flash memory), and for the cards to come with a special utility on diskette allowing you to update the RAM with new settings.

Before that, cards would be configured via jumpers or switches (if they could have their addresses configured at all).

If you configured two cards at the same address, they would generally both try to respond at once. Typically the worst result was simple malfunctions, but depending on the design of the conflicting cards it might have been possible to actually damage one or both.


"What happens if two ISA cards existed on the same computer with the same address?" appears to have no answer yet.

Short answer: you have a problem.

Longer answer: it's very undefined. While both cards would probably react to write operations (with even more undefined results of the hardware), read operations are invariably borked. The CPU could get a mixture of both address locations' bits or nothing at all (when one card terminates the read cycle while the other dominates the data bus but hasn't put on any meaningful content yet).

Similar things would happen with an IRQ or DMA collision: nothing good. Most often the devices simply wouldn't work or loading the driver would lock up the computer. Sometimes the effects could be rather subtle, appearing to work most of the time but playing up without any apparent reason.


You must log in to answer this question.

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