CSE 378 Homework #6: Memory Mapped Character I/O

Supplement to the main assignment.

When to Work on This Portion

You can implement memory mapped I/O either as you are developing the machine or once you have completed the basic instruction set. Following the general idea of incremental implementation and testing, I would do this last.

What To Do

The overall goal is to implement the character input and output portion of the Cebollita I/O architecture. That archtitecture employs memory mapping to expose the character controller device that lets software write to the console and read from the keyboard. Understanding how it works requires understanding two different issues: memory mapping and I/O controllers.

(Character) I/O Controllers

There are two parts to I/O controllers, the I and the O. Both sides are a little different than what we're accustomed to. On the input side, there is no instruction that causes a character to be typed - the user types one whenever s/he feels like. So, input is asynchronous with instruction execution; it happens when it happens. On the output side, output is slow, requiring many cycles to complete. Because of this, output as viewed by the software is demarcated by two events. The first is the start of an output operation. That is caused by the software telling the controller to perform an output, using a controller-specific command. The second event is output completion. This is signalled by the controller by raising one of the bits of its output. While an output operation is going on, it is a software error to tell the controller to start another one.

To accomplish these tasks, the controller has a command set (more or less a set of instructions that it knows how to execute) that it accepts as its input. When the software wants the controller to start an output, it sends it a command indicating that. The controller also has an output. The output indicates the current state of the controller, e.g., "ready to accept an output command" or "a keyboard input character is available".

Given this, it is the software's responsibility to use the controller correctly. For output, the software must do this:

1. Wait for the controller to indicate that it is ready to accept an output command. This is done by sitting in a loop reading the controller output until it indicates that the controller is ready.
2. Send a command indicating that the software wants to output a character, and what the character is.
The character will appear on the console after some unpredictable number of cycles.

When the software wants to read a character, it must do this:

1. Sit in a loop reading the controller output, until the controller indicates that a keyboard input character is available.
2. When the value the software reads from the controller indicates that input is available, the character is included as part of what was read - the "key is available" is a higher-order bit of the controller output that was read in the loop, and the character itself is in bits 0-7.
3. Because the software has read that character, it sends a command to the controller telling it to turn off the "keyboard input available" bit in its output. That way the software can tell the next time a character is typed.

The details of how this work depend on the controller. We'll be using SMOK's Character Controller Device. Its documentation tell you what the controller's command set is, and what the controllers output bits mean.

Memory Mapping

Okay, we know how the software can read and write characters, except for one thing: how does it send command to the controller, and how does it read the controller's output?

We could create new opcodes for this: RFCC (Read From Character Controller) and WTCC (Write To Character Controller). That would work, but the downside is that we'd need a different pair of opcodes for each controller attached to our system. Besides being cumbersome, that would make it impossible to attach controllers that were designed after the processor was built (since the processor wouldn't have the needed opcodes).

Instead of using new opcodes, we note that sending commands to the controller is basically a store operation: "Take the contents of this register and send it to.... Similarly, reading the controller's output is basically a load: "Get ... and put it in this register." So, instead of special opcodes, we'll just use sw and lw.

How can that work? How does the machine know we want to talk with the character controller, rather than memory, on a sw or lw? The answer is that we use a special address to indicate that we really mean the controller, not memory. In particular, Cebollita uses the address 0x40000000. A sw to that address should take the register contents and store it to the character controller (and not anywhere in memory), and a lw from that address puts the character controller's output into a register.

To get this to work is relatively simple: you just need to add enough control to notice that the instruction is a lw or sw and that the address is 0x40000000. Under those conditions, you route the data to/from the character controller, and (if it's a sw) you do NOT cause the memory interface to do a write.