The peripheral constantly transmits status information back to the CPU via the status register, such as whether the operation completed or experienced an error, or how much data was transferred. If the CPU explicitly asks what the tape reader is doing, perhaps because the reader hasn't responded with data in a while, the reader is obliged to tell it using the status register. In addition, the status register may be used to pace the CPU and the peripheral so that they do not get out of step with each other and lose data.

In our example, the two status ports are two bits long each. Remember, one is for the CPU to give status information to the tape reader and the other is for the opposite.

Here are the codes that the two devices put into their status ports. (TR is short for Tape Reader.)

CPU status port (which the TR reads)

00   CPU is quiescent
01   CPU has issued IN; now waiting for TR to respond
10   CPU has read the TR's result byte and accepted it

TR status port (which the CPU reads)

00   TR is ready to accept a command from the CPU
01   TR is getting the next byte
10   TR has gotten the next byte and it is ready to be read

For each byte read and sent to the CPU, the tape reader and the CPU communicate via these two ports. When the CPU issues an IN command to start the TR working, it sets its port to 01. The TR reads this and knows that the CPU is waiting for it to fetch the byte. While it fetches the next byte off the tape, the CPU continually reads the TR's status port, waiting for it to change from 01 to 10.

Finally the byte is ready and TR puts that onto the data port. Then it sets its status port to 10. The order of these events is critical because if the CPU is told that the data port has the correct value but the TR hasn't yet put that there, the CPU will read the wrong bit pattern.