PC PROTOTYPE CARD part-3

G. DECODING

 
Build a prototype card implies how to decode the addresses. There are 2 types of decoding techniques, i.e.: I/O decoding and Memory decoding. If the hardware used I/O map for its port, it was called I/O mapped I/O, and if the hardware used memory map for its port, it was called memory mapped I/O.
What are the different point between this 2 types of decoding ?
If we use I/O mapped I/O port, we only can access this port by using the IN and OUT commands. If we used memory mapped I/O port, we can access this port by using all of the commands usually used for data transfer like MOVE, STORE, or any other modes of addressing transfer. In the I/O mapped I/O port, we can only used the reserved location among 1024 locations which implemented for. In the memory mapped I/O, we can used the upper location of memory above A0000 hex, and it is more wisely if we use the upper limit of FXXXX hex boundary which is still available; e.g.: start at F0000 hex, because many of the available locations can be used for UMB block or for XMS pages. 

•  I/O Mapped I/O Decoding

 

Because of the I/O restriction, we only use 10 address lines (A₀ ~ A₉). Besides that we need AEN line, -IOR & -IOW, -I/O CH RDY (for some card that needs wait states). Notes that, adding wait states will make the computer to run more slowly. It is more wisely not to use this line.How we decoding this lines ? For example; we use address location 300 hex which is still available for prototype card. We need 8 consecutive I/O port locations. The decoding is as follows :

AEN A9 A8      A7 A6 A5 A4      A3 A2 A1 A0

 0  1  1     0  0  0  0    1 X  X  X   =  300 ~ 307 hex

So the decode is :

___    _ _ _ _

AEN A9A8A7A6A5A4A3A2A1A0

• Memory Mapped I/O Decoding
 

Because of DOS restriction, we only use 20 address lines (A0 ~ A19). Besides that we need -MEMR & -MEMW lines.For example; we used 16 consecutive I/O start at the F0000 hex location. So the decoding is as follows :   A₁₉ A₁₈ A₁₇ A₁₆  A₁₅ A₁₄ A₁₃ A₁₂  A₁₁ A₁₀ A₉ A₈  A₇ A₆ A₅ A₄  A₃ A₂ A₁ A₀

 1  1   1  1    0  0   0  0    0  0  0  0   0  0 0  0   X  X X  X

= F0000 ~ F000F hex

So the decode is :

              _  _   _  _  _   _  _  _ _ _  _ _

A₁₉A₁₈A₁₇A₁₆A₁₅A₁₄A₁₃A₁₂A₁₁A₁₀A₉A₈A₇A₆A₅A₄A₃A₂A₁A₀

 

 

H. EXPANDING I/O MAP

 
What are you doing if you run out all of the I/O location ?
There are still more techniques to take advantage of this problem. One is to utilise the upper address line (A₁₀ to A₁₅). On the faceof it this is unacceptable, since these address lines are not decoded by either the system hardware or any expansion cards. These items of hardware will therefore respond to "echoes" of their base addresses, making addresses above 3FFH unuseable. However this problem is avoided if we only use addresses that are "echoes" of the still available address range in the upper block of 512 addresses. For example if the range in 300H to 31FH (32 consecutive I/O ports) are still available, we can expanded it to the limit of 16 x 32 consecutive I/O ports by implemented the above technique. By decoding one or more of the upper address lines as well as the lower 10 address lines, these 32 addresses can effectively be used over and over again, with one set of hardware using the base address range, and each additional piece of hardware using a different "echo" address range. This gives what should be more than enough input/output addresses to satisfy even the most prolific expansion card builder.
The second technique is by used an I/O port as an indexed port like used by video display adapter port. This technique let us to expand 8 I/O ports by used only 2 of the existing I/O port addresses, i.e.: one for the indexed port and the other for the enable port.