19

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.

Improve this question
2
  • 7
    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, 2017 at 20:40
  • 2
    @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).
    – user
    May 24, 2017 at 21:13

3 Answers 3

Reset to default
24

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 be 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.

Improve this answer
6
  • 4
    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, 2017 at 11:41
  • 2
    @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...
    – user
    May 26, 2017 at 15:57
  • 1
    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.
    – user722
    May 26, 2017 at 18:06
  • 7
    @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, 2017 at 19:37
  • 2
    @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, 2018 at 15:50
6

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.

Improve this answer
1

If it was actually RAM at both addresses, you would almost certainly just find that both chips take the write, and both chips return the same data at the same time.

It'd probably be fine. The sequence of pins you set to read DRAM chips mean that the chip will only put it's data on the bus when it actually has the data ready. So there shouldn't be a case of one chip returning a 1 and a slower one still having a 0 hanging round. They'd both be tristated off the bus, if not themselves then by the logic controlling them, until they were ready to return good data.

POST etc, or the other hardware, would have no way of detecting such an address clash in any case. The ISA bus is a very simple bus. It's basically the 8088's pins, with a few extra lines from the interrupt controller etc.

If it were some weird bit of hardware that wasn't actually RAM, but in the RAM address space, clashing with actual RAM, then you might have a problem if it was returning some non-previously-stored result. But you'd have to be insane to build something like that.

If that happened, any 0s and 1s would mean 5V and 0v were fighting. Although usually only with the weak strength the chips could muster. Wouldn't affect other hardware but might possibly blow a chip. But that's real winning the lottery on your birthday, every year, stuff. Not something you'd ever look for or plan for. Even if it happened it would need to persist long enough to cause damage.

It's one (of many!) nice things about chips with a separate I/O range (and pin!). The only things on an ISA bus responding to RAM addresses should be other RAM. On a CGA card or whatever, it's still just RAM.

Improve this answer

You must log in to answer this question.

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