I/O Ports

Pathways between the microprocessor and peripheral devices

Parallel -- All bits of data word are input or output simultaneously
Serial -- Bits transferred one at a time over one data line

Synchronous -- Transmitter and receiver synchronized by same clock
     Clock determines data placed/removed on/from bus & when latched
Asynchronous -- No common clock; transfer synchronized by status/control signals
     Called handshaking signals

Ports are needed because of difference in speed of MP and devices

Basic I/O Ports

Parallel Input Port Operation
     MP outputs address, then latches data from Data Bus
     Input port must:
          1. Detect its address
          2. Detect an I/O Read bus cycle
          3. If both are true, gate data onto the data bus
               (when IOR* goes low)
    Minimal circuitry: address decoder and tristate buffers
 

Parallel Output Port Operation
     Output port must:
          1. Detect its address
          2. Detect an I/O Write bus cycle
          3. If both are true, latch data on the data bus
               (at end of IOW* pulse -- i.e., when IOW* goes from low to high)
               If not, data will be gone
    Minimal circuitry: address decoder and latches

8086-based 16-bit input port
     Address decoding: 74LS30 decodes A7-A1: 0011000x (low-order 8 bits of A.B.)
     High-order address bits are don't cares
     Switches S0-S7 mapped to even addresses (AB0=0)
          IN AL,30h
     Switches S8-S15 mapped to odd addresses (BHE*=0)
         IN AL,31H
     Switches S0-S15 mapped to 16-bit port at address XX30H (AB0=BHE*=0)
         IN AX,30H

A sixteen-bit input port for the 8086

Two 8086-based 8-bit output ports
     74LS30 & lower 74LS138 3-to-8 decoder provide several select signals (when BHE*=0)
     AB7-AB1 = 0000100 & AB0=1 activate SEL9*
          74LS32 AND (OR) combines this with IOWB*
                so the low-to-high pulse latches DB15-DB8 into the octal latch
        OUT 9,AL will work (AB0=1, BHE*=0 ==> odd byte address, lower LS138 selected)
        OUT 8,AL will not work (AB0=0, BHE*=1) selects upper LS138
        OUT 8,AX will not work (AB0=0, BHE*=0) selects neither LS138

8086 Output Ports

     74LS30 & upper 74LS138 activate SEL0* when AB=00000000 (when BHE*=1)
     If connected as in figure below,
          IN AL,0 will turn on a relay
          OUT AL,0 will run off the relay

Using Device Select Pulses to control a relay

 

Memory-Mapped I/O

Ports are made to look like memory locations
     Advantage: many more instructions can be used
     Disadvantage: Use up memory locations
Example: 8086-based memory mapped input port
     All 20 address lines must be decoded
     MEMR* & BHE* active ==> A16=A17+A18=A19=1 enables output of lower 74677
          This and A15-A0=1 enables output of upper 74LS677
               which enables tristates of 74LS244 (input port, switches)
               So any read from address 0xFFFFF will input the state of the switches
               The instruction could be: MOV, ADD, SUB, CMP,...and many more

A Memory-Mapped Input Port for the 8086

 

Centronics Parallel Printer Interface

Status input port, Data output port, Command (strobe) output port
BUSY/READY* indicates when printer is ready
Sequence:
     MP checks BUSY/READY* until ready (printer sets it low when ready)
     MP outputs next character (data)
     MP outputs strobe (hi-->low) signal ==> printer latches data & sets BUSY/READY* high

Centronics interface using polling (Figure 8.19)
     SEL2* & SEL3* from address decoder in earlier figure
     1. IN AL,3 inputs status BUSY/READY*  to bit-7 of AL
         (also sets the J-K ==> STROBE* line is high
         This is repeated until bit-7=0 (READY*)
              program polls this line until low
     2. When ready, OUT 2,AL ==> low->high to transparent latch (74LS374)
          ==> data to printer (latched on rising edge)
     3. OUT 3,AL clears J-K F-F ==> STROBE* goes low
     4. Back to polling loop (1) where IN AL,3 raises STROBE*, thus completing strobe pulse

Parallel Printer Interface Circuit

Parallel Printer Program and Timing

Maximum rate of transfer of data (using polling with the Centronics interface)
(Assume 5 MHz 8086 (T = 1/5*10^6 = 0.2 microsecond))
     Occurs if printer is ready each time polling test is made
          Polling T-states = 10 + 4 + 4 (JNZ not taken)
          Printing T-states = 12 + 10 +10 +17
          Total T-states to pring a character = 67
          Time = 67 * 0.2 = 13.4 miroseconds
          Max rate = 1/13.4*10^(-6) = 74627 characters per second
              This would be barely fast enough for a typical  floppy disk (500,000 bits/sec = 62,500 char/sec)
              Would not be fast enough for a Winchester hard disk -- 5 million bits/sec

Efficiency (polling)
Percent of time "wasted" polling
(Assume a 100 char/sec printer ==> .01 sec/char = 10^4 microseconds)
     Timed needed to output a character = 13.4 microseconds
     Percent time outputting characters = (13.4/10^4)*100 = 0.13%
     Percent time "wasted" = 99.9%
          Could be used to do productive stuff

Response time (polling)
Time from moment device is ready until first instruction of "service routine" is executed
For single-device polling:
     1.  POLL:     IN                (10)
     2.                 TEST            (4)
     3.                 JNZ  POLL   (16/4)
Worst case when device goes ready right after 1 (we/ve just input a "busy"
     So must execute instructions 2, 3, 1, 2, 3 before "service routine" begins
     # of T-states = 1 + 16 + 10 + 4 + 4 = 38
          = 7.6 microseconds (pretty good)

Multiple Device Polling

What if there are many devices?
Need more hardware -- status signals from each device could be stored in an input port (latch)
Assume 8 devices & and 8-bit status port:
     POLL:     IN     AL,STATUS   ; (10)
                    ROR  AL,1               ; get first status bit (2)
                    JNC   DEV0             ; Device-0 routine (4/16)
                    ROR  AL,1               ; (2)
                    JNC   DEV1             ; Device-1 routine (4/16)
                    ROR  AL,1               ; (2)
                    JNC   DEV1             ; Device-2 routine (4/16)
                  etc.
                    JMP   POLL             ; Repeat
     DEV0:    -----
                   -----                          ; instructions to do the I/O with Device 0
                   JMP   POLL
      DEV1:   -----
                   -----                          ; instructions to do the I/O with Device 1
                   JMP   POLL
                 etc. for other devices
If service routines done this way DEV0 has highest priority, DEV7 lowest
     If DEV0 is ready all the time, no other device will be serviced (starvation)

An alternative way
     Instead of JMPing to the service routines in the polling, CALL them
     Each service routine would have the following structure::
      DEV0    PROC    NEAR
                  -----
                  RET
Note that with this scheme each device would have the same priority

Worst-case response time if only Device 0 is ready:
     Worst case is when READY* is asserted just after the IN instruction
          8 * (ROR + JNC) + JMP + IN + ROR + JNC = 8*(12+4)+15+10+2+16) = 91 T-States
          On 5 MHz 8086, this is 19 Microseconds.

But what if all devices are ready and serviced?
Depends on the time of execution of each service routine.
     Assume an average of 100 T-states per service routine:
          Worst case approximate number of T-States:  8 * 100 + 200 (for overhead) = 1000
          Time = 1000*0.2 = 200 microseconds
     Is our 100 character/sec. printer OK? (i.e., will printer have to wait?)
          Time for one character = 10,000 microseconds -- and the program is ready every 200 microseconds
          We're OK.
Multiple device polling is OK if slow, printer-speed devices are being used, but not for faster devices.