Lazo wrote on 2024-08-01, 12:55:

- If M16# "is not qualified by whether the access is to memory location or not" then the question is why ISA designers included separate IO16 and M16 signals to distinguish IO from memory access if all they needed to communicate is that ISA device is 16-bit or 8-bit.

I'm going to guess the answer is related to how DMA works. Pretty much whenever you find something about the ISA bus that looks strange, the answer is "because DMA".

When this came up before, the answer is that M16# needs to be generated so early by the device that it should be decoded from bits 17 to 23 of the address and nothing else. So it's generated before the device even knows whether it's memory or I/O.

The address lines on the ISA bus are shared between memory and I/O accesses.
The slave device is supposed to signal its datapath width when the address decoder on the device recognizes the address belongs to the device, it's just the address, not the access yet.
Now remember that the I/O space is limited to 16 lines, and it's crippled further on PC by the partial I/O port address decoding (down to 10 lines), the device's I/O address decoder _will_ alias with any other device's memory space, regardless if it's this card or some other. The bus does not know yet what kind of access CPU will be doing, but it already must report the supported width, hence the need in two width indicators, one for each address space supported by the slave device.

The replies in this thread are correct, except for the suspicion that this is related to DMA. The AEN shenanigans for I/O address decoding are due to the way DMA is implemented, and there might be other oddities, too. The distinction between IO16 and MEM16 is not, though.

When looking at ISA, you should be aware that there are some fundamental differences to more modern bus systems in that the ISA protocol works mostly without referring to the bus clock signal. On more modern buses, you have some address lines and some cycle type lines (e.g. M/IO, D/C, R/W on the 386/486 FSB and thus on VL), which all get valid approximately at the same time, which is like 10 to 20ns before the "start signal" for the cycle. The start signal is the rising edge of the CLK line if /ADS (on PCI: /FRAME) is held low. This allows a decoder to fully decode the cycle (or at least start doing it), including whether it is memory or I/O, whether it is read or write and (of course) the address itself before that start signal. On the other hand, on ISA there is no "this is the start of a cycle" signal, and cards do not need to take a look at the bus clock at all. Instead, 8-bit ISA has four individual start signals, one for "I/O read", one for "I/O write", one for "Memory read (inside the first MB)" and finally one for "Memory write (inside the first MB)". 16-bit ISA adds two more start signals for "Memory write (anywhere inside the 16MB space)" and a similar read signal. A device has no idea what direction and address space is being used before that start signal is asserted. Especially for 0WS memory cycles to work, mainboards require MEM16 to be valid so early in the cycle that it is difficult to be implemented (if possible at all) as response to a memory read or write start signal. So to allow the IO16 signal to be valid earlier, it should only decoded from the address lines without waiting for /IOW or /IOR.