• Please review our updated Terms and Rules here

PC ISA I/O Address Space : 10-bits or 16-bits

Great Hierophant

Veteran Member
Joined
Mar 22, 2006
Messages
1,928
Location
Massachusetts, USA
The Intel 8086 and 8088 CPUs support 20-bit memory addressing (with segmentation) and 16-bit I/O bus addressing. Yet IBM limited the I/O bus in the PC to 10-bits. Was this an arbitrary limitation from IBM or does the ISA bus enforce a wrap-around effect if bits 10-15 (A-F) are used in an ISA adapter. Even some of IBM's adapters use 16-bit addresses.
 
Completely arbitrary on IBM's part (another screwball decision). Some official IBM cards, such as the cluster adapter, use the remainder of the 16 bit address as selects for more than one card. Any "new" ISA card should fully decode all 16 bits of the I/O address--it could save grief in the future when you're running out of ports in the 10 bit space.

Not having a standard design requirement for cards to share IRQ lines is another big fumble by IBM. Some are completely graceful about it (such as the async comm card and the floppy controller); others assume that sharing is impossible.
 
It's a matter of how many address bits the IO devices decode. The port address space itself is 16-bit, but many IO devices on the 5150/5160 (including all the on-board devices like DMA, PIC, PIT and PPI) only decoded 10 bits of address, so can be reached by 64 (or more) different port addresses.

The same address bits are used for memory addresses as for port addresses (the only difference is the use of the -IOR/-IOW lines instead of the -MEMR/-MEMW lines) and there's nothing that masks out A10-A15 for IO port accesses.
 
So, between the I/O devices on the system board and the ISA cards that only decoded 10 address bits, a board designer needs to be really careful about which ports he is using if he is going to use I/O addresses above 3FF.
 
That's pretty much the story, yes. For example, if you decide to use port 7F2, you're likely to run into your floppy controller.

If you restrict yourself to a certain subset of I/O instructions on the Z80, you can realize a 16-bit I/O address space. Were there any 8-bit systems that attempted to extend the I/O address space with a bankswitching scheme?
 
So, between the I/O devices on the system board and the ISA cards that only decoded 10 address bits, a board designer needs to be really careful about which ports he is using if he is going to use I/O addresses above 3FF.
I remember this particular type of conflict being described as a possibility in the technical manuals of some PS/2 microchannel cards.
 
So, between the I/O devices on the system board and the ISA cards that only decoded 10 address bits, a board designer needs to be really careful about which ports he is using if he is going to use I/O addresses above 3FF.

The motherboard itself (at least IBM PC/XT, but probably other clones too) will only decode address lines A0-A9 for on board I/O devices (such as 8253 PIT, 8237 DMAC, 8259 PIC, 8255 PPI...). The motherboard doesn't do any address decoding for extension cards, so their address decoding will depend on decode circuit on the card itself. Many cards decode just A0-A9 lines, but some (e.g. VGA cards) will decode the entire 16-bit I/O address.

Also some cards use addresses higher than 3FFh by using an address in 0h-3FFh range together with a higher address that equals the address in 0h - 3FFh modulo 400h. This basically ensures that it will be no address conflict due to partial address decode. For example SB32 uses ports in 220h-22Fh range (SB16/SB Pro compatible), and also 620h-623h, 0A20h-0A23h and 0E20h-0E23h addresses for EMU8000. Another similar example is ECP parallel port. It uses 378h-37Fh ports (or 278h-27Fh for LPT2) for standard parallel port compatibility, and also 778h and 77Ah ports for ECP functionality (678h and 67Ah for LPT2).

Many SVGA chips implement various ports at X*400h + 2E8h addresses. For example 4AE8h... Apparently this is for compatibility with IBM 8514/A (which was designed for Micro Channel, and probably didn't have this lower 10-bit address decode problem). Such cards do conflict with COM4 I/O addresses.
 
Last edited:
Completely arbitrary on IBM's part (another screwball decision). Some official IBM cards, such as the cluster adapter, use the remainder of the 16 bit address as selects for more than one card. Any "new" ISA card should fully decode all 16 bits of the I/O address--it could save grief in the future when you're running out of ports in the 10 bit space.

Not having a standard design requirement for cards to share IRQ lines is another big fumble by IBM. Some are completely graceful about it (such as the async comm card and the floppy controller); others assume that sharing is impossible.

Something to add while I was reading:

Obviously my knowledge is limited, but I was under the impression that IRQ sharing is NOT possible at all using the ISA bus except for serial and parallel ports (as defined by the PC architecture)- and even then, only by having an appropriately-written ISR which detects which I/O ports needs attention.

But this made me think:

Suppose I'm developing a custom ISA card which supports IRQ sharing and configurable I/O port... if I choose the wrong port above 3FF (7F2- an 'alias' for the floppy port in your example), isn't my ISR going to get garbage when I try to read two values put on the bus simultaneously, with no workaround except choosing a different address? Is the only solution to "not use those ports"?
 
It depends on the peripherals and whether or not:
  • The interrupts from one card can be masked; or
  • If it's possible to identify the source of an interrupt

For example, it's certainly possible to share IRQ 6 among several floppy controllers. Similarly, async comm adapters can share an interrupt. Both adapters can "float" their IRQ pins, so that more than one card can share an interrupt (but not at the same time).
 
I'll add a bit more... The PS/2 uses the upper 6 bits to specify multiple instances of the same device. So, on a PS/2, the first async port is at 03f8h, the second at 02F8h, the third at 3220h, the fourth at 3228h; the fifth at 4220h; the sixth at 4228h; the seventh at 5220h and the eighth at 5228h. All but the first use IRQ3.

On the PC system of interrupts: Remember that the original 5150 used two onboard interrupts for the timer and keyboard and so had 6 to spare--and there were 5 ISA slots, so it was a pretty conservative design. That is, until multifunction boards came along and then the whole scheme fell apart. On-the-motherboard peripherals didn't help either. The 5170 added a second interrupt controller as a slave, adding 7 more interrupts, but those extra interrupts are only available to 16-bit cards.

Had the designers of the PC had a bit more vision, they might have implemented a different interrupt structure. For example, peripherals could assert an interrupt using open-collector drivers, so that as many of them as desired could pull on an IRQ line. If a standard for chaining ISRs had been implemented in software, then an ISR could check to see if its device needed servicing and pass control to the next ISR. The tail of each ISR chain would be the EOI for the interrupt along with an IRET.

Note that it's still possible for something such as a multiport COM board to use its own 8259 PIC and use it to drive a single bus IRQ line as a slave.
 
Many of the shortcomings were eventually fixed.... with EISA. It supported level triggered (shared) interrupts along with proper bus mastering. Too bad it was so expensive it never really caught on. The only thing it had going for it over Microchannel was backwards compatibility with ISA cards.
 
Back
Top