I'm trying to figure out how the IBM 5150 PC handled the case where multiple physical devices (memory chips) were mapped to the same address within the 8088's physical address space.

The closest I've been able to find is in the August 1981 IBM 5150 Technical Reference, where it says on page 2-68 (PDF page 87) about input from I/O address 3BCH or 378H that

This command presents the CPU with data present on the pins associated with the out to x' '3BC'. This should normally reflect the exact value that was last written to x '3BC'. If an external device should be driving data on these pins (in violation of usage ground rules) at the time of an input, this data will be 'or' ed with the latch contents.

Though of course, not only is that about port I/O, not memory-mapped devices, but also about the MDA/printer combo card, so it's not necessarily the same thing at all (though it could be).

Minus Zero Degrees cautions that the base address for extension memory adapters need to be different from those of any other extension memory adapter in the system. For example, about the 64 KiB adapter:

The switches control the starting address of the RAM. /.../

You can have multiple of these cards in your IBM 5150 or 5160, providing that none of the RAM on a card has an address conflict with any other RAM (motherboard RAM or expansion card RAM).

In order to have a reliable system and get the full benefit of the extra RAM installed, this makes perfect sense: No memory address conflicts allowed.

But what actually happened if you did have a memory address conflict?

Did the system refuse to boot (POST failure)? Did it boot, but functioned erratically depending on which card just happened to serve the particular memory I/O request each time? Or did it boot and functioned "just fine", except you didn't get the benefit of all the extra RAM you just installed (and if so, what about additional ROM chips)? Or what?

Bonus points for answers that not only discuss the user-visible behavior, but also what was going on electrically and/or logically inside the computer.

  • 4
    I believe the answer is "it depends" on what devices are responding to the same physical address. For any arbitrary CPU wired up so that multiple devices respond to the same address, I wouldn't expect anything desirable to happen, but the exact response would depend on the devices. – Brian H May 24 '17 at 20:40
  • 1
    @BrianH So the PC had no particular safeguards to prevent or accurately detect address conflicts, and would basically limp along as best it could given whatever happened each time? (That makes sense, especially given that any personal computer of the time would be considered extremely minimalist by today's standards.) I'd consider that a valid answer (hint, hint). – a CVn May 24 '17 at 21:13

On early IBM PCs, all devices were conntected to the ISA Bus. You can read about how the bus worked in detail here, including timing diagrams.

Basically, all devices were just wired together. Some signals are controlled exclusively by the host (the motherboard, if you want). Other signals are active low and would be pulled low by any device which wanted to signal, so this is effectively a wired-or. The data lines are tristate (each device can control if the data lines are connected to the bus, or not).

That means if several devices were reacting to the same address, a memory or I/O write would go to all of them. For a read, several chips would attempt to drive the same data line, and the result would depend on which driver is "stronger", and on how the host reacted to voltages that are "in between" the defined levels. As a result, conflicting reads would deliver an unusable value.

There were no safeguards to prevent this. The actual effect was that usually both devices with an address conflict just wouldn't work, because the software could neither read data from them, nor reliably control one without affecting the other.

If you had an address conflict with anything that was vital for normal operation, it wouldn't boot (but normally, cards didn't use any of these addresses).

This is why you had often DIP switches on cards, so you could select one of several addresses in case of a conflict.

In the IBM 5150 Technical Reference on page 2-68, it seems like some internal devices like the parallel port latches were connected directly to the bus (no tristate), and for this particularly architecture also the data lines were held or floating high on idle, and actively pulled low. So here a result of a conflicting read would a 0 for each bit that read 0 on either responding device (again a wired-or), with the same effect that the resulting read was unusable.

  • 3
    I would expect that in a rare case that someone put in the exact identical device (like a second identical RAM expansion occupying the same address space as the first), it could even work, as there would be bus conflicts, but with the same addresses and data. CPUs can actually easily drive 2 memory chips connected in parallel. – tofro May 25 '17 at 11:41
  • @tofro On the other hand (besides the fact that it would be pretty much useless to begin with), you'd then almost certainly run into timing issues. Even with a bus clocked at a measly few megahertz, I suspect timing issues would crop up maybe not every time, but some of the time. Not sure how those would manifest themselves, though... – a CVn May 26 '17 at 15:57
  • I don't think most of the signals driven exclusively by devices in the ISA bus were both active-low and required to be open collector, and thus wired-or. Notably the interrupt request lines were active-high which prevented interrupt sharing. – Ross Ridge May 26 '17 at 18:06
  • 3
    @MichaelKjörling Having RAM chips working in parallel is not so useless, after all: One of my common procedures to find a broken DRAM chip in my old computers is simply to set a known good chip, legs bent slightly inwards to make good contact, on top of all the candidates on the PCB, one after the other. The RAM chip will perfectly work in parallel with the existing one and once the RAM check succeeds, I normally have the culprit after a few minutes. – tofro May 26 '17 at 19:37
  • @tofro: It was also possible to have two devices use the same address if one of them only watches what's going on without adding cycles of its own. This approach could be used to e.g. have a "normal" CGA card co-exist with a card that drives some other kind of display with different timing (e.g. an LCD). – supercat Mar 27 '18 at 15:50

This can, in edge cases, even cause hardware damage: If you have something addressing these devices constantly (which is a plausible result from an OS/driver crash due to these ISA devices completely misbehaving in the first place - eg a driver waiting for a certain bit to be asserted, looping on a register read until it is, while another card pulls that bit down HARD with a stronger line driver!) they both try to force conflicting data onto the bus wires (in the worst case, 0x00 against 0xFF...).

For every conflicting bit you will have one tristate driver connecting the shared wire to ground, the other to +5V - in the end creating a +5V to ground short carrying a current only limited by the line driver's impedances, which allow for significantly more current than the allowed 24/48mA (depending on driver type). This can either burn out some driver stages from overcurrent, or overheat a whole line driver (typically, 74LS245 or 74F245 8 channel ) chip - either destroying it or shortening its lifetime significantly.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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